00 · ABSTRACT # Every claim here carries its status, and every number its provenance. Every claim below carries a status and a provenance class, stated exactly: an artifact you can fetch right now, an artifact rendered on this page, a live walkthrough of the platform shown on request, or an artifact available under NDA on request. Statuses are VERIFIED, MEASURED, IN INTEGRATION, ROADMAP, or DECLARED. Every roadmap-status item we track is listed beside the verified ones. 01 · CLAIMS LEDGER ## The ledger. Every VERIFIED row points at a real artifact you can fetch or request, never demo data. Walkthroughs marked ON REQUEST and artifacts marked UNDER NDA are available through the [contact form below](https://rensei.ai/evidence#contact) . Claim Status Provenance Current append-path audit entries are hash-linked and Ed25519-signed; verification protocol and per-workspace key discovery published VERIFIED Provenance FETCHABLE: [curl https://rensei.ai/.well-known/audit-keys.json](https://rensei.ai/.well-known/audit-keys.json) retained history may include legacy unsigned entries The execution layer (donmai) is open source under the MIT license VERIFIED Provenance FETCHABLE: [https://github.com/RenseiAI/donmai](https://github.com/RenseiAI/donmai) 199 historical policy denies immutable on Rensei's own production audit chain MEASURED Provenance UNDER NDA: audit export, available under NDA on request count as of 2026-05-21 Knowledge-graph recall on Rensei's own production sessions, Cedar-authorized and hash-chain audited MEASURED Provenance UNDER NDA: injection-row and audit-row exports Survival-to-posterior routing wiring: survival rewards join the routing posteriors by decision id, with propensity recorded at decision time for offline evaluation VERIFIED Provenance UNDER NDA: decision-record export (candidates, exclusion reasons, propensity, ruleset revision), available under NDA on request live ranking is org opt-in and kill-switched; unopted orgs route in shadow mode; verified 2026-08-12 Every routing decision, placement and claim, writes a typed decision record: candidates considered, a named exclusion reason per rejected candidate, the chosen target, and the ruleset revision it was evaluated against VERIFIED Provenance UNDER NDA: placement-decision record export, available under NDA on request a hosted explain surface walks the same record across all six decision stages; verified 2026-08-12 Fail-static routing durability: the local daemon evaluates a signed, versioned ruleset snapshot, so claims keep flowing through a control-plane outage within a bounded, exposed staleness window VERIFIED Provenance UNDER NDA: ruleset-snapshot compiler and daemon claim-gate source, available under NDA on request failure posture is declared per decision class: permission stays fail-closed against the cached bundle, placement and ranking are fail-static; verified 2026-08-12 SOC 2 Type I ROADMAP Provenance Governor hard-caps and holds ROADMAP Provenance RENDERED: [fail-loop specimen on the evidence page](https://rensei.ai/evidence#fig-fail-loop) loop bounding today is the eight-dispatch cap Interactive sessions attach a live terminal to a running agent session from the web, an iPhone, or an iPad, with the swarm sidebar, host stats, and the agent-to-agent rail VERIFIED Provenance ON REQUEST: live session walkthrough live on the platform; flipped from DECLARED on 2026-09-02 on the founder's confirmation. The platform figure renders a Pi harness on a fictional model, not a customer session An interactive session's terminal stream is recorded as a cast under its org's recording policy, and once the session ends anyone entitled to it can replay the recording in the platform player, with seek, playback speed, and the session record beside it VERIFIED Provenance ON REQUEST: recorded session replay walkthrough part of interactive sessions since they launched in summer 2026 and used daily. Recording is an org entitlement with a per-session policy (org default, opt out, retained) and a per-plan retention window; the player is the web view, and the CLI tails a finished recording as text. Checking replays into a durable evidence store and learning over them is roadmap. The platform figure replays a fictional session Agents coordinate with each other over the A2A protocol across session, harness and model boundaries: tested across Claude Code, Codex, Pi, Antigravity and OpenCode, on Anthropic, OpenAI, Google, the Vercel AI Gateway, Z.ai, xAI and local models VERIFIED Provenance ON REQUEST: cross-harness coordination walkthrough live on the platform and stated by the founder on 2026-09-03; the platform figures show the agent-to-agent rail on a fictional swarm. A multiplexer switches a person between sessions; this is the sessions coordinating among themselves A declarative workflow takes a Linear issue from intake through plan, implement, test gate, review and human sign-off to a merged pull request, dispatching each stage to an agent on the routed provider VERIFIED Provenance ON REQUEST: issue-to-merge run walkthrough live for Linear issues; the one place a person acts is the sign-off gate, and that ruling lands on the audit chain. The platform figure replays a fictional run GitHub Issues, Jira and Asana as issue sources for the same workflow IN INTEGRATION Provenance GitHub Issues partial, Jira and Asana early, as of 2026-09-03; Linear is the verified source above A user-scoped inbox lists every session a user is entitled to see across orgs and projects, in creation order with urgency by badge, a needs-you tray, and batch approval ROADMAP Provenance RENDERED: [inbox specimen on the platform page](https://rensei.ai/platform#fig-inbox) design ruled 2026-08-14 (single partition, positions hold until filed); ships with the unified session stream On-prem deployment ROADMAP Provenance FETCHABLE: [/security#deployment](https://rensei.ai/security#deployment) Rensei deliberately publishes one [redacted signed sample](https://app.rensei.ai/.well-known/audit-sample) from its own platform for account-free offline verification. It includes a key-discovery link and a copy-pasteable verification command. It is a public example, not a complete chain export or evidence of continuous monitoring coverage. The [verification protocol and key catalog](https://rensei.ai/.well-known/audit-keys.json) describe the workspace-scoped key path. Signature presence and verification are distinct: the signature is the evidence to check, and checking it is a separate step. Authenticated audit reads use application-level organization/workspace authorization and query filtering. Project filtering is route-dependent and applies only on routes that accept project scope. These audit-read routes are not Cedar-gated, and this page does not claim production database RLS as their live runtime enforcement boundary. 02 · DERIVATION ## Four primitives, derived. Cedar policy enforcement, hash-chained audit, fail-closed egress, and decision provenance are properties of a deterministic execution graph. None of them is a module that could have been left out. ### Cedar policy enforcement Declarative workflows compile to a durable execution graph, and every outbound tool call in that graph passes a Cedar policy-enforcement point before egress. Coverage is fixed at compilation; a step cannot route around a check the graph places in its path. ### Hash-chained audit Entries produced by the current append path link each entry hash to the prior hash and carry per-workspace Ed25519 signatures. Retained history can include legacy unsigned entries. A holder can recompute a supplied segment and check signatures where present against published keys. That establishes tamper-evidence for the checked segment. It does not establish capture or full-history completeness or truth at capture. External timestamp anchoring is not part of this published proof. ### Fail-closed egress A missing or failed policy ruling denies by default. The enforcement point lives in the execution path itself, so an unreachable policy engine stops state-modifying calls rather than waving them through; observation-only reads proceed and land on the audit chain. ### Decision provenance Every action binds model version, prompt, context, and policy ruling into a signed decision record. When models are nondeterministic, that binding is what makes a decision reconstructable. The derivation is the public answer to how this is different. LLMs run as bounded operators inside workflow steps; the control loop is deterministic code. When the control loop is instead a model that can rewrite the steps it is about to run, the record of what ran is only a claim: tamper-evident audit requires a loop that cannot edit its own history. A deterministic graph forecloses that failure structurally. The structure that executed is the structure that was reviewed, and the chain that recorded it sits outside the reach of the thing it records. 03 · VERIFY THIS PAGE ## This page can prove itself. At build time, a script canonicalizes each chapter of this page: the rendered text plus, in order, every link target and image reference, normalized and whitespace-collapsed. Each chapter record hashes with the record before it, the doc strip under the navigation is the genesis record, and the page hash in the footer commits to all of them. The full construction, and what each verifier outcome means, is published on [the verification method page](https://rensei.ai/verify) . The chain proves the prose, links, and figures you received are the ones that were built, complete and in order. It does not prove the claims true. The ledger above does that. Hash-chaining this page took a build script. A SOC 2 takes an auditor, and its status is printed in the ledger above as ROADMAP. The verifier source is MIT licensed and runs against this site's own pages. 04 · SEED PLAYGROUND ## Determinism you can poke. The strand below is a pure function of its seed. The default seed is this page's own record hash. Change it, re-render, change it back: the render is reproduced exactly. The same property holds for workflow runs: graph, state transitions, and policy evaluations are deterministic and replayable. The strand generator is MIT licensed and ships alongside the verifier. 05 · SPECIMENS ## Rendered artifacts. The platform components run in your browser over declared demo data. These figures are the page's RENDERED provenance class. FIG 5.0 *FIG 5.0 - Thompson posteriors per provider and work type. Survival-to-posterior wiring: verified, decision-id joined.* Figures are live component renders, not screenshots. Demo data. Per-line provenance and survival measurement are live: survival rewards join the routing posteriors by decision id, with propensity recorded for offline evaluation. Live ranking is org opt-in and kill-switched; unopted orgs run in shadow mode. FIG 5.1 *FIG 5.1 - Code-survival scorecard, 30-day window, hot-weighted.* FIG 5.2 *FIG 5.2 - Hash-chain verification with one expanded decision-provenance row. Mock hashes.* FIG 5.3 *FIG 5.3 - A step fails, the loop retries, the cap holds. The rendered artifact for the governor-caps ledger row.* 06 · VELOCITY ## Built at pace. The git history is the record. 07 · RUN YOUR OWN ## Bring your own benchmark. The most credible number for your evaluation is one produced on your workload. We run scoped benchmark engagements under NDA: a workload you define, a written methodology your team can check, and a measured result you keep. Disclosure stays in your hands; nothing is published without your sign-off. Start [below](https://rensei.ai/evidence#contact) . 08 · CONTACT ## Request the artifacts. Artifacts under NDA ship on request. Every request for the artifacts gets a reply. --- Canonical: https://rensei.ai/evidence Site index: https://rensei.ai/llms.txt Docs: https://rensei.ai/docs OpenAPI: https://rensei.ai/openapi.json