Control what AI ships.Prove what reached production.
G-14 governs the software your AI builds and runs, from the proposed change to production evidence. It works under your rules, independently of the AI doing the work.
Plan a read-only first connection with us.
Write down what one AI workflow may do. Free PDF, no sign-up.
Portable evidence: ECL-1 example
OriginalCheck a recorded decision
A public example record. Check it yourself, under its own trust policy: the signing keys and rules accepted for this example.
Verifier: Not checked in this browser.
A passing check shows this record is intact under its included policy. It doesn’t show who issued it, that it’s complete, or that the action happened.
status: "closed"
Action: records.update
- Decision in this record (not verified)
- Allow
(admit)
Inspect the check and its limits
The example uses its included trust policy. Its historical action window is not permission to do anything now. This is a check of example records, not a connection to a live backend.
The control changes one seconds digit in the first signed timestamp of a local copy. The original download stays unchanged. A changed digest can be rejected before a signature is checked.
Example records © 2026 G-14, Inc. Apache-2.0 license. Original bundle source; Policy source; Notices.
Know what changed.
Know what’s running.
An approved pull request isn’t running software. G-14 follows each change from the agent’s proposal through review, release and production, and shows what the evidence establishes at every step, including what is still unknown.
Know what exists
Map the repositories, pipelines and runtime you connect. What G-14 can’t observe is marked unknown, never assumed.
Fictional example- Payments repository
- Mapped
- Nightly batch host
- Unknown
Govern the change
Freeze each proposed change for review, then allow or hold it under your rules.
Fictional example- Agent’s proposal
- Retry fix
- Frozen diff reviewed by
- Payments lead
Control the action
Before an agent acts, check that it’s allowed: the right authority, the conditions you set, and the uses or budget left.
Fictional example- Scope
- Deploy the reviewed payments-service release to production.
- Returned decision
- Allowed under its production permit.
A staging permit can’t cover production.
Establish what’s running
Tell what your pipeline reports apart from what an authorized observer sees running.
Fictional example- Pipeline report, production
- Release
2.14.3sent. - Separate observation, production
- The running artifact matches the reviewed release.
Keep the evidence
Keep records your authorized reviewers can take away and check, using the issuers, keys and rules they choose to trust.
Fictional example- Unknown
- Whether the retry fix changed settlement timing. No observation covers it.
Your first connection
Start with read-only access to one supported repository. The first record identifies the software G-14 could establish and the observations still missing.
Reading your software never grants permission to edit, merge or deploy it.
Put the plan in
your team’s hands.
Give your team a plan they can review: what may happen, what must be true, and who decides.
Free. No account or email.
Fictional supplier-payment example
Release a supplier payment
Ask a person each time. Every condition below must hold.
- More than USD 5,000 and less than USD 10,000
- Bank details are confirmed by an independent call-back
- The supplier account is active when the payment is made
Still to define: approval role, scope, time window, uses and escalation.
The brief records requirements. It does not check real-world conditions or run the workflow.
Does your AI need a gate?
| You need a gate when your agent can | You may not when it only |
|---|---|
| Change a record in your system of record | Answers questions, with no tools |
| Move money or commit you to something | Drafts text a person reviews and sends |
| Send a message or a notice in your name | Summarizes documents for a person to read |
| See or move private customer data | Searches public information |
| Reach new tools or widen its own access | Runs in a sandbox with no path to an outside effect |
| Release code or change production infrastructure | Checks code in an isolated environment without deploying it |
A chatbot that states prices, terms or policy in your company’s name also has consequences. This comparison concerns actions an agent can take. The G-14 platform connects discovery and governed development to production proof and evidence. Plan one action-control workflow to put its requirements on paper.
Control down to
a single action.
Set rules for the action, the object and the exact change. Every applicable limit must allow it. One denial stops it.
- Observe
- Propose
- Build
- Admit
- Promote
- Deploy
- Operate
Permission profiles, from Observe to Operate, group the exact grants for a job. All eleven limits still apply.
A gate only works if it’s the only way in. Establishing and testing that boundary is part of every integration.
Missing or ambiguous authorization blocks a new action. The proposed change is frozen before review. Switching models doesn’t reset its limits.
Integration is part
of the platform.
Keep the repositories, pipelines, clouds and runtime you already rely on. Read-only connection targets include GitHub, GitLab, Azure DevOps, Bitbucket and internal Git. Agree on the supported connections, deployment scope and control boundary for your stack.
G-14’s own AI agents build connector and adapter changes for your stack, inside the platform, as Missions: jobs with a defined scope, tools, time and budget. Your team reviews each proposed change under the same rules and evidence requirements as other work.
Discuss your stackWhere it runs
- Free local gate
- Hosted
- Private execution
- Self-managed
- Sovereign or air-gapped
Supported releases and deployment boundaries are agreed on separately.
Find the right integration pathInspect one runtime boundary.
Play the approver. When the demonstration is connected, an agent works a fictional case, you decide what it may change, and each returned decision comes back as a signed record. This local example uses fictional records and public test keys, and covers record changes only.
The runtime example is not connected here. You can still create a permission brief.
Service checkout-api, production
An alert fires at peak traffic. An agent proposes the fix.
Starting asks the backend to create a fictional record and issue your requested permit.
Declared example scope
This is the setup for a fictional example, not an issued permit. No record values or gate decisions are observed in this view.
- Starting scope
- Open or update the incident; Change the log level
- Needs a permit
- Scale the service; Turn a feature flag off; Roll the configuration
- Excluded
- Change the database schema
Inspect declared example fields
Declared scope
Local runtime unavailable
- Holder
- Assigned on start
- Declared uses
- 50 when issued
- Requested window
- 60 minutes
Declared setup, not an issued permit.
What this shows
This list is what the room asked the policy plane for and saw confirmed. It is not signed issuance: the pilot does not produce that record. “Admitted decisions” counts decoded decisions whose signed policy reference names this permit; it is not the gate’s own usage counter.
P1, P2 and so on are local labels for this room’s permits. A label doesn’t make a permit usable or link it to an effect. Each decision drawer separately shows the room association, decoded signed policy reference and verification result.
No room or permit is requested until your explicit start. The requested limits are one fictional record, the starting fields, 50 uses and 60 minutes.
The gate
Every proposed change meets this boundary.
No returned decisions in this view.The protected record
Service checkout-api, production
An alert fires at peak traffic. An agent proposes the fix.
Not observed yet
What this shows
Starting asks the backend to create a fictional record and issue your requested permit. No values have been observed yet.
The signed evidence is the gate’s own report under published pilot test keys. Neither that evidence nor this record view is independent proof that a change happened. Plain values are followed by the exact stored field and JSON value.
| Field | Declared scope |
|---|---|
Open or update the incidentincident | Starting scope |
Change the log levellog_level | Starting scope |
Scale the servicereplicas | Needs a permit |
Turn a feature flag offfeature_flag | Needs a permit |
Roll the configurationconfig_version | Needs a permit |
Change the database schemadatabase_schema | Excluded |
| Field and declared scope | Gate decisions | Observed value |
|---|---|---|
Open or update the incidentStarting scope | No decision returned | Not observed yetincident |
Change the log levelStarting scope | No decision returned | Not observed yetlog_level |
Scale the serviceNeeds a permit | No decision returned | Not observed yetreplicas |
Turn a feature flag offNeeds a permit | No decision returned | Not observed yetfeature_flag |
Roll the configurationNeeds a permit | No decision returned | Not observed yetconfig_version |
Change the database schemaExcluded | No permitted path | Not observed yetdatabase_schema |
records.updateThe evidence
Every decision above came back from the backend as a signed evidence bundle. Check them here with the open ECL-1 verifier, or download each one with the trust policy and check them on your own machine.
Records appear here as the gate decides.
What this pilot protects, and what its evidence means
The gate only protects what it stands in front of. Your receiving system must accept the agent’s effects only through the agreed boundary, without other credentials or access paths around it. Establishing and testing that boundary is part of the integration. Read the demonstration flow and the integration paths.
This local pilot uses published test keys whose private halves anyone can derive. A successful check establishes integrity under that test policy, not that G-14 produced the record. A production deployment needs protected keys and a policy naming them.
When a signed decision bundle comes back, the room lets you inspect it, download it with its trust policy, or package the run for an offline check. Decoding is not verification. Packaging adds no signatures and does not establish trusted time or completeness. Check a bundle you already hold or read the ECL-1 contract and assessment requirements. ECL-1 is the runtime edge, not the whole company.
Start with the software
you already run.
Choose one supported repository to inspect without changing it. Agree on what G-14 can establish first, then decide where control belongs in your stack.