Your AI proposes
The model, agent, robot policy, copilot, or workflow engine emits a proposed action instead of executing directly.
Bring Your Own AI
Keep your AI.Govern the action.
G‑14 does not replace your models, agents, robots, or copilots. It sits between AI output and consequential effect, where a proposed action must be admitted before it touches systems, records, money, code, machines, or the physical world.
Model agnosticTyped action contractBoundary-gated releaseReplay to controlProof receipts
Model estate
Bring every AI estate to one admission boundary.
Bring hosted models, open-source models, internal models, agents, robotics policies, and mixed providers. G‑14 standardizes what matters for control: the proposed action, actor, resource, authority, evidence, decision, and proof.
The adapter is usually thin at the model side and stricter at the effect side. The critical design move is to remove direct write authority from the AI path and make the execution channel wait for a G‑14 admission decision.
Hosted LLMsOpen-source modelsInternal modelsAI coding agentsRobotics policiesEnterprise copilotsWorkflow automationIndustrial adapters
How it works
Your AI proposes. G‑14 decides whether the action is admitted.
Typed output makes proposals inspectable. Enforcement begins when the execution channel requires an admission decision before effect.
Adapter normalizes
Provider-specific output becomes the G‑14 ActionProposal contract with actor, verb, resource, trust domain, payload, and trace.
G‑14 admits or denies
The admission engine evaluates authority, evidence, policy, boundary, escalation, and fail-closed conditions.
Execution waits
The downstream tool, robot, workflow, API, or deployment channel only receives the action when the exact release is admitted.
Proof survives
Proposal, decision, evidence, release path, outcome, and verifier material bind into an inspectable receipt.
Typed output is not enforcement
Structured model output helps G‑14 understand a proposal. It does not make the proposal safe to execute.
A schema can identify a proposed code deployment or robot tote movement. G‑14 answers the harder question: may that exact action cross the boundary now, under this authority, with this evidence, and with this proof retained?
Shape, parsing, validation, fields, and fewer ambiguous requests.
Admission, hold, correction, block, release, fail-closed behavior, and proof.
Canonical proposalg14_action_proposal_v0
{
"schema_version": "g14_action_proposal_v0",
"action_proposal_id": "ap_acme_robot_0421",
"tenant_id": "tenant_acme",
"trust_domain_id": "td_robot_cell_04",
"action_type_id": "warehouse_robot.move_tote",
"actor_principal_id": "principal_openvla_cell_04",
"proposed_verb": "move_tote",
"target_resource": {
"from_zone": "A",
"to_zone": "B",
"tote_id": "tote_7741"
},
"model_or_agent_ref": "acme_ai_policy_v12",
"trace_id": "trace_20260517_001"
}Adapter patterns
Do not build governance around every model. Control the paths where AI can change the world.
Provider-native tools
Hosted model APIs and agents that already call tools or functions.
Declare a G‑14 action proposal tool. The model can request the tool, but cannot execute the downstream effect.
Structured output adapter
JSON schema, typed output, or internal parsers that can produce a stable action object.
Validate model output into ActionProposal. Reject malformed, missing, ambiguous, or unsupported action shapes.
Agent runtime gateway
Internal agents, MCP servers, orchestration frameworks, copilots, and automation services.
Intercept consequential tool calls before the agent receives production write authority.
Execution sidecar
Robotics, ERP writes, code deployment, cloud operations, payments, document release, and machine commands.
Move production credentials into a sidecar or gateway that requires a G‑14 admission decision before effect.
Replay and shadow harness
Early pilots where live enforcement is not approved yet.
Run historical or live-copy proposals through G‑14 to prove what would be held, blocked, corrected, released, and evidenced.
Enforcement boundary
G‑14 enforces only when the AI cannot bypass admission.
In replay and shadow, G‑14 can prove what would have happened. In control, the downstream system refuses to act without the G‑14 decision for that exact proposal.
No direct production credential in the AI loop
If the model or agent can call the production system without G‑14, G‑14 can observe or replay, but it is not the enforcing boundary.
Execution channel requires the decision
The robot, API, workflow, ticketing system, deployment runner, or data writer must require the specific admitted action before effect.
Evidence is required before release
The permit defines which identity, runtime, safety, test, policy, approval, or context evidence must exist before action.
Failure is deterministic
Missing evidence, expired holds, unknown actors, stale proposals, policy mismatch, and unavailable control services fail closed.
ProposedPreservedCorrectedHeldBlockedReleasedTimed outEffectedObstructedRevokedEscalatedProven
Deployment path
Start without production authority. Earn control through evidence.
The safest enterprise path is not to let G‑14 control production on day one. The first proof shows how the boundary behaves against your real action path.
Use historical runs
Show what G‑14 would have admitted, held, blocked, corrected, and proven without touching production.
Run beside live systems
Evaluate real proposals and evidence in parallel while the current execution path stays unchanged.
Guide human review
Recommend hold, block, correction, escalation, and release decisions while authorized operators remain in charge.
Enforce before effect
Put credentials, release, execution, outcome verification, and proof receipt behind the admission boundary.
Pilot input
One action path is enough for the first private proof.
- One consequential action path
- The current model, agent, robot, copilot, or workflow source
- The execution channel that currently performs the effect
- The authority model: humans, service accounts, roles, duties, and trust domains
- Required evidence before release
- Expected fail-closed behavior for hold, block, timeout, stale proposal, and unavailable control service
- Proof retention, export, redaction, and verifier requirements
Proof output
A proof-bearing action record.
Proposal inputNormalized action contractPolicy versionEvidence bundleAdmission decision and reasonHuman release or escalationExecution report and outcomeReceipt hash, signature reference, verifier material
Private proof