For business / Governance
Every decision is signed into a record an auditor can verify.
Every claim carries its author and every grade and signature on it. The identity that wrote a claim can never approve it.
Follow a claim from its authorRuns today: a signed journal anyone holding it can verify, with the reviewer named on each decision. Next: the Solo release of today's gate, installable, backed up and restorable, with rotating signing keys and erasable content. Then Team, one gate a group shares over the network, under one review policy.
A claim, one thing written down for reuse, is written by an agent, a person or a program the operator runs, each under its own identity. The gate holds and scans it, and promotes it only when a person or grading model other than its author signs it.
No one can write under another’s name. A program proves who it is with its API key, and a person signs in. The gate takes the author from that connection and refuses a request that names an author itself.
While it is held, only its author’s recall, the gate’s search, returns it, marked held. By default one grading model reads each claim twice, once for it and once against, and those two readings can promote it with no person. One setting requires a person for any kind of content.
For every claim, the record answers “Where did this come from?” It keeps the author, the work area (a named place for claims), what the author says produced the claim, and what it derives from.
The gate tells authors and reviewers apart by API key and sign-in. If an agent starts as the gate’s own operating-system user, its shell can promote what its session wrote (how to prevent that). Run the agent as another operating-system user and the rule holds against it. A gate that runs under a service user of its own is on the roadmap. Reading from outside systems is a later step, by a separate program with its own API key.
Say an agent asks the gate for another agent’s held claim by its id. Without the reviewer role, it gets the same answer as for a claim that does not exist. The same holds wherever it looks: by id, in a listing, a count, a refusal, a history or a position in the journal. A caller can still learn four things, and we publish them:
An agent writes through the Claude Code plugin, and a person in the gate’s web console on its machine. The skill watcher writes the skill files it finds. Each claim is held, scanned and reviewed the same way.
Say an agent learns that the payments sandbox rate-limits per API key, and writes it into its work area. Until a reviewer other than the agent signs it, only the agent and the gate’s reviewers can read it (what others can still learn).
What is recorded: the agent’s identity, the work area, what the agent says produced the claim, what the scanner found, the reviewer, and the signature.
A person signed in to the console writes a fact or a correction with its New claim form, into a work area they pick. It is reviewed like an agent’s claim, and its author cannot approve it.
What is recorded: who wrote it, as their sign-in names them, the work area, the claims it derives from, the reviewer, and the signature.
The skill watcher, a program the operator runs under its own API key, finds each new skill file in a folder the operator keeps and writes it into the gate once. A skill changes what other agents do, so the gate scans it for injected instructions, secrets and scripts before a reviewer sees it. The default review can promote it. An imported skill bundle is checked without running anything and stays held: one gate alone never promotes it.
What is recorded: the skill’s exact text, the watcher’s identity, what the scanner found, the reviewer, and the signature.
Each field below is part of the record a reviewer signs. Beside it is the requirement it answers.
track back the source of the issue in a timely mannerand
allow traceability for (external) validation
automatic recording of events (logs) over the lifetime of the system
to obtain human interventionand
to express his or her point of view
maintain a record of processing activities
a single authoritative source for risk data per each type of risk
A rejection produces the same record, kept and signed like a promotion, so the journal shows what was turned down and why.
Every promotion, rejection, demotion and expiry is a signed event with its reason: who decided, when, and on what basis.
Each claim links to what it derives from. When one turns out to be wrong, a reviewer can find what produced it and what else came from the same source.
A correction is a new version linked to what it replaces. So the history of what the organization believed, and when it changed its mind, stays intact.
Recall finds promoted claims with the record of where each came from. Reviewers see every held claim. Recall never returns another author’s held claim.
No product makes an organization compliant. Compliance is the organization’s judgement against a control framework, and doublegate produces evidence for that judgement. Each requirement below is quoted from its source, beside what an auditor can see.
| The requirement, quoted | Source | What an auditor can see |
|---|---|---|
| "rigorous documentation and audit trailing of changes, data overrides and sign-offs" under a four-eyes principle | ECB Guide on effective risk data aggregation and reporting, May 2024 | the reviewer is never the author: the gate enforces it between every API key and sign-in. On one machine it binds an agent that runs under another operating-system user (who writes and who decides). |
| lineage must "in case of data quality incidents be able to track back the source of the issue in a timely manner" | ECB Guide on effective RDARR, May 2024 | every claim links to what it derives from |
| lineage must "allow traceability for (external) validation" | ECB Guide on effective RDARR, May 2024 | a signed journal that an auditor with access to the gate checks with one command. An export for the auditor’s own tools comes with the Solo release. |
| "shall technically allow for the automatic recording of events (logs) over the lifetime of the system" | EU AI Act, Article 12(1) — applies from Dec 2027 (Annex III systems) or Aug 2028 (systems under EU product-safety law) | append-only signed journal, from the first write |
| "shall maintain a record of processing activities under its responsibility" | GDPR Article 30(1) | per claim: the author, the work area, what produced it, its source, the time |
| the right "to obtain human intervention […] to express his or her point of view and to contest the decision" | GDPR Article 22(3) | a record of who decided and why, to support an investigation. A process for a person to intervene and contest a decision is a separate duty of the organization. |
| "strive towards a single authoritative source for risk data per each type of risk" | BCBS 239, Principle 3(d) | one reviewed store per gate, not one per agent |
Grading can run on a model the organization hosts on its own hardware. The operator can require a person for any kind of content, and a model can never overrule a person’s decision.
Every quote above is verbatim from the named source and checked against it. See the full citations →
The record is the journal, kept on the gate’s machine. Each entry is signed and linked to the one before, so a later change shows.
doublegate verify checks every signature and every link in the journal.
A changed field, a removed decision or a reordered event makes the check fail. The check
holds no lock, so claims can still be written while it runs.
doublegate audit prints one claim’s decisions in order, with their
signatures checked.
Both run where the gate runs. An export a third party can verify offline comes with the Solo release, beside backup and restore.
Each decision is recorded with who made it and signed with the gate’s signing key. Checked against the latest entry an auditor holds, a changed or missing entry shows. If the newest entries are cut off, the shorter journal still checks out on its own. Keep a copy of the latest entry elsewhere to catch that. The signature does not make the claim true.
A reviewer signs a record: the claim and its version, the identity behind the decision, and the evidence it rests on. This is how far it reaches today.
A promotion means one gate’s reviewers signed the claim. It stays marked provisional, checked by this gate alone, until a second gate exists. After a demotion, rejection or expiry, recall no longer returns the claim, and its history is kept. A person’s objection stops automatic promotion until it is retracted.
The journal is append-only: nothing written to it is deleted. That conflicts with the right to erasure in GDPR Article 17 until erasure comes with the Solo release.
The gate does not defend against a compromised machine that holds its signing key, or a grading model that colludes with an author. Nor does it defend against side channels, such as how long an answer takes or how much is stored. In each case the recovery is demotion: a reviewer takes the claim out of every recall and keeps it, with the reason. Anyone who can read the journal and guesses a claim’s exact text can confirm the guess. A fix is on the roadmap.
BCBS 239 does not contain the word “lineage”: we found zero occurrences in the 2013 text. So we cite the requirement to the ECB’s 2024 implementation guide, which is where it lives.