G‑14Run a private proof

SDK / API / Agent Control Runtime

Build atthe actionboundary.

Put G‑14 between AI proposals and consequential execution. Start with one governed action path, then move from proof to pilot to production when the control burden is real.

Request SDK accessOpen API/Test LabBring your AI guide
AI proposalTyped actionActor, verb, resource, context
G‑14 decisionAdmission boundary
HoldBlockRelease
Proof receiptVerifiable recordEvidence retained for review
allow / hold / blockindustrial permitsAMR dispatch gatewayproof packets

Why builders use it

One narrow integration can turn unmanaged AI action into governed execution.

You do not need to rebuild your model stack to start. Put G‑14 at the boundary where an AI system, robot, tool, workflow, or agent asks to touch the world. The first integration can run record-only, then move toward live release gating when the operational case is clear.

Runtime surfaces

What your team can build with.

The integration question is concrete: where G‑14 plugs in, what the runtime returns, and what proof survives after execution.

Agent Control Runtime

Embed the action-boundary contract where your agents or tools cross into consequence.

ACR gives builders typed runtime objects for witness state, action telemetry, action context, release decisions, hold packets, and replayable evidence. Use it when the system needs a fail-closed decision before a proposed action becomes execution.

  • Witness and action telemetry
  • Allow / hold / block release decisions
  • Branch-aware evidence records
Industrial action boundary

Run G‑14 as a sidecar API for consequential industrial tasks.

Submit an industrial task packet, receive a permit verdict, resolve holds with recorded authority, sweep expired holds fail-closed, and retrieve portable evidence from a hardened evidence store.

  • Permit evaluation endpoint
  • Operator hold resolution
  • Portable evidence retrieval
AMR gateway

Gate autonomous mobile robot dispatch before commands leave the control boundary.

The AMR gateway accepts mission artifacts and normalized dispatch commands, evaluates the action, records custody, forwards only released commands, and supports Open-RMF and VDA 5050 shaped connector paths.

  • Zone authorize, pause, resume, route change, safe state
  • Duplicate and stale-command rejection
  • Operator holds and timeout safe-state handling
Proof packets

Give customers evidence, not just better execution.

Every governed action can produce a proof receipt showing what was proposed, how the control layer responded, which runtime evidence was used, what happened after execution, and which audit bindings were configured.

  • Proposal and control decision
  • Runtime evidence and final outcome
  • Cryptographic hashes and audit bindings where configured
Verifier tools

Let security, audit, and customer teams verify the record outside the runtime.

Verifier tooling checks packet versions, canonical hashes, permit and dispatch consistency, custody records, finalization semantics, timeout custody, signatures, and key status.

  • Offline verifier receipts
  • Bundle export for customers
  • Hosted proof-packet test path
API/Test Lab

Start with a controlled technical review before production access.

The API/Test Lab gives builders a low-friction way to inspect request shapes, run proof-packet examples, and decide whether SDK access, a pilot, or a deployment review is the right next step.

  • Docs and route families
  • Proof packets and verifier checks
  • Access request with technical context

Connection points

Pick the boundary that matches the action.

Software agents, tool calls, industrial tasks, robot dispatch, and proof-only review all follow the same pattern: proposal in, decision out, evidence retained.

01

Agent or tool gateway

MCP servers, internal agents, workflow automation, code or data actions.

You send
Proposed action, action context, authority context, evidence refs, and release deadline.
You get
Allow, hold, or block decision with reasons, custody, and proof packet path.
02

Industrial task permit

Manufacturing cells, lab automation, inspection workflows, process control handoffs.

You send
Task packet, site context, operational boundary, runtime evidence, and operator role model.
You get
Permit verdict, hold resolution path, expired-hold sweep behavior, and evidence retrieval.
03

AMR dispatch gateway

Fleet orchestration above existing AMR platforms and embodied autonomy workflows.

You send
Mission packet, decision request, decision response, dispatch command, timing, and evidence.
You get
Released or suppressed dispatch custody, operator review queue, timeout safe-state behavior, and verifier bundle.
04

Proof and verifier layer

Audit teams, safety reviews, customer assurance, vendor diligence, and post-action dispute review.

You send
Proof packet, packet bundle, keyset, manifest, and configured audit bindings.
You get
Independent verifier receipt and a durable record of the governed decision path.

API/Test Lab

The first review is concrete.

See route families, inspect request shapes, run proof-packet checks, and understand what moves from test lab to controlled access.

Open API/Test LabRun proof test
AMR dispatch request shaperecord-only or live-gated
POST /v1/amr/dispatches
{
  "mission_packet": "...",
  "decision_request": "...",
  "decision_response": "...",
  "provided_evidence": ["zone_map", "operator_roster"],
  "dispatch_command": {
    "command_name": "zone_authorize",
    "fleet_id": "line-7",
    "robot_id": "amr-042",
    "target_zone": "cell-a",
    "downstream_locator": "open-rmf"
  }
}

Route families

Enough detail to plan a real integration.

Product-level surfaces are public. Private scoring logic, protected implementation, exact keys, and route availability are controlled during access review.

SurfaceRouteUse
Industrial permitPOST /v1/industrial/permits/evaluateEvaluate a proposed industrial task before execution.
Industrial holdPOST /v1/industrial/permits/<permit-id>/resolve-holdRecord an authorized operator resolution for a held permit.
AMR dispatchPOST /v1/amr/dispatchesSubmit a governed robot or fleet command for release evaluation.
Operator queueGET /v1/amr/operator/holdsRead the live queue of commands waiting for operator review.
Proof packetGET /v1/amr/evidence/<permit-id>/packetExport the customer-facing proof packet for offline verification.
Evidence bundleGET /v1/amr/evidence/<permit-id>/bundleExport packet, verifier receipt, manifest, and rejection artifacts where applicable.

Proof receipts

Control the action. Prove the decision.

TargetLock and G‑14 runtime surfaces do not just improve execution. They give customers evidence for what happened before, during, and after release.

Base model or agent proposalExternal control decisionPreserved, corrected, blocked, or released pathRuntime evidence usedTiming and step countsRisk events and reason codesFinal outcomeCryptographic hashes and audit bindings where configured

Security and deployment review

Designed for teams that need runtime control to be part of production architecture.

Serious builders need access, evidence export, downstream dispatch, private deployment, and safety boundaries clarified before they invest in an SDK path.

Separated access tokens

Production paths separate API calls, operator actions, evidence export, and timeout-worker authority instead of treating one token as universal control.

Private deployment posture

Private cloud, U.S. colocation, and customer-controlled boundary reviews can be scoped before a pilot moves into production dependencies.

Redacted write responses

Write paths can stay concise while evidence export requires its own authorization, keeping operational data and audit material separate.

Downstream egress control

Connector review covers dispatch targets, downstream host allowlists, OIDC/JWKS configuration, and record-only dry runs before live forwarding.

Fail-closed operations

Holds, stale commands, duplicate mission/task IDs, missing authority, and expired review windows are treated as control events, not silent pass-through.

Safety boundary honesty

G‑14 governs runtime action release. It does not replace PLCs, interlocks, certified safety systems, low-level motion controllers, or required safety assessments.

Request deployment reviewEmail security

Regulated industries

Map one consequential workflow before you ask for production access.

Pharmaceuticals, healthcare, finance, industrial, infrastructure, and public-sector teams need the same first artifact: a clear action boundary, a configured authority model, runtime evidence, and proof receipts that survive audit or customer review.

Regulated deployment reviewProposal → boundary → authority → decision → proof

Use the regulated action mapper to identify where G‑14 should sit, what the API needs to receive, and what proof the SDK should return before live enforcement.

Open regulated mapper

What to bring

The fastest path is one governed action, not a platform rewrite.

A useful SDK review starts when the action, authority, evidence, and failure behavior are concrete.

  • One consequential workflow or action path
  • Current agent, robot, tool, or orchestration layer
  • Authority model and operator roles
  • Evidence sources available at runtime
  • Fail-closed behavior for hold, block, timeout, and stale command cases
  • Target deployment boundary: exploratory, private cloud, high-assurance, or production pilot

Request SDK access

Tell us the action boundary you want to govern.

Your information is never shared. NDA available upon request.

Access review

SDK access starts with one governed action path.

Tell us the system you are building, the action boundary you need to control, and the proof your operators, customers, security team, or auditors need to trust the result.

  • Agent, tool, industrial, AMR, and proof-packet paths are reviewed separately.
  • Private deployment and security posture are scoped before production access.
  • Proof-packet and verifier access can begin before live control is approved.
  • NDA available upon request.

Put G‑14 where AI stops proposing and starts acting.

Tell us the action path, the system you are connecting, and the proof your customers or operators need.

Request SDK access
G‑14

We are the External Control Layer for AI.
G‑14 provides infrastructure for consequential AI action. TargetLock is the physical-AI runtime.

TargetLockPlatformResultsResearchPilotsSDKBring AIRegulatedProof test
Privately owned. Built in the USA.

G‑14 is a privately owned American company. TargetLock is built on G‑14-owned USA based infrastructure.

Private infrastructure and proof.

Customer environments can be scoped around dedicated infrastructure, private networking, evidence-retaining proof receipts, cryptographic audit bindings, and post-quantum migration paths using NIST-standardized algorithms where configured.

Audit-ready pathways.

Readiness and evidence mapping can support SOC 2, ISO/IEC 27001, ISO/IEC 42001, NIST CSF 2.0, NIST AI RMF, NIST SP 800-171 / CMMC, FedRAMP authorization paths, and ISA/IEC 62443-aligned industrial deployments when properly scoped.

© 2026 G‑14, Inc. All rights reserved. Patents pending. G‑14, TargetLock, TargetLock Runtime, ECI-1, G‑14 External Control Layer technology, External Control Layer, ExternalControlLayer.ai, and related names, marks, logos, product names, software, designs, graphics, proof receipts, and proof artifacts are trademarks, trade names, copyrighted works, or other protected intellectual property of G‑14. Standards, certification, and authorization references describe readiness paths and control mappings, not completed certifications unless expressly stated in a signed customer or assessor document.