Skip to content
FractalOps

FeaturePlane

FeaturePlane

Section titled “FeaturePlane”

FeaturePlane is the agent-facing feature-store layer for FractalOps. It converts noisy project evidence, issue history, FractalOps lineage, DataHub project RDF steward reports, PostHog behavior events, OpenTelemetry runtime signals, and warehouse facts into compact feature briefs that agents can read before falling back to raw logs.

Responsibility Split

Section titled “Responsibility Split”
  • Semantics remains the lineage source of truth. FeaturePlane stores DataHub URN references reported by project RDF steward agents, but DataHub does not own SCIM/JIT, proof, mutation, or project authority.
  • ClickHouse remains the warehouse fact and event accumulation plane. Project RDF steward reports must also emit normalized ClickHouse events/facts so historical analysis, metrics, and warehouse proof do not depend on DataHub API availability.
  • PostHog and OpenTelemetry are distributed source systems. FeaturePlane consumes their ClickHouse projections after they are classified into the global ontology; it must not consume unbounded raw event streams directly.
  • Redpanda is the Kafka API-compatible event log for fresh agent signals, blocker events, and feature materialization triggers.
  • Feast owns feature registry, feature serving, online/offline store configuration, and OpenLineage emission for feature definitions and materialization.
  • OpenBao owns secret values. FeaturePlane stores only secret refs such as ref:feature-plane:feast-registry-dsn.
  • CUE/Helm GitOps owns the portable infrastructure contract. FeaturePlane is rendered as a dedicated GitOps/data-plane contract so the feature stack can move without expanding a central infrastructure claim.

Agent Contract

Section titled “Agent Contract”

Agents should call the feature-plane MCP before reading raw evidence. The MCP returns a small feature_plane_agent_brief with:

  • feature ids and entity keys
  • DataHub project RDF steward refs
  • Feast project and materialization SLA
  • freshness and blocker-risk feature names
  • estimated token savings compared with raw context

This is the Hermes-style path: agents receive a structured context card, use the refs to request deeper evidence only when needed, then report gaps back through the HUD or GitHub issue flow.

Runtime Shape

Section titled “Runtime Shape”

The canonical render path is:

Terminal window
fractalops feature-plane render \
  --topology ops/infra/topology/lxc-pve-lab.yaml \
  --project-slug fractalops \
  --output-dir /tmp/feature-plane

It emits:

  • feature_repo/feature_store.yaml for Feast
  • datahub-recipes/*.yaml for DataHub ingestion
  • feature-plane.json for GitOps review and agent context tests

The MCP entrypoint is:

Terminal window
ops/cli/run_feature_plane_mcp.py

Armory mounts it as feature-plane, and Ouroboros receives it by default.

Feast is not imported into the FractalOps control-plane process. FractalOps renders the portable feature repository contract; GitOps deploys the Feast runtime separately so Feast dependency constraints cannot destabilize the Portal/API runtime.

Token Economy Rule

Section titled “Token Economy Rule”

FeaturePlane must not pass full session memory, issue bodies, or DataHub payloads directly to agents when a compact feature brief exists. The default budget is five feature refs and ten lineage refs. The token_economy block estimates raw vs compact token use so regressions are testable.

Current Standard

Section titled “Current Standard”
  • Use redpanda naming in FractalOps contracts.
  • Use DataHub kafka ingestion type only where DataHub expects Kafka protocol metadata.
  • Use Feast SQL registry for concurrent materialization safety.
  • Use Redis-compatible online store settings with Valkey as the internal compatible backend.
  • Do not add local DB fallbacks or hard-coded credentials.