ObligationSign
Dashboard Guide · L1 / L2 Tenants
← Open Dashboard

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.

What happens behind the scenes: When you submit a governance request, the clearinghouse evaluates five admission gates against three observable values (Entropy, Compliance, Energy), sends the proof bundle to an independent validator network for approval, and then the ObligationSign operator’s Sovereign Authority device (a hardware-secured phone) signs the record with a biometric-gated key. The signed record is submitted to the transparency log. You receive a permanent leaf index and leaf hash as your receipt.

Your tier: L1 or L2

TierWhat you getSigning
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.
L3 and L4 tiers are for organisations that deploy their own dedicated Sovereign Authority device. Those tiers have a separate operator guide covering device setup and hardware signing. Contact ops@obligationsign.com for details.

Getting started

Enrollment takes about two minutes. You need only a web browser and your email address. No software installation is required.

1
Sign in with your email
Cloudflare Access · one-time passcode
  1. Navigate to the ObligationSign dashboard

    Open obligationsign.com/dashboard/ in your browser. You will be prompted to authenticate.

  2. 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.

  3. 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.

2
Free trial
30 days · no payment required

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.

3
Add payment details (before trial ends)
Optional during trial · required to continue after 30 days
  1. Click “Add payment details” in the trial banner

    Or navigate to the System tab and find the Billing panel. Click Add Payment Method.

  2. 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.

  3. 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.

The three observables: Every governance request is evaluated against three measurable values that describe the AI decision:
  • 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.
A
Option A: Connect tab (streamlined)
Recommended for most L1/L2 tenants
  1. Open the Connect tab

    You will see the “Sign an AI action — live” form.

  2. 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.
  3. 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.

B
Option B: Govern tab (step-by-step)
More control over each stage

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.

GateNameWhat it checksThreshold
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
If a gate fails: correct the underlying value — do not try to work around it. A failed gate means the action does not currently meet the governance protocol’s admission criteria. The gates exist to protect you and your auditors.

Step 2 of 4 — Assemble the proof bundle

  1. 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.
  2. 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

  1. Optionally set the Payload URI

    If you have a storage location for the proof bundle file, enter the URL. Otherwise leave the default.

  2. 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.

  3. 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.

  4. 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.

Record submitted. Your governance record is now permanently in the transparency log. It cannot be altered, deleted, or denied. The record proves that this action was properly authorised, checked by independent validators, and sealed with a hardware-backed signature — all before the AI system ran.
4
Step 4 of 4 — Record execution and compute variance (optional)
Closes the audit loop with Leaf 2 and Leaf 3

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.

  1. 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.

  2. 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.

  3. 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.

Variance classifications:
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

MetricWhat 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:

How independent verification works

  1. Retrieve the record

    Anyone can fetch your governance envelope from the log using the leaf index. The endpoint is public and requires no authentication.

  2. 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.

  3. 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.

For non-technical auditors: share the leaf index and log URL, and open the Compliance & Audit tab in the dashboard. It generates a human-readable compliance report stating, in plain language, which governance claims are satisfied and citing the cryptographic evidence for each.

Troubleshooting

SymptomWhat it meansWhat 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

TermPlain-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.