AI builds the software.
You keep control.
Know what exists. Decide what may change. Keep consequential actions inside your rules. Keep the evidence in your hands.
G-14 is the independent control and proof plane for software built and operated by AI: the layer between AI and your systems that decides what may change and proves what reached production.
See what you have
before AI changes it.
Connect your repositories, pipelines and production systems read-only. See what’s there before you decide what AI may change.
Reading a system does not grant permission to edit, merge or deploy it.
A picture with the gaps left in.
G-14 pins what it imports to exact versions and keeps three things apart: what it observed, what someone declared, and what it couldn’t see. An inventory tells you what exists. What’s running is a separate, later claim.
Your first connection covers one repository, one build path, one artifact registry and one runtime target from the supported list.
Rules for what each object may become.
A test fixture must not become release source just because someone copied or renamed it. G-14 classifies everything it finds: source code, fixtures, evidence, builds, releases, vendor code, private secrets and unknowns, and a copy or rename can’t move anything into a more trusted class.
If a fact is missing, stale, ambiguous or merely asserted, the object is held or refused. G-14 never fills a gap with a guess.
Connection targets include GitHub, GitLab, Azure DevOps, Bitbucket and internal Git, plus artifact registries, CI systems, clouds and clusters. Agree on a supported provider, build path, registry and runtime target for the first connection.
What the importer refuses
The importer refuses unexpected sources, redirects, Git hooks, surprise submodules and special files, and flags unsafe paths such as escapes, symlinks and name collisions. Private secrets never become candidate material, and test fixtures never become release source.
What the first receipt covers
A first estate receipt separates what was observed, what was declared and what remains unobserved. It names the scope of the connection and leaves missing delivery links visible.
The agreed scope covers a repository, build path, artifact registry and runtime target. An inventory receipt does not establish what is running; a production claim needs the relevant deployment and observation evidence.
Code and context over time
Compare code and context as they were when a decision was made with what changed later. Keep what was known, when it applied and when it was recorded separate.
During an investigation, use the recorded context to examine a decision without treating later knowledge as if it was available earlier.
The plan, the change
and the proof stay together.
AI can write a plan, produce code and say the work is done. G-14 keeps those proposals separate from the decisions that accept them.
Agree on the objective, the decision owner and the acceptance requirements first. One dedicated authority in G-14 records the owner’s decisions that accept the plan or mark the work complete, and works alongside your issue tracker. An agent saying “done” never writes that decision.
“Independent” here means separate from the AI, not third-party assessed.
A model’s output is never authority, a decision, release proof or an effect fact.
One change, followed to what ran.
An illustration, not a recorded run. The numbers show reading order.
- 01Exact candidate.
- Before editing, the agent records the scope it intends to change and works in an authorized workspace. G-14 reconciles the actual changes against that scope and freezes the result: the exact bytes reviewed for approval. A later edit creates a new candidate and expires approvals for the changed subject.
- 02The right decision.
- The named authority decides whether this exact candidate may proceed or must wait, using its evidence, policy, environment and configuration. A separately authorized repository adapter performs the merge. Releasing the software takes its own decision.
- 03A separately approved release.
- The exact source and every release member are built, signed and bound to their configuration, then promoted between named environments under separation of duties.
- 04Delivery.
- Where G-14 has authority, a bounded adapter delivers the exact release. Where your own pipeline deploys, G-14 records and observes that deployment, and never claims to have prevented it.
- 05Outside observation.
- Where the platform permits it, a separately administered observer measures what is running. G-14 compares what was qualified, promoted, deployed and observed, and keeps the strongest claim the evidence supports.
A plan isn’t a release, a build isn’t a deployment, and a receipt isn’t proof the effect happened. Each step keeps its own evidence. See the five levels of production claim.
Missions: one authorized job
A Mission is one authorized job with a named scope, workspace and evidence requirements. Before editing, participants publish their intent. They keep up with changes to the source baseline, holds, conflicts and revocation, then report what they actually changed. The work receives an admission decision or a reason for a hold before handoff or closure.
The objective, acceptance criteria, owners and open holds stay attached to the work. Participants exchange identity for a short-lived Mission capability, read only their authorized context and close or hand off with custody and usage receipts.
Independent changes can proceed separately once their required checks pass; conflicts remain held.
Bound the workspace and its tools
A job has named tools, allowed network routes, package policy and CPU, token and spending limits. Just-in-time secret references stay within the authorized scope; private secrets do not become candidate material. Emergency stop remains separate from the agent’s work.
Workspace classes range from unmanaged local work, where environment integrity is unproven, to an air-gapped cell with its own boundary. Importing work cannot create missing pre-edit history.
Follow the records behind a change
G-14 shows how one change connects intent, code, tests, findings, decisions and evidence. That view displays records from the owning authorities without becoming another authority, so an inferred link can’t close a hold.
The eleven limits and seven profiles
An operation must fit all eleven applicable limits, including the organization, job, target, budget and local enforcement rules. A permissive job grant cannot override another limit. Changing the model, provider, session or agent cannot reset inherited budgets or restrictions.
- Platform safety baseline
- Organization policy
- Program policy
- Environment policy
- The Mission’s grant
- The participant’s identity and delegation
- Workspace and tool policy
- What the target system allows
- Remaining budget and action history
- Revocation status
- Enforcement at the target
These seven profiles expand to exact grants. The applicable scope, target, time, budget and reviewer obligations remain explicit.
- Observe
- Propose
- Build
- Admit
- Promote
- Deploy
- Operate
The specialist agent team
Specialists contribute proposals and checks under separate grants. A Reviewer challenges the frozen candidate. A Release specialist assembles the release without authorizing it. The team includes:
- Planner. Proposes the objective, plan and assumptions.
- Architect. Proposes boundaries, contracts, migrations and risks.
- Builder. Changes only the admitted targets.
- Designer. Works against journeys, accessibility and design obligations.
- Reviewer. Challenges the frozen candidate without editing it under the same role.
- Test. Performs the named test obligations.
- Security. Performs the named security obligations.
- Release. Assembles the release set without self-authorizing it.
- Operator. Investigates observed runtime and proposes bounded recovery.
- Arbiter. Resolves only explicitly delegated conflicts, or abstains and escalates.
Roles describe capabilities, not model personalities. Different role names do not establish independently administered identities or assessment.
What a participant can establish about its work
An agent, editor or adapter is labeled by the evidence it can supply about its work. The four assurance classes distinguish continuing coordination, immutable submission, later observation and another authority’s attestation.
- Governed-live
- The participant supplies authenticated intent before editing, keeps coordination current and reconciles its actual changes.
- Governed-submit
- The participant submits an immutable candidate after the work, without claiming coordination before editing.
- Observed
- G-14 receives repository or build-system events after they happen.
- External-attested
- Another authority supplies evidence identified by its issuer.
Governed-live work requires continuing heartbeats and source-baseline refresh. Observation does not establish complete capture, and an external issuer still needs a basis for trust. Importing an external candidate cannot invent its history.
The boundary sits
before the action.
The agent proposes. The right authority decides. A local gate enforces that decision before the receiving system acts.
For privileged operations, a separate runtime authority evaluates each request and issues a short-lived signed capability or a denial. ECL-1, the open standard G-14 wrote, sets requirements for the decision authority, the enforcement point and the portable receipts each action leaves, so other systems can check them.
Execution is a separate event.
An illustration of the path. Each deployment defines its exact boundary and evidence.
Propose
Identify the action, its target and the intended change.
Bound and evaluate
Check scope, consequence, authority and the required readiness inputs.
Review or hold
Ask the named person when the configured rule requires their decision.
Prepare
Prepare the bounded operation without changing the external system.
Release
Require an affirmative, valid decision for this action and its release conditions.
Dispatch
The customer’s host or gateway applies the permitted operation.
Report
Record the result your system reports, kept separate from any independent observation of the effect.
A missing input is never permission. A record that an action was released isn’t proof it succeeded; that takes its own observation.
Where configured, each step is recorded with its authority and result. A recipient with the matching verifier can check those records under the trust policy they choose. A record states what it covers; it doesn’t establish that every step was captured or that an outside event happened.
One amount is not a policy.
Combine exact actions, objects, amounts, required checks, operating state, time and counted uses. Each input needs an owner, a freshness rule and a binding to this exact action.
A fictional supplier-payment rule
- WHENMore than USD 5,000
- ANDLess than USD 10,000
- ANDThe independent call-back is confirmed
- ANDThe supplier account is active
All four must describe this payment and supplier. Exactly USD 5,000 or USD 10,000 does not qualify. Human approval is also required for each payment.
Plan your own conditionsA separate path to stop.
Emergency stop runs on its own control path, apart from everyday policy changes, and can halt one tenant or everything. Revoking a permit, quarantining or canceling a Mission, and pressing an endpoint’s panic key are separate switches. G-14 records when a stop is acknowledged; whether an outside action actually stopped is observed separately.
Govern remote operations, too.
VaultDesk brings the same rules to remote support, for people and AI agents alike. A session is view-only until someone at the device consents. Hands-on control needs approval on the device itself, and every clipboard, file, shell and admin action is gated and logged.
AI agents connect under their own identities with bounded permissions, and masked mode limits what they can see. Sessions leave signed evidence, keys are established with a hybrid X25519 and ML-KEM exchange, and human panic controls stay with the people involved.
The receiving system and the local example
The system receiving the action must accept it only through the gate, and the agent must hold no other credentials for it. A gate can’t close a side door the target leaves open. Freshness, expiry, revocation, concurrent uses and recovery must be enforced at the actual boundary. Without valid authorization, do not start. If a reply is lost after submission, keep the outcome unknown until reconciled; do not blindly replay it.
The local record-update example changes fields in fictional records using public test keys when connected to its backend. It does not demonstrate the separate runtime authority, remote endpoint control, amount/check/state enforcement, governed software development or production deployment. Its halt timing is not a production service-level promise. Read the receiving system’s responsibilities.
Built is not shipped.
Shipped is not running.
G-14 links the accepted change to its build, release decision, configuration, target and what is observed running, and keeps each claim exactly as strong as its evidence.
An old receipt can’t tell you what’s running now. A system saying “done” isn’t the same as seeing it done.
Five levels of claim, weakest first.
They are different strengths of evidence, not steps that must happen in order or a record of a completed run. Evidence for one does not establish the others.
- Declared
- a provider or operator reported a version
- Deployed
- an approved adapter sent the exact release bytes and configuration
- Acknowledged
- the target returned a receipt with a defined scope
- Observed
- an authorized observer separately measured what is running
- Effect-observed
- a separate observation established that the relevant external action happened
G-14 never collapses these states. Where a platform cannot be observed exactly, it says so.
Your pipeline says a release went out. G-14 records that as declared, or as deployed when an approved adapter sent the exact bytes. It calls the release observed only when an authorized observer independently measured what is running.
The records behind a production claim
Each link identifies the exact subject, environment, issuer, method, time and exclusions. Source-to-artifact is not source-to-production. Runtime bytes may not be measurable on every platform; the claim must say so.
Where G-14 does not mediate the external deployment, it can attest and observe within the connected scope rather than pretend it prevented the deployment. Signatures and graph links do not establish missing observations, complete event populations or current truth.
Read the integration’s evidence obligationsYour proof should outlast
your choice of provider.
Keep the record, the policy and the verifier version together so a recipient can repeat the check under an explicit trust policy.
G-14 Evidence
Every receipt states who issued it, under whose administration, how independent the issuer is, how it was checked, what it doesn’t cover, how long it’s valid and where its current status comes from.
Evidence never grants permission: even a passing assessment can’t authorize a merge or a deployment.
The right verifier for the record.
Public ECL-1 tools check ECL-1 action evidence. Platform authority, development and custody records use separate contracts.
A valid signature establishes integrity under the selected policy. It does not establish the truth of an observation, complete capture, protected key custody or the identity of an untrusted issuer.
Check an ECL-1 bundle you holdWhat each evidence record is for, and what it does not establish
A claim states what is being asserted; evidence supports a specific check; an assessment records a review. None grants permission to act.
- Required evidence (EvidenceRequirement)
The evidence obligation set by a policy or verification profile.
The caller cannot establish satisfaction just by saying it is met.
- Collected evidence (EvidenceItem)
A collected observation, artifact reference, testimony or signed statement.
Collection alone does not make it trusted or sufficient.
- Scoped assertion (Claim)
A precise statement about a subject, scope, time and environment.
The statement needs admitted evidence.
- Verification rules (VerificationProfile)
The required methods, evidence, thresholds, failure behavior and independence for a check.
It is not the implementation that performs the check.
- Verifier package (VerifierPack)
A versioned executable or human checking procedure with its provenance and constraints.
It does not grant permission to run in every environment or issue authority.
- Bounded review (Assessment)
A bounded evaluation of an exact subject.
It is not certification or a release decision.
- Result or gap (Finding)
A result, gap, counterexample or limitation from an evaluation.
Recording a risk does not mean someone accepted it.
- Scoped conclusion (Qualification)
A conclusion limited to the exact subject, checking profile and recorded state for a stated time window.
It does not authorize deployment or action.
- Signed record (Receipt)
A portable signed record of a defined event or conclusion.
It supports only the statements it explicitly makes.
- Verification trust (TrustBundle)
The keys, issuers, status sources, algorithms and policy used for verification.
It is not a reason to trust every issuer or record.
- Authorized export (Disclosure)
An authorized view or export for named recipients.
It does not grant access to private source or raw material.
- Reassessment schedule (ReassessmentSchedule)
The expiry, triggers and recurrence rules for another check.
A scheduled check is not a completed check.
Revocation and supersession do not delete earlier evidence. Disclosure does not override the recipient’s permissions. The platform’s verifier distribution is separate from the ECL-1 verifier.
One control model.
The right view of the work.
Console brings the software estate, delivery, runtime authority and evidence into one oversight view. Studio organizes governed planning, building and review around those same records and authorities.
- Home
- Estate
- Ship
- Control
- Evidence
- Operate
From outcome to exact candidate.
Studio’s Outcome, Builder, Code, Preview, Agents and Mission Cockpit modes serve different depths of work. Create, build and govern without turning a view or a model response into a decision.
Operate under the same rules.
Trace an incident across running objects, recent changes, owners, policy and observations. Link proposed recovery to its evidence and required authority. Missing observations and unresolved holds remain visible. Evidence supports an authorized decision to close an incident. A status color can’t supply a missing observation.
Confirm the release, interfaces and deployment terms for your environment with us.
Choose where the
control and data live.
Run it locally, use G-14’s hosted service, run it in your own private or self-managed environment, or go sovereign and air-gapped. The local gate is free. Availability for each option is agreed with you.
In supported local deployments, the action check doesn’t require a hosted round trip. Current authority, freshness, expiry and revocation rules still apply. Receipt delivery can happen asynchronously.
The five deployment models
- Local gate
- A gate at the customer’s runtime, with local enforcement and receipts.
- Hosted
- The hosted deployment model calls for regional control cells and separately agreed execution arrangements.
- Private execution
- Hosted control with execution in the customer’s network or account.
- Self-managed
- Customer-operated control and execution services.
- Sovereign or air-gapped
- Disconnected customer-operated systems with controlled offline updates, revocation information and reconciliation.
What a deployment agreement must name
Topology, authentication, supported adapters, tenant boundaries, network and egress limits, signing-key custody, evidence retention and access, emergency halt and recovery. Private and sovereign operation are concrete arrangements, not a label that proves isolation or compliance.
Establish the external enforcement and observation paths before admitting production work. Read this demonstration’s security limits or discuss a customer deployment review.
The platform,
in detail.
Choose a group to find a capability and the rules behind it. Supported interfaces, identity connections and deployment scope are agreed before integration.
Know what exists 10 capabilities
- Connection targetsRead-only connection targets include GitHub, GitLab, Azure DevOps, Bitbucket and internal Git, plus artifact registries, CI, clouds and clusters.
- Version pinsImported source pinned to exact versions.
- First estate receiptA first estate receipt distinguishes observed, declared and unobserved objects, with missing delivery links left visible.
- Object classificationClassification into source, test fixtures, evidence, builds, releases, vendor code, private secrets and unknowns.
- Path safetyPath-safety checks for escapes, symlinks and name collisions.
- Visible gapsGaps stay visible: missing or stale facts are held, never guessed.
- Decision contextCompare code and context as they were when a decision was made with what changed later.
- CI targetsConnection targets include GitHub Actions, GitLab CI, Jenkins, Buildkite, CircleCI and your own runners.
- Runtime targetsConnection targets include Kubernetes, serverless, VMs and edge or device fleets. A prevention claim requires enforcement on every action path in scope.
- AI estate objectsThe estate model covers agents, models, prompts, tools and MCP endpoints, each with an owner.
Govern the change 13 capabilities
- Plans and completionObjectives, owners and acceptance criteria set under your rules, with plan and completion decisions recorded by a dedicated authority.
- Intent before editsAgents declare their intent before editing; G-14 reconciles it against the actual change.
- Frozen reviewsFrozen candidates: reviewers see the exact bytes, and a later edit expires approvals for the changed subject.
- Independent changesIndependent changes can proceed separately once their required checks pass; conflicts remain held.
- Bounded workspacesBounded workspaces with network, package and tool policy, just-in-time secret references and spending limits.
- MissionsMissions: short-lived, scoped units of AI work that must leave evidence.
- Agent teamA built-in agent team in ten specialist roles, each working under its own grants.
- Assurance classesAssurance classes distinguish coordinated work from submitted, observed or externally attested work.
- Change graphA change view that links intent, code, tests, findings, decisions and evidence.
- Planning toolsPlanning targets include Jira, Linear, ServiceNow, GitHub, GitLab and Azure Boards.
- Model and framework sourcesProposal-source targets include OpenAI, Anthropic, Gemini, Bedrock, open-source and internal models, agent frameworks and MCP tool calls. Their output is a proposal, never authority.
- Outside coding agentsWork from outside coding agents and editors is admitted as an exact candidate with a stated assurance class.
- Evaluation modesReplay, shadow and assist are evaluation modes. They do not enforce an effect boundary; control requires an admitted enforcement path.
Control the action 14 capabilities
- Eleven limitsEleven limits; every applicable limit must allow the action.
- Permission profilesSeven capability profiles, from Observe to Operate, with exact grants.
- Permit typesStanding permits, one-use permits and actions never allowed in a workflow.
- Combined conditionsRules that combine amounts, independent checks, operating state, time and counted uses.
- Continuing budgetsBudgets that carry over when the model, agent or session changes.
- Agent identityEvery agent acts under its own identity; delegation can narrow its authority, never widen it.
- Revocation rulesRevoke a permit under the deployment’s declared timing rules.
- Local gateA free local gate; in supported local deployments, the action check doesn’t require a hosted round trip.
- Emergency stopEmergency stop on its own control path, for one tenant or everything.
- Runtime authorityA separate runtime authority for privileged operations, issuing short-lived signed capabilities or a denial.
- Enforcement pointsEnforcement points for AI tool calls and standard authorization checks.
- Remote operationsGoverned remote support for people and AI agents on endpoints through VaultDesk.
- Fail closed under outageA timeout never grants permission. Missing current authority blocks a new action; a reply lost after submission leaves the outcome unknown until reconciled.
- Billing never grants authorityCommercial access and action authority are separate. Billing cannot make evidence sufficient, issue a qualification or grant release authority.
Identity, tenancy and access 11 capabilities
Rules for configuring identity and access. Each deployment needs evidence that its selected identity connections and tenant boundaries enforce these rules.
- Identity-provider sign-inSign-in through your identity provider is defined over OpenID Connect, with the issuer, keys, flow and allowed claims fixed for the deployment. Signing in identifies the account; it never grants permission by itself.
- Authority decided on the serverThe server validates authorization separately from identity. A client-supplied tenant, role or model output cannot create permission.
- Tenant isolationTenant isolation uses forced row-level security in a locally tested runtime schema. Each deployment must also establish its cache, job, export and logging boundaries.
- SessionsThe session contract specifies opaque handles held on the server, idle and absolute expiry, rotation, logout and revocation.
- Step-upUnder the identity and release contracts, high-consequence release workflows need fresh step-up evidence. Step-up alone grants no release authority.
- Separation of dutiesThe release contract separates requesters from approvers and requires customer-approved roles. Distinct role names alone do not prove independent people.
- Who did whatApproval and release records must identify the actor, session, tenant and environment under the audit contract.
- API keysAPI keys are scoped, shown once and listed only as hashes in the locally tested implementation. Production key management requires separate qualification.
- Role revocationRole changes must invalidate dependent grants under a declared revocation policy. Propagation paths and timing require deployment-specific verification.
- Support accessSupport-access rules require customer approval, time limits and no release authority. They exclude impersonation.
- External policy checksThe AuthZEN binding lets an outside policy decision add restrictions. It cannot replace G-14’s own authorization checks.
Establish what’s running 5 capabilities
- Claim levelsFive levels of production claim, from declared to effect-observed.
- Release bindingsSource, build, configuration and target bound together for every release.
- Runtime observationRuntime observation kept apart from what pipelines report.
- Deployment reportsRecord your pipeline’s deployment reports and add observations where supported.
- Incident responseIncident response that links running systems, recent changes, owners and evidence to a recovery decision, under the same rules.
Keep the evidence 9 capabilities
- Evidence typesG-14 Evidence: twelve evidence types, each with a stated purpose and limit.
- Signed receiptsSigned receipts that name their issuer, administration, independence, method, limits, validity and status source.
- Portable verificationCheck portable records with the matching verifier under your own trust policy.
- Open verifiersOpen ECL-1 verifiers in TypeScript, Python and Go, plus one in your browser.
- Evidence historyChanging or revoking a permit doesn’t rewrite earlier evidence.
- Disclosure and reviewDisclosure to named recipients, and reassessment schedules that say when a conclusion must be checked again.
- Telemetry exportOpenTelemetry export defined by an ECL-1 binding.
- Whole-run exportWhen connected, export this site’s ECL-1 example bundles and trust policy for offline checks. Public test keys do not establish issuer identity or effects.
- Offline ECL-1 checksCheck supported ECL-1 action bundles offline with the matching public verifier and your chosen trust policy.
Work and deploy your way 14 capabilities
- Deployment modelsSelect and qualify the control, execution and custody model for your scope: local, hosted, private execution, self-managed, or sovereign and air-gapped operation.
- Key and data custodySigning-key custody, data location and retention agreed for each deployment.
- Separate control credentialsSeparate credentials for policy, decisions, enforcement and emergency stop.
- Operations consoleConsole: one view across estate, delivery, control, evidence and operations.
- Development studioStudio: plan, build and review AI work, from outcome to exact change.
- Governed connectorsConnectors and adapters built by G-14’s own agents as Missions, then reviewed and admitted by your team.
- Developer interfacesPlan API, CLI and SDK access for the lifecycle steps your deployment needs. Confirm the supported interfaces and versions with G-14.
- ECL-1ECL-1, the open standard for runtime control and portable receipts.
- Standards bindingsECL-1 bindings for AuthZEN, AARM, OWASP ACS, MCP, OpenTelemetry and OAuth.
- Formal modelsFormal TLA+ and Tamarin models behind the standard.
- Source custodyThe deployment agreement sets source custody: references only, indexing inside your cell, or hosted custody.
- Analytics boundariesThe analytics design calls for privacy-preserving aggregates. Confirm what a deployment collects, redacts and retains.
- Early-access termsEarly-access scope, pricing and terms are set in a written agreement.
- Service levels and supportService levels, support and response commitments are set in your agreement.
Terms used on this site
- Permit
- A bounded grant that lets an agent take a named kind of action within limits on scope, uses and time. Your rules say who may issue it.
- Standing permit
- A permit for repeated actions within its scope. It ends when it expires, runs out of uses or is revoked, and other limits still apply.
- One-use permit
- A permit for a single action, such as one a person grants after review.
- Excluded action
- An action this workflow does not permit. A permit for this workflow must not include it.
- Gate
- The checkpoint that permits an action only when a valid decision authorizes it.
- Accept, or hold
- The named authority’s decision on an exact change. A hold prevents that change from proceeding until the required issue is resolved.
- Read-only (observe-only)
- This connection grants permission to read the agreed scope, without granting permission to change it.
- Receipt
- A signed record of what was decided or observed, with its limits.
- Trust policy
- The issuers, keys, permitted uses and rules you choose to accept when checking a record.
- Mission
- One bounded piece of AI work with its own permission, workspace and evidence trail.
- Assurance class
- A label for the evidence a participant can supply about its work: coordinated live, submitted after, observed, or attested by another party.
Connect first.
Grant deliberately.
Bring the estate you have and one production question you need to answer. Begin observe-only. Add governed development and controlled effects only when the relevant boundaries are established.
Replay, shadow and assist modes help evaluate a path before it is enforced. They don’t enforce an effect boundary or establish production readiness.