Dashboard Guide
This guide is for L1 L2 tenants — organisations that use the ObligationSign clearinghouse to create provable governance records for AI systems and automated decisions. You do not need your own signing hardware or cryptographic expertise. The ObligationSign Sovereign Authority signs every governance envelope on your behalf.
What is ObligationSign?
ObligationSign is a governance service that creates tamper-evident records proving an AI action or automated decision was properly authorised before it ran. Each governance session produces a Governance Envelope — a cryptographic record of who authorised a decision, what checks passed, and the hardware-backed signature that seals it. That record is then written to a public Transparency Log: an append-only ledger that anyone can verify, but nobody can alter.
Think of it as a notarised audit trail on a public ledger. The notary is a dedicated signing device operated by ObligationSign, and your organisation’s record is permanently linked to its place in the log.
Your tier: L1 or L2
| Tier | What you get | Signing |
|---|---|---|
| L1 | Full dashboard access, transparency log entries, cockpit monitoring, compliance reporting. 30-day free trial included. | ObligationSign Sovereign Authority signs on your behalf. |
| L2 | Everything in L1, plus higher event volume, priority validator processing, and extended audit reporting. | ObligationSign Sovereign Authority signs on your behalf. |
Getting started
Enrollment takes about two minutes. You need only a web browser and your email address. No software installation is required.
-
Navigate to the ObligationSign dashboard
Open obligationsign.com/dashboard/ in your browser. You will be prompted to authenticate.
-
Enter your email address
A one-time passcode is sent to your inbox. Enter it on the next screen. This is your identity for the clearinghouse — all governance records will be linked to this email.
-
Automatic enrollment
On first sign-in, the clearinghouse automatically provisions your tenant. You will see a green banner confirming your free trial is active. An API key is generated and stored in the Connect tab.
Your L1 free trial begins immediately. During the trial period, all governance features are fully available. Usage is tracked but not billed. A banner at the top of the dashboard shows how many days remain.
-
Click “Add payment details” in the trial banner
Or navigate to the System tab and find the Billing panel. Click Add Payment Method.
-
Complete the payment form
You are redirected to a secure payment page. Enter your card details. You will not be charged until the trial ends.
-
Return to the dashboard
The billing panel will show your payment method is saved and your tier is L1 — Active.
Dashboard tour
The dashboard is organised into ten tabs across the top. Here is what each one does.
Overview
A summary of your tenant’s current state: trust score, decision counts (admitted, refused, quarantined), validator health, leaf count, and a protocol timeline showing how each governance request flows through the five gates and into the log.
Connect
Where you submit live governance requests. This is the primary action tab for L1/L2 tenants. You enter the three observable values (H, C, E), a subject ID, operator ID, and evidence class. The clearinghouse evaluates the five admission gates, runs the validator network, and signs the record on your behalf. Your API key and tenant configuration are also displayed here.
Govern
A four-step governance workflow for building and submitting governance envelopes with more granular control. Step 1 evaluates the five admission gates. Step 2 assembles the proof bundle. Step 3 signs the envelope and submits to the log. Step 4 (optional) records execution-time state and computes variance for the closed-loop audit trail.
Cockpit
A live operations view showing your governance activity in real time. Displays your tenant-scoped log size, quorum status, admitted/blocked/quarantined counters, a Merkle tree visualisation, trust dial, governance topology map, and a scrolling event stream. Everything shown is scoped to your tenant.
Compliance & Audit
Generates human-readable compliance reports based on your governance records. Shows which of the AGTS compliance claims are satisfied and cites the cryptographic evidence for each. Useful for sharing with auditors and regulators.
Chain
A detailed view of the transparency log. Browse your log leaves, inspect individual governance envelopes, view inclusion proofs, and verify the Merkle chain integrity.
Settlement
Usage metering and settlement details. Shows your governance event count, billing period, and per-event pricing based on your risk tier.
System
Billing, validator registry, module health, and identity configuration. The billing panel shows your current tier, payment status, and trial countdown. The validator registry shows which independent nodes are online and their roles.
Readiness
A pre-flight checklist for your governance setup. Shows whether your tenant is properly configured, validators are reachable, and the log is accepting submissions.
Policy Sandbox
A testing environment where you can simulate governance requests with different H, C, E values and see how the gates would evaluate them — without submitting a real record to the log. Useful for understanding the admission thresholds before going live.
Apps
Plugin extensions that add domain-specific governance capabilities. Plugins can provide specialised gate checks, evidence collection, or reporting for particular industries or use cases.
Submitting a governance request
A governance session creates a permanent, tamper-evident record of an AI action or automated decision being authorised. There are two ways to submit: the Connect tab (streamlined, recommended for most L1/L2 tenants) or the Govern tab (step-by-step, more granular control). Both produce the same governance envelope.
- H — Entropy: information-theoretic entropy of the decision process. Higher H means the system considered more alternatives before deciding — a sign of deliberation, not snap-judgement.
- C — Coherence: reasoning alignment score. Higher C signals stronger coherence across the decision envelope.
- E — Energy: computational energy the system expended. Lower is better — high E signals runaway computation or instability.
-
Open the Connect tab
You will see the “Sign an AI action — live” form.
-
Fill in the required fields
- Subject ID — a unique identifier for the entity or decision your AI system acted on (e.g. user:alice:loan-decision-042).
- Domain / context — optional tag to categorise the decision (e.g. credit-risk, medical-triage, content-mod).
- H — Entropy — minimum 0.40 to pass gate G1.
- C — Coherence — minimum 0.40 to pass gate G2.
- E — Energy — maximum 0.60 to pass gate G3.
- Operator ID — the person authorising this decision (e.g. your email). Required for gate G5.
- Evidence class — how governance evidence was collected. Required for gate G4.
-
Click “Submit Governance Request”
The clearinghouse evaluates all five gates, runs the validator network, signs the envelope via the Sovereign Authority, and submits it to the transparency log. You receive a leaf index and leaf hash as your permanent receipt.
Step 1 of 4 — Evaluate admission gates
Five independent gates determine whether the proposed action is admissible. All five must pass before the proof bundle can be built.
| Gate | Name | What it checks | Threshold |
|---|---|---|---|
| G1 | Semantic Validity | Entropy (H) — the information-theoretic diversity of the decision process. Ensures the system deliberated sufficiently before deciding. | H ≥ 0.40 |
| G2 | Financial Validity | Coherence (C) — reasoning alignment score. Verifies financial governance coherence across the decision envelope. | C ≥ 0.40 |
| G3 | Operational Validity | Energy (E) — the computational cost of the decision. Ensures resource expenditure remains within operational bounds. | E ≤ 0.60 |
| G4 | Policy Admission | Evidence integrity — verifies that all four artifact hashes (dataset provenance, evaluation trace, ablation log, capability certificate) are present and the evidence class (HOOKED, ATTESTED, or INSTRUMENTED) is valid. | All hashes present + valid class |
| G5 | Cryptographic Finalization | Human authorization — confirms a named operator is accountable for this governance decision. The operator ID is committed to the Ed25519-signed Merkle proof. | operator_id required |
Step 2 of 4 — Assemble the proof bundle
-
Fill in the bundle fields
- Subject ID — a unique identifier for the AI system or decision being authorised (e.g. model-deployment-20260322).
- Capability Certificate ID — SHA-256 hash of the capability certificate, if your organisation uses them. Otherwise leave blank.
- Deployment Artifact Hash — SHA-256 hash of the model weights or deployment package. Otherwise leave blank.
- G4 Evidence Class — HOOKED (live human-in-the-loop), ATTESTED (operator recorded), or INSTRUMENTED (automated pipeline).
- G5 Operator ID — the person authorising this decision.
-
Click “Build Proof Bundle”
The dashboard assembles the proof bundle — a cryptographic record of all gate results, evidence, and operator identity. An artifact hash appears as the bundle’s fingerprint. Step 2 turns green.
Step 3 of 4 — Sign envelope and submit to log
-
Optionally set the Payload URI
If you have a storage location for the proof bundle file, enter the URL. Otherwise leave the default.
-
Click “Build Envelope + Run Validators”
The clearinghouse packages the proof bundle into a governance envelope and sends it to the independent validator network. Four validators each review the bundle against their own policy rules and cast an ACCEPT or REJECT vote. A quorum of three out of four approvals (including at least one regulator or auditor) is required.
-
Sovereign Authority signing (automatic for L1/L2)
The ObligationSign operator’s Sovereign Authority device signs the envelope on your behalf. This is a hardware-secured, biometric-gated signature from a dedicated device. You do not need to do anything — the signing is handled by the clearinghouse.
-
Click “Submit to Log”
The fully signed governance envelope is submitted to the transparency log. You receive:
- Leaf index — the permanent position of your record (e.g. leaf #12).
- Leaf hash — the unique fingerprint of this entry.
These are your permanent receipt. Save them for your records.
After the AI system has actually run, you can record what happened and compare it to what was authorised. This creates a complete closed-loop audit trail — the Triple-Leaf Ledger.
-
Set the execution-time observables
After the AI system runs, adjust the H (Entropy), C (Coherence), and E (Energy) sliders to reflect the actual measured values during execution. These may differ from the authorisation-time values.
-
Click “Record Execution → Leaf 2”
This submits the execution trace to the log as Leaf 2, linked to your original authorisation record (Leaf 1) by its leaf hash.
-
Click “Compute Variance → Leaf 3”
The dashboard calculates the distance between what was authorised and what actually happened. The variance record is submitted as Leaf 3.
NOMINAL — execution matched authorisation closely (L2 distance ≤ 0.05).
DRIFT — moderate deviation detected (0.05 < L2 distance ≤ 0.20).
BREACH — significant deviation from authorised parameters (L2 distance > 0.20).
Reading the Cockpit
The Cockpit tab is your real-time operations view. Everything shown is scoped to your tenant — you see only your own governance events, not those of other organisations.
Metrics strip
| Metric | What it shows |
|---|---|
| Log Size | The number of leaves in the transparency log that belong to your tenant. Each governance session creates one to three leaves (authorisation, execution, variance). |
| Quorum | The number of validators currently online out of the total registered (e.g. 4/4). Three of four must approve each request. |
| Variance | The classification of your most recent variance computation (NOMINAL, DRIFT, or BREACH). Shows “—” if no variance has been computed yet. |
| Admitted / Blocked / Quarantined | Session counters for governance decisions. Admitted = all gates passed and logged. Blocked = a gate or validator check failed. Quarantined = held for human review. |
Merkle tree visualisation
The tree shows your most recent log leaves and the hash chain linking them. Each leaf node displays its leaf index (L0, L1, L2…) and a truncated hash. The root hash at the top is the current Signed Tree Head of the global transparency log.
Gate pipeline
Five gate indicators (G1 through G5) show the result of the most recent governance request. Green = passed, red = failed, grey = pending.
Trust dial
A composite score reflecting your governance health. It is computed from gate pass rates, validator approval rates, and variance history. A higher score indicates consistent governance adherence.
Governance topology
A 3D visualisation showing how governance requests flow between agent nodes, the clearinghouse, and the validator network. Pulses animate when new decisions are processed.
Event stream
A scrolling log of cockpit events. Green entries indicate successful admissions, red entries indicate blocked decisions, and amber entries indicate quarantined events awaiting human review.
Verifying your governance records
The transparency log is independently verifiable — you do not need to trust ObligationSign to confirm that your record exists and has not been tampered with.
What to share with auditors or regulators
Provide these values from your submission receipt:
- The log URL (the transparency log endpoint)
- The leaf index (which entry in the log is yours)
- The leaf hash (the fingerprint of your specific entry)
How independent verification works
-
Retrieve the record
Anyone can fetch your governance envelope from the log using the leaf index. The endpoint is public and requires no authentication.
-
Check the inclusion proof
The log provides a mathematical proof (an inclusion proof) that your leaf is part of the Merkle tree. This can be verified using standard cryptographic libraries without trusting ObligationSign.
-
Verify the authority signature
The Sovereign Authority’s public key is published. Any verifier can confirm that the hardware-backed signature on your envelope is authentic and was produced by the registered signing device.
Troubleshooting
| Symptom | What it means | What to do |
|---|---|---|
| Email passcode does not arrive | The one-time passcode may be in your spam folder, or the email address may not be authorised. | Check spam/junk. If still missing, contact ops@obligationsign.com to confirm your email is allowlisted. |
| Dashboard shows “No active session” | Your tenant has not been provisioned or your session has expired. | Sign in again via the email passcode. If the problem persists, click “Register New Tenant” in the Connect tab. |
| Trial expired banner appears | Your 30-day free trial has ended and no payment method is on file. | Add a payment method in the System tab → Billing panel to continue using the service. |
| Gate G1 or G2 fails | Entropy (H) is below 0.40 or Compliance (C) is below 0.40. | Increase the H or C value. These thresholds are set by the protocol and cannot be overridden. |
| Gate G3 fails | Energy (E) exceeds 0.60. The decision process consumed too many computational resources. | Reduce the E value to 0.60 or below. |
| Gate G4 fails | One or more evidence artifact hashes are missing, or the evidence class is not recognised. | Ensure you have selected a valid evidence class (HOOKED, ATTESTED, or INSTRUMENTED) and that all four artifact hashes are present. |
| Gate G5 fails | No operator ID was provided. | Enter your operator identifier (e.g. your email address) in the Operator ID field. |
| Quorum not met — validators reject | One or more validators found the proof bundle did not meet their policy thresholds. | Read the rejection reason shown next to each vote. Adjust your observable values or evidence class and rebuild the envelope. |
| “Submit to Log” fails | The transparency log service is temporarily unreachable. | Wait a moment and try again. Your envelope is saved locally and will not be lost. |
| Cockpit shows “0” for Log Size after submitting | The leaf fetch may still be in progress, or the log has not yet indexed the new leaf. | Click “Refresh Log” in the cockpit, or wait for the automatic 30-second refresh. |
| Log Size shows a number followed by “+” | Your tenant has more than 200 leaves. The dashboard displays the first 200 with a “+” indicator. | This is expected for high-volume tenants. All leaves are in the log and verifiable. |
Glossary
| Term | Plain-language meaning |
|---|---|
| Admission gate | One of five automated checks (G1–G5) that must pass before a governance record can be created. |
| Artifact hash | A unique 64-character fingerprint of the proof bundle. If anything in the bundle changes, the hash changes completely. |
| Compliance (C) | Reasoning alignment score. One of the three observables. Higher C indicates stronger coherence across the decision envelope. Gate G2 requires C ≥ 0.40. |
| Energy (E) | Computational energy expended by the AI system. One of the three observables. Lower is better. Gate G3 requires E ≤ 0.60. |
| Entropy (H) | Information-theoretic entropy of the decision process. One of the three observables. Higher H means greater deliberation. Gate G1 requires H ≥ 0.40. |
| Evidence class | How governance evidence was collected: HOOKED (live human-in-the-loop), ATTESTED (operator recorded), or INSTRUMENTED (automated pipeline). Required by gate G4. |
| Governance Envelope | The complete record produced by a governance session: proof bundle, validator votes, and the Sovereign Authority signature. This is what is submitted to the transparency log. |
| Inclusion proof | Mathematical proof that your record is part of the transparency log. Anyone can use it to verify independently. |
| Leaf | A single entry in the transparency log. Each governance session creates one leaf (authorisation). The optional closed-loop flow creates two more (execution and variance). |
| Merkle tree | The data structure linking all log entries together. Altering or deleting any entry changes the root hash, which is publicly monitored. |
| Proof bundle | The cryptographic record of a governance session’s gate results, subject identity, evidence class, and operator identity. |
| Quorum | The minimum validator approvals needed to proceed (3 of 4 by default, including at least one regulator or auditor). |
| Sovereign Authority | The hardware-secured signing device that seals every governance envelope. For L1/L2 tenants, this is operated by ObligationSign. |
| Tenant | Your organisation’s account on the clearinghouse. All governance records, API keys, and billing are scoped to your tenant. |
| Transparency log | The public, append-only ledger where governance records are stored. Verifiable by anyone without trusting ObligationSign. |
| Triple-Leaf Ledger | The optional closed-loop audit trail: Leaf 1 (authorisation), Leaf 2 (execution), and Leaf 3 (variance). Links what was authorised to what actually happened. |
| Validator | An independent node that reviews governance bundles and votes to accept or reject them. Operated by third parties (auditor, regulator, independent, or customer roles). |
| Variance | The measured difference between the authorised state and the actual execution state. Classified as NOMINAL (≤0.05), DRIFT (0.05–0.20), or BREACH (>0.20) based on L2 distance. |
For questions, contact ops@obligationsign.com.