What Hiveram owns

The public identity map for the work-intelligence layer.

Hiveram is the layer that keeps work explicit enough for humans and agents to share it safely. It is where the canonical work graph lives, where execution evidence accumulates, and where portable reasoning can leave one environment and return without dissolving into transcript folklore.

The short version is simple: Hiveram owns the work graph, its execution evidence, and the bounded handoff surfaces around it. It does not try to become the context compiler, the policy runtime, the evidence court, or the runner itself.

Hiveram owns

• Canonical work orders. Title, scope, acceptance, priority, status, targets, and related evidence.
• Execution routing signals. Complexity tiers, model fit, grouping, and bundle-level planning.
• Portable reasoning handoff. Bounded request and reply bundles, mission briefings, and controlled apply back to the canonical graph.
• Scaffold review and continuation. Current tip, attached scaffold path, visible claim weight, and continuation from the right rung instead of transcript replay.
• Checkpoints and provenance. Branchable continuity, reviewable returns, and visible lineage for what left, what came back, and what was applied.
• Authority modes. One shared authoritative mode for canonical writes, plus explicit portable or disconnected workflows when the environment requires them.

Hiveram does not own

• Context shaping and focus-window delivery. That belongs to NeuroRouter.
• Action-boundary policy. That belongs to Verdict.
• Evidence dissection. That belongs to VectorCourt.
• Issue intake and diagnosis. That belongs to Hivebus when teams want an upstream intake surface.
• Execution runtime. That belongs to tokencontrol when teams choose the wider stack.

Hiveram and Workledger

Workledger is the engine name inside the product: the CLI, API, bundle, checkpoint, scaffold, and provenance surfaces that Hiveram exposes. Buyers do not need to reason about that distinction first, but engineering teams often appreciate seeing it named once and named cleanly.

So the mapping is: Hiveram is the product surface. Workledger is the engine and protocol surface that carries it. Workledger keeps the scaffold attached, durable, and reviewable. Hiveram makes that visible enough for operators to inspect the current tip, the recent path behind it, and what can safely carry weight into the next session.

How the surrounding products relate

• Hivebus keeps why work exists explicit before execution starts.
• Hiveram keeps what work exists, what it touches, how it moves, and what execution evidence exists around it.
• tokencontrol executes ready work across the chosen runners and providers.
• NeuroRouter decides what slice of the Hiveram graph enters the live model window and protects continuity during long sessions.
• Verdict enforces what the agent may do at the action boundary.
• VectorCourt stress-tests evidence and decisions before they harden into costly commitments.

Why this separation matters

Good boundaries reduce product confusion and operator risk at the same time. A team can adopt Hiveram alone, or add the surrounding layers one by one, without the whole stack collapsing into one opaque system.

That is also why custody choice and runtime mode stay explicit in public. Some teams want a live shared ledger. Some need portable reasoning, delayed apply, or airgapped transfer. Both are legitimate. The important promise is that the authority boundary stays visible and the shared truth stays singular.