Proof

Can DaemonCore actually do what it claims?

Not a marketing answer — a recording. DaemonCore's first genuine captured execution, RUN-001, is on this site and you can replay it line by line. It is partial and honest about what it is; the rest of this page helps you decide whether it is worth inspecting.

For engineers, architects, security professionals and technical evaluators judging whether governance-before-execution is structurally real.

What you can inspect today

One genuine recorded execution. A real code_review_request was published to the runtime and driven through admission — schema validation, the governance gate, and the creation of a canonical execution — with every artifact preserved verbatim. Here are three lines from the log:

recorded · RUN-001 · governance gate → execution → admission

[trace=15b52d4c] [msg=EVID-e9b58172] [role=reviewer] [agent=29f43d03] [EnforcementGate] Advisory: No skill match: No candidates found in any registry
[trace=15b52d4c] [msg=EVID-e9b58172] [role=reviewer] [agent=29f43d03] [Execution] Created exec-a41c2c95cbc8 | intent=code_review_request | trigger=queue_message:EVID-e9b58172 | participant=reviewer
[trace=15b52d4c] [msg=EVID-e9b58172] [role=reviewer] [agent=29f43d03] [MaxBusBridge] Dispatched EVID-e9b58172 -> execution exec-a41c2c95cbc8 (admission only; outcome pending)
Three contiguous lines from the recorded RUN-001 runtime log: the governance gate evaluates the request, the runtime creates execution exec-a41c2c95cbc8, and dispatch stops at "admission only; outcome pending". Leading timestamps and levels, and one trailing workspace path, are omitted; nothing between is altered. The gate ran in advisory mode and no model executed. The full recording is one click away.

What RUN-001 is

RUN-001 is a genuine capture of the DaemonCore runtime admitting a request through the governance gate, recorded on 17 July 2026 as execution exec-a41c2c95cbc8. It was captured in process against the real runtime in an isolated workspace — recorded, not reconstructed. The identifiers, timestamps and advisory warnings you see are the system's own output, left exactly as produced.

What it genuinely proves

The sequence is the substance of the claim: the request was validated, passed the governance gate, and only then became an execution — governance before execution, shown rather than asserted.

Every line carries a trace id, message id, role and agent, so "what happened, and who requested it" has an answer built into the record rather than added by an application that remembered to log. That is the attribution an audit needs.

What it does not prove

RUN-001 is genuine but partial, and stating its limits is part of the evidence. It captures the admission phase only:

  • No model executed — the code review itself was never performed; this is not evidence of a completed review or task outcome.
  • The gate ran advisory — it was invoked before execution and admitted the request; it did not block anything here.
  • Unsealed — the execution was left in progress, with no sealed terminal outcome.
  • Not independently verified — no second party has reviewed the artifact against runtime behaviour.

It is limited to the demonstrated admission path. We say so here rather than let the recording imply more than it shows.

Inspect the full replay

The excerpt above is a summary. The full recording — the complete admission timeline, replayable event by event, with each moment inspectable against its provenance — lives on its own page. That is where "what exactly happened" is answered; this page only answers "why inspect it".

The fuller shape, illustrated

Show the illustrative end-to-end path

RUN-001 is real but partial. To show the complete governed path — including the parts the advisory run does not reach — the walkthrough below is illustrative: it traces the shape of the behaviour rather than recording a live session.

  1. A request arrives as ambiguous natural language and is classified before any action.
  2. The agent must produce a protocol-shaped proposal that can be validated, not free-form text.
  3. The validated proposal routes as a typed message; a mismatched schema simply will not route.
  4. Execution runs inside template constraints — required checks, bounded scope, read-only access.
  5. An out-of-scope access is blocked at the governance layer and logged with full context.

One honest limit: DaemonCore V1 does not prevent prompt injection at the model level. If manipulated, an agent can still be influenced — but it cannot act outside its permitted scope, and the attempt is recorded. Governance bounds and records; it does not promise to prevent. How the layers enforce this is on the Architecture page.

Where this goes next

Architecture

How is this structured? Kernel, runtime, capability boundaries and the bus.

Enterprise

What does this mean for an organisation? Bounded risk, accountability and audit.

Documentation

The public kernel specification: architecture, concepts and technical questions.

Developer

What can I inspect and build against today, and where is the project going?