Summit Cognitive — Proof Mode · Scripted Browser Sandbox

Phase 0 · Day 0 — Pre-install

What exists before Proof Mode: capable agents, unprovable actions

The agent stack already works — a voice or process-automation platform takes intents and drives tools: scheduling, CRM, payments, messaging. What's missing is not capability. It's admissibility: when an autonomous system acts on a business's behalf, nothing in the stack can prove what happened, under whose authority, from what evidence — in a form a third party can check.

VALUE AT THIS STAGE — a scoping exercise, not a build: pick one workflow, list its decision points (every write, charge, or send), and define what each receipt must capture. Half a day with the workflow owner.

RISK IF YOU SKIP IT — agents ship to production on logs alone: mutable, scattered across five systems, silent about authorization. The first dispute, chargeback, or regulator question becomes archaeology — and the answer is “trust us.”

The architecture. Proof Mode inserts one hop: the gate evaluates each claim before the tool executes, and seals the outcome — allowed or not — into an append-only receipt chain.

Integration is one of three thin seams — no re-platforming

Mode	How it works	Fits
SDK wrap	The agent runtime calls gate.evaluate(claim) before each tool dispatch — a few lines at the tool-router layer.	Custom agent stacks, voice platforms
Gateway proxy	Tool traffic routes through a policy-enforcing proxy; agents need zero code changes.	Platforms with a central tool bus / MCP-style tool servers
Webhook gate	The platform posts each pending action to /v1/evaluate and honors the verdict.	Process-automation & orchestration platforms, CI/CD

# the entire integration surface, in one call — production shape
POST https://decrec.summitcognitive.ai/v1/evaluate
{
  "claim":   "Charge $180.00 deposit to card-on-file for WO#4417",
  "entity":  "alpine-peak/payments",
  "agent":   { "id": "PAY-1", "runtime": "voice-stack" },
  "tool":    { "name": "payments.charge", "args_sha256": "9c41…" },
  "sources": [ { "type": "call_transcript", "digest": "b7d2…" } ]
}
# → verdict: ACCEPTED | ESCALATED | BLOCKED  + sealed, chain-linked receipt

Phase 1 · Day 1 — Instrument & set policy

Nine deny-by-default rules, tuned to the client's risk appetite

Policy is configuration, not code. Autonomy caps, data-scope boundaries, approver lists, and confidence floors are set with the workflow owner on day one — and every rule evaluation is itself recorded in the receipt, so “the policy fired” is provable, not asserted.

VALUE AT THIS STAGE — governance becomes explicit and testable. The client can read their own rules in plain language and see exactly what their agent may, must-ask, and must-never do.

RISK IF YOU SKIP IT — “guardrails” live as prompt text and tribal knowledge. Nobody can say what the agent was allowed to do on a given Tuesday, because allowed was never written down.

Rule	What it enforces	Catches, e.g.
R1 identity & decision rights	The actor is verified and holds the right to make this decision on this entity.	Caller fails two-factor identity match → write blocked
R2 source diversity	Consequential actions cite ≥ N independent evidence sources.	A charge justified only by the agent's own summary
R3 provenance integrity	Every cited source carries a digest; inputs are content-addressed.	Evidence edited after the fact
R4 confidence threshold	Model confidence below the floor cannot authorize a write.	Mumbled 8 vs 18 on a call → escalate, don't guess
R5 autonomy cap	Value/action ceilings for autonomous execution; above → human approval.	$180 charge vs $100 cap → escalated with evidence
R6 data scope & sensitivity	Restricted categories (health, raw card data, gov ID) are unwritable by this agent.	“My husband is on home oxygen” never enters the CRM
R7 blast-radius bounds	Rate and scope limits: one call can't touch a thousand records.	Runaway loop mass-updating the calendar
R8 replay determinism	The decision must be re-derivable from recorded inputs alone.	“It seemed right at the time” as a defense
R9 attestation & chain integrity	The receipt seals into the chain; production adds Ed25519 signatures.	Quietly deleting the embarrassing action

Anatomy of a Decision Receipt

Every field exists to answer an auditor's question: who acted, on what authority, from what evidence, with what outcome — and how do I know this record is the original?

Phase 2 · Days 2–30 — Operate

The scripted sandbox: synthetic events, in-memory state, real receipt hashing

Press start. A seeded generator produces synthetic operational scenarios — bookings, reschedules, payment collections, refunds, after-hours dispatches, and attempted policy violations. Scripted actor labels route those events through browser-only JavaScript functions that update the in-memory panels below. Watch the synthetic state and receipt chain change. Change the seed for a different scenario sequence; keep it for a bit-identical one. This demonstrates deterministic policy and hashing mechanics, not autonomous-agent or external-tool execution.

VALUE AT THIS STAGE — the viewer can inspect governance logic on synthetic traffic: every scripted action is countable, simulated escalations are visible, and disallowed in-memory writes fail safe. This is a mechanism demonstration, not a production result.

RISK WITHOUT IT — the pilot's only artifact is a demo call and a feeling. Nothing accumulates; the security review restarts from zero each time someone new asks.

seedⓘ reproducible

Receipts sealed

Accepted

Escalated

Blocked

Scenarios handled

—

Chain status

Simulation feed — scripted actors processing synthetic traffic

SANDBOX

Idle. Press Start scripted traffic — synthetic scenarios will update the in-memory state below.

Receipt chain — sealing in realtime

LEDGER

Every gate decision appears here, hash-chained to the one before it. Click a receipt to inspect the full sealed record.

Synthetic in-memory state — these panels are updated only by browser JavaScript

SCHEDULING — week grid ● IN-MEMORY

CRM — customer records ● IN-MEMORY

PAYMENTS — ledger ● IN-MEMORY

COMMS — outbox ● IN-MEMORY

Phase 3 · Any day — Prove

Attack the record. It defends itself.

A control you can't test is a promise. Everything here operates on the chain sealed above — recomputing real hashes, in your browser, with no Summit service in the loop.

VALUE AT THIS STAGE — verification is a customer capability, not a vendor claim. Hand the exported ledger to an auditor, a client, opposing counsel — they can check it without trusting anyone.

RISK WITHOUT IT — whoever holds database access holds history. Insider edits, retention gaps and “log cleanup” are undetectable by design.

① Verify the chain

Recompute every receipt hash from contents; confirm each link points to its predecessor.

Seal some receipts first — run the sandbox above.

② Tamper test

Rewrite history — change any sealed field. The chain breaks at that receipt and everything downstream becomes unprovable.

Receipt New value for its primary field

Awaiting sealed receipts.

③ Export the ledger

The whole chain as portable JSON. This file is the audit artifact — anyone can re-verify it with ~15 lines of code in any language.

Awaiting sealed receipts.

# independent verifier — no Summit code required
for r in ledger:
  assert sha256(canonical(r minus hash)) == r.hash
  assert r.prev == previous.hash

Phase 4 · Month 6+ — Recall & audit

“Show me everything about that charge in July.”

The question always comes later — a chargeback, a complaint, a regulator, a discovery request. Query the ledger you sealed above like an auditor would: filter to the action, open its dossier, walk its evidence chain, and replay the decision from recorded inputs to prove the system would decide the same way again.

VALUE AT THIS STAGE — minutes to a complete, self-proving dossier: the action, its authority, its evidence digests, its policy evaluation, and a live replay match. Disputes end here.

RISK WITHOUT IT — reconstruction from fragmented logs, months later, by people who weren't there — presented to skeptics with no way to prove the record wasn't curated.

Tool

Verdict

Free text (customer, WO#, claim)

Seal some receipts first — run the sandbox above, then come back as the auditor.

Dossier

Evidence & custody chain

Replay pending…

The sealed record

Where this sits

A governance layer for every stack that lets agents act

Proof Mode is infrastructure, not an app: it sits between “the agent decided” and “the system did,” wherever that seam exists. The sandbox above is a service-business voice workflow — the same gate-and-seal pattern applies unchanged across:

Voice-agent platforms

Bookings, CRM writes, payments taken on calls — the adoption blocker is defensibility; receipts remove it.

Process-automation & orchestration platforms

Agentic steps inside regulated business processes get per-action verdicts and audit-ready evidence — the artifact compliance teams currently ask for and don't get.

Enterprise agent fleets

Multi-agent systems with tool access at scale: autonomy caps, blast-radius bounds, and one chain of custody across all of them.

CI/CD & software agents

The live production system gating autonomous code-change decisions today — see the ledger link below.

What the receipt chain gives your compliance story

Receipts are evidence artifacts, mappable to the controls your customers already audit against: change-management and logging controls in SOC 2 and ISO 27001, the govern/map/measure functions of the NIST AI RMF, and record-keeping, human-oversight and traceability obligations for high-risk systems under the EU AI Act. The pilot's verification pack includes the control mapping for the instrumented workflow.