Discuss your stack

One action, from proposal to record.

When connected to its backend, the room on the home page demonstrates one kind of action: a change to a record. This page explains how the decision point checks a proposal against a human-issued permit, how the gate enforces the signed decision and how it records the outcome.

For the wider company and its integration surfaces, read Platform and Developers. The demonstration’s control requirements are explained on our ECL-1 page. Not sure you need a gate? See who it is for.

The parts

The register
The demonstration’s list of allowed field changes: some are within the standing permit, some require an explicit permit request from the visitor, and some are never permitted. The web room enforces these choices through the permits it can issue. The separate workflow planner records your intended rules; it does not configure this gate or issue a permit.
The permit
One agent, one set of records, named fields, a counted number of uses, a validity window and a reason, written on the policy plane. The backend allows one active permit per agent at a time. That limit does not resolve a lost reply or prove which permit a signed decision refers to. A one-use permit replaces the standing permit. The standing permit does not return automatically; the visitor must request it again.
The gate
The enforcement point. The agent’s proposal arrives here first. The gate asks the decision point, receives a signed decision, and only then acts. Admitted actions carry a single-use authority that is consumed on release. Denied actions produce a record and nothing else.
The stop
Stop-work authority for a whole tenant. While it is pulled, every proposal is denied with a signed record. Releasing it is a separate act by an authorized person. On this site’s shared demonstration tenant, the stop also releases itself after 45 seconds.
The record
A bundle of signed envelopes. An admitted action includes the request, decision, consumption of its authorization, release and terminal state; a refusal includes the events applicable to that path. Anyone with the bundle and a trust policy can verify it offline, with no call to G-14. On this site the trust policy names the pilot’s public test keys, so verification does not establish who produced it.

The path of one action

This is the sequence the room on the home page runs when it is connected, step for step.

The path of one action through G-14An agent proposes an action to the G-14 gate. The gate asks the decision point, which checks the permit in force, the permits your people issued and the stop-work state. An admitted action reaches your system of record; a denied one stops at the gate. Every decision, admit or deny, is written as a signed ECL-1 record. A compatible verifier can check it under a chosen trust policy.admitdeny: stops hereevery decisionYour AI agentproposes one actionThe G-14 gateenforces the signed decisionYour system of recordchanges only on admitDecision pointchecks the permit in forcePermitsissued by your peopleStop-workhalts everything in scopeSigned evidenceone record per decisionCompatible ECL-1 verifierthe open ECL-1 tools, offlineThe path of one action through G-14An agent proposes an action to the G-14 gate. The gate asks the decision point, which checks the permit in force, the permits your people issued and the stop-work state. An admitted action reaches your system of record; a denied one stops at the gate. Every decision, admit or deny, is written as a signed ECL-1 record. A compatible verifier can check it under a chosen trust policy.Permitsyour people issueStop-workhalts all in scopeDecision pointchecks the permit in forceYour AI agentproposes one actionThe G-14 gateenforces the signed decisionYour system of recordchanges only on admitSigned evidencecheck with an ECL-1 verifieradmitdeny: stopsevery decision
  1. The agent proposesThe agent sends the gate a proposal: this record, this change, its own reference for the attempt, and the record revision it read.
  2. The gate records the requestThe gate writes the request down and signs it, then asks the decision point.
  3. The decision point decidesThe decision point finds the one active permit for that agent in that tenant. No permit: denied. Record or field outside the permit: denied. Uses spent, window closed, permit revoked, stop pulled: denied, each with its own reason code. Otherwise: admitted, with a single-use authority bound to exactly this action.
  4. The gate releases, or does notThe gate consumes the authority and applies the change, checking the revision so a stale read cannot overwrite newer work. It must release within a declared bound after admission, 250 milliseconds here, and inside the authority’s validity window, or the action does not run.
  5. The gate signs the outcomeThe gate signs the terminal event: carried out, or not, and why.
  6. The record is kept and returnedThe bundle is returned to the caller and kept in the evidence store, which the gate can only append to.

Name the work. Bound the authority.

A permit-to-work names the job, the isolation, the window and the people responsible. A software permit applies the same discipline to an agent and the records it may change.

From a permit to a declared boundaryAn illustration compares a permit-to-work form with a declared register entry. The form names a permit, job, isolation points, validity window, issuer and worker. Dashed lines connect that named work, scope, window and responsibility to a register entry for a case record that needs a permit. This is a comparison of the disciplines, not a live permit or a signed issuance record.Permit to workThe same discipline, in a registerPermit no.PTW-014JobUpdate a case recordIsolation pointsCase 4471, credit statusValid from14:00 UTCValid until14:10 UTCIssued byNamed supervisorAccepted byNamed workerWork and isolationValidity windowResponsibilityUpdate credit statusCase 447114:00 to 14:10 UTCNamed supervisorNamed agentNeeds a permitFrom a permit to a declared boundaryAn illustration compares a permit-to-work form with a declared register entry. The form names a permit, job, isolation points, validity window, issuer and worker. Dashed lines connect that named work, scope, window and responsibility to a register entry for a case record that needs a permit. This is a comparison of the disciplines, not a live permit or a signed issuance record.Permit to workPermit no.PTW-014JobUpdate a case recordIsolation pointsCase 4471, credit statusValid from14:00 UTCValid until14:10 UTCIssued byNamed supervisorAccepted byNamed workerOne declared register entryWork and isolationValidity windowWho can permitAgentCredit statusCase 447114:00 to 14:10 UTCNamed supervisorNamed agentNeeds a permit
This is an analogy, not a live permit. Pilot permits name agents, records, fields, uses and time. The pilot does not produce a signed record of permit issuance.

When actions aren’t API calls

The gate accepts typed, declared operations: this record, this field, this value. Today the pilot governs records.update. It does not govern arbitrary shell commands, SQL queries or browser sessions.

For a free-form agent, the integration must keep system credentials away from the agent and put the gate where its proposed effects leave. The system receiving those effects must refuse a path that bypasses the gate.

Within this action boundary, a jailbreak can change what the agent asks for. It can’t widen the permit or get past the gate’s checks.

When something is wrong

The decision point is unreachable
The gate denies the action with the reason code dependency-unavailable and records it. An agent never gains authority from an outage.
The record changed under the agent
Denied, revision-conflict. The agent must read again and propose again.
A permit is revoked
A proposal that relies on the revoked permit is denied. Work resumes only under a newly issued valid permit. When the room is connected, try Revoke.
A permit’s uses are spent
Denied, quota-exhausted. Each admitted action also receives a separate single-use authorization, consumed on release. That consumption event is not a signed usage ledger for the standing permit.
A field marked Never in this workflow
No permit can name it. On this site the register is enforced where permits are written: the site refuses to write such a permit, and the gate denies the field because no permit covers it. The policy plane does not yet enforce the register itself.
Someone changes the signed evidence
If the bytes covered by a signature change, that signature no longer verifies. The verifier identifies the affected envelope. Try it on the verify page.

Where it fits

The gate is an HTTP service in front of one action class at a time. The backend behind this site exposes one action class, records.update: a field-level change to a record in a system of record, with optimistic concurrency. For an action-control integration, wire the agent and receiving system this way: the agent calls the gate instead of the system, and you set the system to accept changes only from the gate. That last step is yours, and we do it with you. The integration must set and test its timing bounds.

Policy is written through a separate policy plane with its own credentials. Stop-work and revocation live on an emergency plane with theirs. The evidence store is append-only to the gate and read-only to the observer role. The roles separate these responsibilities.

The protocols this demonstration’s gate speaks are the open ones in ECL-1: the decision protocol, the evidence protocol, the integrity envelope and the trust policy. A verifier that implements the applicable protocols can check these ECL-1 records under the chosen trust policy. That does not make it a verifier for every platform authority or evidence object. You can pin the verifier version you reviewed and check the records without depending on our hosted copy.

What is not in the demonstration room yet: the register’s two further classes from the standard, where an action is held until an employee or the customer approves it in-flight, with the approval itself signed into the record. The gate behind this site decides admit or deny today. The pilot does not hold actions for approval today.

Open the dispute casePlan one workflow

Check a record yourself: Verify. Read the rules: ECL-1.