1 · Choose a Scenario
1Pick a proposed action
Six autonomous-agent actions are submitted to Synchronicity as structured facts in a Structured Proposed Action Descriptor. No eligibility outcome is supplied in the request—the versioned policy derives it.
2 · Review the Proposed Action
2The proposed action, in plain language
What this is: the facts the proposing system transmits — the proposing agent, the proposed action, its target and context, and the policy-relevant facts. Why it matters: there is no outcome, verdict, or conclusion field here, just facts. The policy decides what they mean. Every fact below is editable: change one and the dry-run in Step 3 re-evaluates live.
View Structured Proposed Action Descriptor
The exact payload sent to the real API.
3 · Evaluate Against Policy
3Applicable policy and policy version
What this is: the versioned, licensee-authored policy this tenant is
governed by — visible and editable, with its contract_version: 2
eligibility grammar in the open. Why it matters: the outcome is derived by these
rules from the Step-2 facts; nothing is keyed to the scenario name or tenant ID.
(Policy edits here are a dry-run — they never sign or record anything.)
View Versioned Policy
4Evaluate the proposed action
What this is: the real /v2/decide call against the
deployed, versioned policy. Why it matters: the outcome you will see in
Step 5 is produced here, by policy evaluation over the Step-2 facts — it is not
revealed anywhere before this evaluation runs. Fact edits travel with the request;
policy edits stay a Step-3 dry-run.
5Eligibility outcome
What this is: the canonical v2 eligibility outcome — one of
Eligible, Eligible with Conditions, Hold, or Not Eligible
— bound into the signed artifact together with contract_version: 2.
Why it matters: when several rules match, the most restrictive outcome wins; when
no rule matches, the evaluation fails closed to Hold. An action that is Eligible with
Conditions is eligible only when each signed condition is verified; a Hold means
execution must not proceed until the stated condition or uncertainty is resolved; Not
Eligible means the proposed action does not satisfy current policy. In every case
Synchronicity returned an eligibility determination — the downstream execution
system remains responsible for enforcement and execution.
6Constraint or reason trace
What this is: the decisive, signed reason codes (the codes of the rules that support the final, highest-precedence outcome), any signed conditions, and the step-by-step reasoning trace. Why it matters: a decision you can't explain is a decision you can't audit — every outcome names the exact policy constraints behind it.
4 · Inspect the Signed Evidence
7Signed evidence summary
What this is: the Deterministic Decision Artifact, Ed25519-signed and appended to this tenant's tamper-evident evidence chain before it is returned. Why it matters: the signature covers the outcome, the decisive reason codes, any conditions, the contract version, the SPAD hash, and the policy-snapshot hash — the complete input set, not just the answer.
View Deterministic Decision Artifact
The complete signed artifact, including its full signature material.
8Verify and replay
What this is: the trust anchor — independent checks you can run yourself. Independent signature verification can be performed against the published Synchronicity JWKS. Replay re-evaluates the stored SPAD against the stored policy snapshot and compares the reproduced result with the recorded evaluation.
Verify Signed Evidence
Or verify from your own terminal (no service dependency): download the DDA, then run the bundled offline CLI against the public JWKS.
Replay Deterministic Evaluation
Replay demonstrates deterministic reproduction of the evaluation. Replay does not independently verify the original signature.
Developer Details
This page runs only its own code (Content-Security-Policy, nonce-based) — no third-party scripts can inject.
The signing key is pinned by RFC 7638 thumbprint — a swapped key is rejected in your browser. Pinned:
The offline verifier you download is published with SHA-256 — verify the tool itself. (SRI here covers the downloadable artifact; the page's inline assets are covered by the CSP nonce above.)
Point the demo at a different Synchronicity host (leave blank to use this same host; no trailing slash):
↻How it works
- An autonomous system creates a Structured Proposed Action Descriptor.
- Synchronicity evaluates it against versioned policy.
- Synchronicity returns one canonical eligibility outcome.
- Synchronicity issues a signed Deterministic Decision Artifact.
- A separate downstream system verifies the artifact and independently determines whether execution proceeds.
⊚Governance Without Execution Authority
Synchronicity evaluates whether the proposed action is eligible under the applicable policy. It does not initiate or execute the action. The governed execution system remains responsible for verifying the signed artifact, satisfying any stated conditions, and determining whether execution proceeds.
KDH is the architecture licensor, not the regulated party — Synchronicity produces the evidence and controls that help a licensee meet its own obligations in the licensee's own environment.
Run this in your environment
Don't watch ours — run yours. Drop the container in, wire the reference adapter in ≤ 20 lines, point it at a policy template, and get a governed decision on your own machine. Then let's talk.