The Six Substrate Dimensions

Governed agent systems are being built on top of frameworks that treat agents as prompts, tools, and graphs. The frameworks are impressive. They are also, by design, interface layers. They make bets about what an agent is and how agents should talk. Those bets will age. When they do, the systems built directly on them will have to move.

The earlier post Causal Decomposition Under Suspended Judgment applied causal decomposition to two failure modes in retrieval and orchestration. The Protocol Between Agents Is the Protocol Between Teams argued that the pattern the software industry has already lived through, interface layers that replatform and service layers that patch, is about to repeat in multi-agent AI. The protocol between agents is the protocol between teams. If that protocol sits on a durable substrate, change is engineering. If it sits in the interface layer, change is a coordination tax.

This post narrows the lens again and makes the substrate explicit. It defines six dimensions that every governed agent system must carry, regardless of framework:

• Identity: who did this?
• Task state: where is this work right now?
• Tempo: how fast should this happen?
• Cost: what did this consume?
• Currency: is the justification still valid?
• Fidelity: how do we know this answer is true enough for this context, and what evidence proves it?

These are not features. They are substrate commitments. They are the questions a regulated enterprise must be able to answer about any agent doing work under its name. If a system cannot answer all six, it is not governed. It is a demo.

What a substrate dimension is

A substrate dimension is a property of the work itself, not of any particular framework.

• It is first-class in the schema: every audit entry, every task record, every dispatch carries it.
• It is configurable per task: different workloads require different values.
• It is stable across replatforming: when the agent framework changes, the dimension still exists and still means the same thing.
• It is separable from implementation: the dimension says “this task requires X,” not “you must use algorithm Y to achieve X.”

Identity, tempo, task state, and cost were introduced in Causal Decomposition Under Suspended Judgment and The Protocol Between Agents Is the Protocol Between Teams as the first four dimensions. Currency was added in conversation with George Lagogiannis as a fifth: is the justification for this answer still valid right now? This post adds the sixth: fidelity.

Fidelity is the dimension that turns “does this answer look plausible?” into “does this answer meet the bar required for this context, and what evidence shows that it does?”

Fidelity is not a single check

It is easy to conflate fidelity with a single scorer. In the Keystone stack, HHEM answers one specific question: does the answer match the chunks? That is a fidelity check. It is not fidelity itself.

Think of fidelity like measuring whether a building is level.

• If you are hanging a picture, you hold up a phone with a bubble level. Good enough. If the picture is slightly crooked, nobody is harmed.
• If you are pouring a foundation, you bring a transit level and measure to the millimeter. If the foundation is off, the whole building is off, and you cannot fix it later without tearing the building down.

Same property being measured. Completely different precision. Completely different instrument. The difference is not the measurement. The difference is the consequence of being wrong.

Agent systems have exactly this structure.

• A customer asking “what are your office hours?” needs almost no fidelity checking. If the answer is slightly outdated, nobody is harmed.
• A customer asking “can I stop taking this medication based on my latest lab results?” needs the highest fidelity you can achieve. Wrong answer, real harm.

Right now, many stacks have only one instrument, HHEM or a similar entailment scorer, and they use it for both the picture and the foundation. It works, but it does not know it should try harder for the foundation than for the picture.

Fidelity as a substrate dimension means the system carries a fidelity requirement on every task, the same way it carries tempo or cost. Not hardcoded. Configurable. Tunable per domain, per task type, per consequence level.

How fidelity looks in the substrate

A task arrives. In a system that treats fidelity as a dimension, the task record carries:

• Identity: which agent is answering, and under whose authority.
• Task state: created, in progress, completed, failed, or under review.
• Tempo: how fast this response must be delivered.
• Cost: what budget in tokens, latency, and dollars this task can consume.
• Currency: how fresh the justification must be, and how staleness is measured.
• Fidelity: what bar the answer must clear before it is allowed to leave the system, and what evidence must accompany it.

The fidelity field does not specify which algorithm runs. It specifies the requirement: what kind of verification this answer needs, and how precise that verification must be.

Concrete examples:

• Low-consequence, general knowledge (e.g., “what are your office hours?”)
  • Fidelity requirement: HHEM score above 0.5, no additional check.
  • Rationale: minor harm if slightly wrong; speed and cost dominate.
• Regulatory query in financial services (e.g., “can I execute this trade under rule X?”)
  • Fidelity requirement:
    • HHEM above 0.8, and
    • source document published within the last 90 days, and
    • citation to the specific regulatory section included in the response.
  • Rationale: wrong answer exposes the firm to compliance risk; evidence must be auditable.
• Clinical query with treatment implications (e.g., “should I stop this medication given my latest labs?”)
  • Fidelity requirement:
    • HHEM above 0.9, and
    • check against a known-current formulary or guideline, and
    • mandatory human review before the answer is delivered to the patient.
  • Rationale: wrong answer can cause direct harm; highest bar, most instruments, human in the loop.

The fidelity dimension does not define which scorer, which retrieval-date check, which formulary, or which human review workflow runs. It defines that a bar exists, that it is attached to the task, and that evidence of meeting the bar is recorded. The implementation can change. The contract does not.

This is exactly parallel to tempo. Tempo does not define which scheduling algorithm runs. It defines that the system knows how fast this task should complete and can route accordingly. The routing implementation can change. The dimension stays.

Currency as a control-theory problem

The Currency dimension came out of an exchange with George Lagogiannis. He framed the question as: “Do the conditions that originally justified this action still hold?” If not, everything above may still be working correctly, but the action may no longer be justified.

In that exchange, Currency is first a governance question: whether the original justification still legitimately authorizes the intended consequence at the point of execution. In the substrate, that question becomes a property the system must carry on every task. The control-theory framing is one realization of that governance question, not the only possible one. That question can be answered through control-theoretic mechanisms, through policy re-evaluation, or through other architectures. The substrate commitment is to carry the question. The implementation decides how.

The framing that emerged from that conversation is that this is time-of-check to time-of-use, but the mechanism is closer to control theory than to security. In a control loop, the set point can drift between the moment the controller decides and the moment the actuator responds. In a fast plant with a stable reference, the drift is negligible. In a slow plant with a drifting reference, the error dominates.

Agent systems have exactly this structure. The authorization decision is the controller’s response to the reference at time t. The action is the actuator responding at time t + delta. If the reference has drifted during delta, the action is aimed at a target that no longer exists.

Currency is functionally a dead-band re-validation at the point of consequence: if the state has drifted beyond threshold since authorization, re-check before executing. That is a specific mechanism, not just a principle. It does not fit inside orchestration. It is a governance layer that sits between the orchestration layer and the actuator layer, and it needs to know both the original justification and the current state to run the comparison.

Why fidelity must be a dimension, not a feature

Most current agent frameworks treat fidelity as an afterthought. If it exists at all, it is:

• A single scorer wired into a particular retrieval pipeline.
• A hard-coded threshold in one service.
• Something that can be “added later” when governance becomes a requirement.

That approach works until it does not.

When fidelity is a feature:

• It is local: one team’s scorer, one pipeline’s threshold.
• It is invisible to the rest of the system: orchestrators, audit logs, and compliance tools do not see it as a first-class property.
• It is hard to change: raising the bar for a class of tasks requires hunting down every place the scorer or threshold is used and coordinating across teams.

When fidelity is a dimension:

• It is global: every task carries a fidelity requirement, regardless of which agent or framework produced the answer.
• It is visible: orchestrators can route high-fidelity tasks to different paths; audit logs can record what bar was required and what evidence was produced; compliance tools can query “show me all tasks with fidelity ≥ X in domain Y.”
• It is changeable without replatforming: you can swap HHEM for a better scorer, add domain-specific checks, or introduce human review for certain fidelity levels without changing the substrate contract. The substrate only says “this task requires fidelity level X.” How you achieve level X is implementation.

The difference is the same as between patch and replatform. With fidelity as a feature, every new requirement is a negotiation. With fidelity as a dimension, it is an engineering conversation.

The six dimensions together

Bringing all six together, the substrate contract for any governed agent system looks like this:

• Identity
  Every audit entry, every state record, every authorization decision carries a first-class field for “which agent did this.”
  Without identity, multi-agent governance collapses. You cannot answer “who is allowed to call this tool,” “who took this action,” or “did the compliance agent verify what the retrieval agent claimed.”
• Task state
  Work exists as tasks with explicit state: created, in progress, completed, failed, under review.
  That state lives in the data plane, not implicitly in agent code. Without first-class task state, a hung agent, a rate-limited tool, or a failed call leaves the orchestrator with no way to detect stuck work, reassign tasks, or recover gracefully.
• Tempo
  Different agents operate on different time horizons: sub-second for customer-facing engagement, seconds for compliance checks, minutes or hours for batch analytics.
  If tempo is not a first-class field and dispatch parameter, the orchestrator will either block fast workflows on slow agents or exclude slow agents entirely. Both outcomes break guarantees.
• Cost
  Every operation records what it consumed in tokens, latency, and dollars. Every dispatch carries a budget. Agent registries hold cost profiles; audit entries carry cost fields.
  As multi-agent systems consume an order of magnitude more tokens than conversational interactions, and as regulated enterprises ask for cost-per-query reports and cost-bounded behavior, cost moves into the center of governance.
• Currency
  Every answer carries a justification: which documents, which rules, which data supported it. Currency asks: is that justification still valid right now?
  Some work can tolerate week-old justifications. Some cannot. Without currency, systems deliver answers that were once correct but are no longer safe, compliant, or aligned with current policy.
• Fidelity
  Every answer carries a fidelity requirement: what bar must it clear, and what evidence proves it cleared that bar?
  The bar scales with consequence. Low-consequence queries need light checks. High-consequence queries need multiple instruments and possibly human review.
  Fidelity is not a single scorer. It is a configurable requirement that can be met by HHEM, other scorers, retrieval-date checks, domain-specific validators, human review, or combinations thereof.

All six dimensions share the same properties:

• They are substrate-level commitments that do not depend on any particular agent framework.
• They survive framework churn. Whatever happens to LangGraph, CrewAI, the Agents SDK, or Agent Framework, enterprises will still need to answer these six questions about any agent doing work under their name.
• They turn governance from a set of ad-hoc checks into a stable contract that the system must honor on every task.

An evidentiary layer that can be verified across framework and organizational boundaries belongs in this substrate. That is the point Kazuki Toyota underscored in our exchange: Evidentia does not determine whether an answer meets the fidelity bar. It makes the record of the checks, outputs, and resulting evidence independently verifiable across systems and organizational boundaries. If that record must remain legible and auditable when the agent framework changes, the evidentiary commitments cannot be framework-specific. They belong in the substrate.

The falsifiable test for “substrate vs framework” came out of a conversation with Raheem Larry Babatunde. He asked for a way to distinguish, in advance, what belongs to the substrate and what belongs to the interface. The answer is entity-replacement invariance: if you replace the agent, the framework, or the provider, and the property is still necessary, it is substrate. If it disappears when you swap the implementation, it was always framework. This test connects directly to the independent convergence seen in AEGF Session 01, where identity and task state surfaced across multiple contributions because governance questions like admissibility, observability, authority, and post-execution legitimacy all depend on them.

Day-one substrate versus future retrofit

The practical difference between treating these six dimensions as day-one substrate and treating them as future enhancements is the kind of work required to add them.

If identity, tempo, task state, cost, currency, and fidelity are present in the schema from the first commit:

• Future code can start using them as soon as there is a reason.
• They are available for queries, dashboards, and governance without forcing a data migration.
• Having all six from the start gives a bigger picture of what the system must account for in the pipeline: how tasks are routed, what is audited, what compliance checks run, how cost is bounded, and what fidelity checks are required before an answer leaves the system.
• The argument about whether to use them is an engineering conversation.

If they are absent:

• Every future capability that depends on them requires a schema change, a backfill, a redeploy, and an organizational negotiation.
• The argument about whether to add them is a roadmap conversation.
• The cost is paid not just in engineering hours but in coordination at the human layer.

In the second case of Causal Decomposition Under Suspended Judgment, the day-one substrate decision in Keystone was a deliberate choice to incur eight to twelve hours of schema and interface work in order to avoid months of retrofit later. Two tables, a handful of fields on the audit schema, a few extra parameters on dispatch interfaces, and observability attributes. That is not heroic engineering. It is boring work, done early, informed by watching what happens when it is not done.

Applied to multi-agent AI in general, the claim is simple: every team that builds a serious governed agent system over the next few years will either pay for these six dimensions up front or pay for them later. Paying later is more expensive.

Why this matters beyond one platform

Most engineers building multi-agent systems in 2026 have not yet lived through a full replatform cycle in their own stacks. They have seen local refactors and infrastructure migrations. They have not watched an interface layer get replaced three or four times while the service layer underneath stayed recognizably itself, and they have not sat in the customer conversations where the cost of those replacements was negotiated.

Most buyers signing contracts for agent frameworks have not lived through it either. They are being told they are buying “the future,” and in a narrow sense they are. What they are not being shown is the pattern: interface layers are bets, bets age, expired bets replatform, and replatforming is paid for by customers whose workflows, approvals, and training are built on the old shape.

This post exists for that audience.

It says: the pattern you have already seen in desktops, web UIs, and cloud workspaces is about to show up in agent frameworks. The layer where agents live and talk will be rebuilt. The substrate that models what the business needs to know can either be attached to that layer or kept separate from it.

Building on the substrate means committing to six dimensions that do not age with frameworks. Building directly on frameworks means committing to assumptions that do.

Keystone’s position in that pattern

Keystone is opinionated about where it belongs in this picture.

The platform is built as governed retrieval and orchestration for regulated environments, with the substrate holding identity, tempo, task state, cost, currency, and fidelity as first-class citizens. The agent layer above it is treated as replaceable. Frameworks are tools. Substrate is the commitment.

The public eval ledger exists so that the decisions made at that substrate can be inspected, rerun, and criticized. The keystone-engage and keystone-verify repos exist so that the architecture is not just described but visible. The day-one schema choices are not secret. They are artifacts.

• Ledger: https://github.com/getkeystone/keystone-ledger
• Engage: https://github.com/getkeystone/keystone-engage
• Verify: https://github.com/getkeystone/keystone-verify

The point is not that Keystone is uniquely correct. The point is that Keystone is built as if multi-agent replatforming is inevitable and the substrate must survive it.

If the tech industry repeats the pattern it has already lived through, there will be enterprises in 2028 looking at agent frameworks the way contact center buyers looked at workspaces in previous cycles: useful, necessary, and expensive to move off. There will also be a smaller number of systems that treated the substrate as a separate commitment and can patch through the transition.

This post is a record that says, in advance, which side Keystone intends to be on.