RUNTIME BOUND
Explore the local demonstration

Architecture

In the local demonstration, an agent cannot route around the boundary.

In the local demonstration, Runtime Bound runs as separate identities on one host. The agent proposes and holds no key. Only the broker can send. A witness keeps a separate record of every change.

The Runtime Bound local boundary The agent proposes to the broker. The broker checks authority and capacity, reserves capacity, signs and forwards approved orders to the destination. The broker records every change with the witness first, and asks the time and position sources for trusted time and observed commitments. The operator reaches the broker through the console. Agent Proposes an action. Holds no key. Broker Checks authority and capacity, reserves capacity, signs, and forwards only what is approved. Only identity that can send. Destination Simulated in this demo. Takes broker-signed orders only. Witness Separate record of changes. Time and position sources Trusted clock; external commitments. Operator console Halt, resume, reconcile. proposes asks for time and positions sends records first
  1. Agent. Proposes an action. Holds no key.
  2. Broker. Checks authority and capacity, reserves capacity, signs, and forwards only what is approved. The only identity that can send. It asks the sources for time and positions, and writes every change to the witness first.
  3. Witness. Keeps a separately administered record of every change, written before the change commits.
  4. Time and position sources. Answer the broker’s requests for the trusted clock and for external commitments.
  5. Destination. Simulated in this demonstration. Takes broker-signed orders only.
  6. Operator console. Halt, resume and reconcile.

Illustration of the local reference topology. In the demonstration each role runs as its own operating-system account on one Linux host. Arrows follow the request: the agent proposes to the broker, the broker asks the sources, records with the witness, and sends to the destination. “Independent” means a separate service and account within this demonstrated topology; it is not an independent institutional attestation.

What the boundary checks

  • Authenticated authority. A mandate signed by the institution’s root, an envelope that may only narrow it, approvals by a named limit setter, a time attestation from the clock source that names the exact action, and a signed observation of commitments made elsewhere. The broker fetches time and observations itself. The agent supplies only the action.
  • The exact action. The approval is bound to a digest of the action. A changed instruction, a replayed approval or a forged one is refused before anything is sent.
  • Capacity. One exact dollar contract. Evaluation, record and reservation happen in a single locked transaction, so concurrent proposals can never jointly exceed the limit.
  • Safe recovery. Every state change is appended to the witness before it commits. A restored state database is replayed forward from the witness before any decision; a forked or downgraded one is refused.
  • Exclusive sending. Separate operating-system identities and permissions. The destination accepts only orders signed with the broker’s sending key.
  • Reconstructible evidence. The journal, each evaluation, each interception, each acknowledgment and the witness record export as linked records.
A permitted evaluation is not permission to forward. The broker forwards only when the approval verifies, names this installation, matches a decision it recorded, matches the exact instruction being sent, and has not been used before. A failure while recording is a hold, never a permission.

The six outcomes

Evaluation returns one of these states and only these. There is no advisory pass. An unenforced breach is never a pass.

OutcomeWhat it means
PERMITTEDThe action is inside the envelope, review dates are current, constraints do not conflict, and no documented limit is breached.
DENIEDA documented limit that is enforced is exceeded, or a reserved action is attempted against a halt.
INSUFFICIENT INFORMATIONThe envelope cannot be examined: unsigned, incomplete, or missing facts about the action. It fails closed.
OUTSIDE AUTHORITY SCOPEThe action is not among the permitted actions, or asserts a quantity the envelope does not govern.
CONFLICTING CONSTRAINTSThe envelope cannot be satisfied as written.
REQUIRES ESCALATIONA limit is breached while enforcement is unenforced or partial, or a review date has lapsed. The gap is recorded and the action is not passed.

What an institution must supply

This package is a local reference demonstrator. Its keys, institution, persons, sources and destination are synthetic. Adopting the design takes, at least:

  1. Authority: its own root, roster, key custody and signed mandate and envelope, with revocation and rotation.
  2. Time and observation: a trusted time source and an independent feed of external commitments.
  3. A witness under separate administration from the broker host.
  4. A real destination reachable only by the broker, with idempotency, authenticated acknowledgments and a statement feed.
  5. Host and key custody appropriate to the risk.
  6. Operations: monitoring, alerting, evidence retention and tested restores.
  7. Regulatory and legal mapping and acceptance, and an independent examination. A passing demonstration implies none of these.
Current release status. Local reference demonstrator with simulated interception. In simulation it implements approvals bound to the exact action, durable capacity reservations, one-time use of each approval, witness-anchored recovery, exclusive sending to a simulated destination and linked evidence. Institution-specific trust, destination integration, operations and legal acceptance remain with the institution, and institutional effectiveness is not claimed. See how to run it locally.