For engineers
Build with reviewed knowledge.
Run the gate. Connect Claude Code. Review in the console.
The SDK checks files offline, without a gate.
Available today: the gate, its console, a Claude Code plugin and the offline SDK. 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.
The standalone doublegate-sdk checks a file against a manifest, the declared checks that file must pass. It runs offline, with no runtime dependencies, and works without a gate. A clean result is evidence for a reviewer and approves nothing.
Install the SDK
Python 3.11 or later. The file loader uses POSIX operations and runs on Linux and WSL. The core starts no service.
Clone the public SDK repository and create a Python environment. The versioned quickstart gives the commands to install and run it.
Its clients for agents and reviewers check the access scope before sending anything. They never send an API key unencrypted off the machine.
doublegate-sdk is a development release.
Check a runbook field
The bundled runbook manifest requires the literal text Owner:. From the SDK repository root, run the versioned example on a runbook with that line and on one without it.
The published runbook quickstart walks through loading the package and checking the file.
A clean result means the literal text is there. Whether the owner is real and the runbook correct is for a reviewer to decide. The gate's policy decides whether that reviewer is a person.
Claude Code connects through a plugin with an agent's permissions
The plugin gives each Claude Code session thirteen tools: remember, record, recall, context, work area, lineage, relate work areas, complete, status, ask, cancel a question, read the questions routed to the crew and answer one. Remember writes a claim, one thing written down for reuse, held until a reviewer other than its author signs it. Only then is it promoted, and other agents' recall, the gate's search, returns it. Record keeps evidence, never graded or recalled.
Work areas and recall
Each session writes into a work area of its own, the named place its claims go. A subagent's area is opened from the session's. By default, recall searches the session's own work area, then each area above it, and stops at the first that has an answer. It never searches a sibling, such as an earlier session's area. So a new session finds an earlier session's promoted claims only when it recalls across the space, or when the two areas are related.
When it recalls
The plugin recalls when the model calls recall. Recall before every prompt and at a session's start is on the roadmap. The gate's built-in plugin recalls on every prompt and is being retired. Install one or the other.
Session records and the librarian
Hooks record the session as evidence at its start, before Claude Code compacts the conversation, and at its end. They run silently and never block the session. A librarian subagent writes what a task learned as derived facts: claims that cite their sources. With no gate configured, every tool answers that the gate is unavailable, and keeps nothing.
Who it acts as
The plugin offers only an agent's acts: it writes and recalls, and never promotes, signs, rejects, demotes or hides. On one machine, the operating-system user that runs the gate is its administrator over the local socket. If Claude Code runs as that same user, as it does when one person starts both, its shell can promote what its own session wrote. The plugin's API key does not change that.
To hold Claude Code to an agent's acts, run it as another operating-system user. Give the plugin an agent-role API key over the gate's loopback address. A gate that runs under a service user of its own is on the roadmap.
A reviewer or administrator creates the plugin's agent-role API key on the console's Access page, which shows it once, beside the plugin's setup. A marketplace entry for the plugin is on the roadmap.
People review in a console on the gate's machine
Sign in through the organization’s identity provider or the gate's own sign-in, in one of four roles: reader, agent, reviewer, admin. Programs hold API keys, which are shown once and stored as a hash. With the gate's own sign-in, a reload keeps the session signed in.
The console holds the review queue, work areas (topology, relation graph, work graph), activity, a recall bar, status, access, settings an administrator can save, and a manual. One Live switch keeps every page current. Every page fits a phone and follows the device’s light or dark setting.
In the console a reviewer signs, rejects, defers, demotes and comments. Hiding a claim is done through the gate's API or its command line. The console uses the spaces that exist; an administrator creates new ones through the API.
The relation graph's 3D view needs WebGL. Its List view serves a keyboard and a screen reader.
The console and every data route answer only on the gate's machine, with no TLS and no network surface.
Three ways to connect
The SDK, the gate and the plugin are separate pieces. Installing the SDK starts no gate and connects no agent.
Check a file offline
Check a file against a manifest with the SDK. Keep what it finds as evidence for the reviewer, together with the manifest's input limits and its review policy.
SDK manual and limitsConnect Claude Code
The plugin runs over the SDK alone. It gives each session an agent's acts in a work area of its own. Sessions write into main, the space a new install has, unless the operator sets another. An administrator creates any other space first, and the gate refuses a claim that names an unknown one.
The Claude Code pluginSpeak the agent-tool protocol
The gate speaks the Model Context Protocol over stdio and HTTP POST, request and response only, with no streaming. It takes the caller's identity from the connection and refuses a request that names an author. The protocol's own reference client connects to the gate's built-in plugin, which is being retired, with no change to its code.
Current interface snapshots
The gate holds, stores and serves the claims written through it. One gate process writes the journal, the signed record of every decision, under one lock. A second gate process started on the same store is refused, and nothing in the store is lost.
The gate calls only the grading model the operator chooses and the sign-in provider the operator names. Two separate programs extend it, each under an API key of its own. The notifier follows the journal and sends a note, never the content, to a file, socket, webhook or script. The skill watcher reads folders the operator keeps and writes each new skill file it finds for review.
A note says who wrote what kind of claim, and where. A webhook sends that note off the machine. A notifier on a read-only API key reports a promotion, and never the demotion that later takes the claim out of recall.
Repositories, tickets and policy documents stay the systems of record, and a claim can cite them. A signed decision records who signed the claim and why. The signature binds the decision to the claim. It says nothing about whether the claim is true.
The gate keeps three kinds of thing, and their risks differ. Memories hold claims to reuse. Skills carry instructions, sometimes with scripts, that change what an agent does. Records keep events as evidence. Reviewing a skill is separate from permission to run it.
Follow the review lifecycleInterfaces published as data
Four files publish the interface as JSON: the method catalog, the HTTP description, the note schema and the tool schemas of the gate's built-in plugin. The gate answers only the methods the catalog declares. The Claude Code plugin's thirteen tools are listed above and are not in these files. The artifact manifest records the source revision of each file. Begin with the machine-readable index.
| Role | Methods it reaches | Acts it adds |
|---|---|---|
| reader | 24 of 83 | — |
| agent | 37 of 83 | — |
| reviewer | 64 of 83 | promote, sign, reject, demote, hide |
| admin | 80 of 83 | ban |
| runner | 40 of 83 | — |
An agent-role API key reaches 37 of 83 methods, and none of them promotes, signs, rejects, demotes, hides or bans.
Programs follow the gate through an event feed: the journal's events in order, at most 1,000 a call, behind a cursor the gate issues. An event names what happened, never the content.
The gate seals the cursor, so it reveals no positions in the journal. Each answer says when the program has caught up.
The id returned when an agent writes is not a promotion, which is a separate, signed decision.
Plan the deployment, not just the import
Runtime
Python 3.11 or later, with SQLite on local disk. PostgreSQL can hold the views the gate rebuilds from the journal. How PostgreSQL performs at scale is unmeasured. An installable package comes with the Solo release.
Grading
By default the gate sends grading to a model server the operator runs on this machine, at port 11435. With no grading model, every held claim waits for a person. A hosted grading model receives the text with secrets masked. A daily token budget pauses grading when it is spent.
Running it
doublegate doctor names each failure with its fix. The console's Status page shows what waits at each step and the grading budget spent today. An export from another memory tool is imported through the same review as any claim.
Administration and signing keys
Any agent running as the gate's own operating-system user can promote what its session wrote (who the plugin acts as). A lost signing key has no recovery path today. Key rotation and recovery come with the Solo release.
The operator runs the gate on infrastructure the organization controls, and its stores stay there. Operating responsibilities · Identity, retention and governance requirements.
What it costs to run
By default each held claim costs two readings by the grading model. When the gate's policy asks for a person, it also costs that person's time. Every claim kept uses disk, and storage only grows because nothing is deleted. What drives each cost:
- Every event is on disk before the call returns, so the disk caps how fast the gate writes.
- Checking the journal's chain reads every event in it, so the check grows with the journal.
- Each claim holds disk permanently, because nothing is deleted.
- The scanner reads the whole text of every claim written.
- Writing a claim takes longer as the store grows. An index that lowers it is on the roadmap.
Promotion, and rebuilding the views from the journal, take longer as the journal grows. More readers at once lower throughput on SQLite. Fixes for both are on the roadmap.
How to evaluate it on a group’s own work
Start from conventions or runbooks the group owns, with nothing sensitive in them. Run the same tasks through doublegate and the current workflow, with the same source access and review budget. Compare how many tasks each completes correctly.
Count harmful claims promoted, useful claims rejected and claims that went stale. Count any API key used beyond its role, and the time until a correction takes effect. Record failures, reviewer effort and total cost. A clean SDK result proves none of these outcomes.
Release sequence
The steps are listed in the order they ship.
- NowOne gate on one machineHeld claims and the scanner. Grading by a model, by a person in the console, or both. The signed journal. Work areas and lineage. The Claude Code plugin and the console. The notifier and the skill watcher. The offline SDK. Every promotion is marked provisional. How often the grading model is right is unmeasured.
- NextThe Solo releaseInstallable, and restarted if it stops. Backup, restore and export. Signing keys that rotate and recover. Content erasure, with the signed record still verifying. An older version refuses a newer store and says why.
- ThenTeamA group shares one gate over the network, under one review policy.
- LaterA second gateA second, independent gate that countersigns a promotion and lifts its provisional mark.
The Solo release gets a date when it passes its acceptance checks.