01
A control point
The gate sits before consequence-bearing execution. It evaluates whether the route has enough evidence, authority, continuity, and scope to proceed.
TA-14 Gate
The admissible execution gate.
The TA-14 Gate is the proof-bound control point where a consequence-bearing route is tested before it is allowed to bind, commit, execute, or create reliance.
It is the practical expression of the doctrine: if the evidence chain is not admissible enough, consequence-bearing execution must not proceed as normal. The route must be classified as ALLOW, HOLD, DENY, or ESCALATE before consequence attaches.
Direct contact: ta14admissibleexecution@gmail.com
What the gate is
The TA-14 Gate is where evidence either becomes admissible enough for execution — or execution is stopped.
Evidence → Admissibility → Binding → Commit → Execution Control → Outcome Proof
02
A refusal layer
If evidence is missing, stale, broken, unauthorized, or out of scope, the gate does not simply log the problem. It routes the system to hold, refuse, or escalate.
03
A proof surface
The gate creates a structured explanation for why execution was allowed, held, refused, or escalated. It turns execution readiness into a reviewable evidence object.
The gate is not the whole of TA-14
The gate is an implementation surface inside the broader TA-14 architecture. TA-14 governs the full chain from Reality through Outcome. The gate is the control layer where that chain becomes operational: admissible evidence must exist before consequence-bearing execution proceeds.
Live public API
The Gate is publicly testable and machine-readable.
TA-14 now exposes a live public reference API with an OpenAPI contract, interactive Swagger testing, deterministic decision classes, machine-readable chain specifications, and six evaluation routes. This is not merely a written-review offer. It is a developer-facing decision surface for testing how proposed routes are classified before execution.
01
Evaluate execution
POST /v1/evaluate-execution
Classifies a proposed consequence-bearing route against declared reality, evidence, continuity, authority, binding, commit, and outcome conditions.
02
Evaluate evidence
POST /v1/evaluate-evidence
Tests whether submitted evidence conditions are sufficient, current, continuous, attributable, and fit for governed reliance.
03
Check authority
POST /v1/check-authority
Tests whether identity, delegated authority, scope, legitimacy, and the proposed action are properly aligned.
04
Validate continuity
POST /v1/validate-continuity
Tests whether sequence, lineage, custody, timing, and material continuity remain preserved across the route.
05
Create a reviewability record
POST /v1/reviewability-record
Produces a structured record showing what was submitted, what failed, what warnings remain, and what should happen next.
06
Screen AI procurement
POST /v1/procurement-screen
Tests whether an AI product, vendor, pilot, or proposed deployment exposes unresolved evidence, authority, runtime, reliance, or consequence gaps.
Structured outputs, not a generic score
Public evaluations return a bounded decision — ALLOW, HOLD, DENY, or ESCALATE — together with failed links, warnings, reasons, next steps, request identifiers, timestamps, API version information, public-boundary language, and the TA-14 chain.
Gate logic
The gate evaluates the route before consequence can attach.
A consequence-bearing route cannot be treated as ready merely because a workflow reached an action step. The route must be checked across the admissible-execution chain. The TA-14 Gate asks whether the route has a preserved reality basis, a sufficient record, continuity, admissibility, authority, scope, binding control, commit control, execution control, and outcome accountability.
1
Receive route
The gate receives a proposed action route, workflow step, intervention, recommendation, release, refusal, or decision.
2
Check evidence
The gate checks whether evidence exists, whether it is current, whether continuity is preserved, and whether thresholds are met.
3
Verify authority
The gate checks whether the proposed action is authorized, in scope, and bound to the right governing basis.
4
Control execution
The gate allows, holds, refuses, or escalates the route before consequence-bearing execution occurs.
Core gate question
Can anything consequential happen outside the admissibility chain?
In a TA-14-governed route, the answer should be no. Every consequence-bearing route should be registered, governed, tested, fail-closed, source-grounded, authority-validated, scope-constrained, bind/commit-receipted, execution-controlled, replayable, and outcome-accounted.
Decision states
ALLOW, HOLD, DENY, or ESCALATE.
The gate does not collapse all uncertainty into yes or no. It classifies execution readiness based on the condition of the evidence chain.
ALLOW
The route has enough evidence, continuity, authority, scope, threshold satisfaction, commit control, and outcome accountability to proceed.
HOLD
The route is not ready yet. Evidence may be incomplete, stale, awaiting confirmation, missing a threshold, or lacking sufficient continuity.
DENY
The route should not proceed. Evidence is inadmissible, authority is invalid, scope is exceeded, continuity is broken, or the action would create unsupported consequence.
ESCALATE
The route requires higher authority, human review, expert review, additional evidence, or a governed exception process before any consequence-bearing step may continue.
Evidence and route objects
The gate turns action readiness into a reviewable object.
The TA-14 Gate is strongest when the route is represented as an evidence-bearing object. That object explains what is being acted on, what evidence supports it, who authorized it, what threshold is met, where commit occurs, and what outcome record must be preserved.
Evidence object
A structured record of the evidence relied upon before action. It may include source state, baseline, threshold, diagnostic determination, timestamp, authority, continuity proof, and admissibility status.
- Source record
- Baseline condition
- Threshold or rule
- Declared determination
- Continuity proof
- Admissibility state
Route object
A structured map of the proposed consequence-bearing route. It identifies the action, reliance point, binding point, commit boundary, execution mechanism, refusal path, escalation path, and outcome record.
- Proposed action
- Reliance surface
- Authority basis
- Commit boundary
- Execution control
- Outcome accountability
route_id: TA14-ROUTE-001
proposed_action: consequence-bearing execution request
reality_basis: captured
record_status: preserved
continuity_status: verified
authority_status: valid
scope_status: in_scope
threshold_status: met
binding_status: controlled
commit_status: receipt_required
execution_status: gated
outcome_record: required
gate_decision: ALLOW | HOLD | DENY | ESCALATE
GitHub reference
The gate has a public reference repository.
The public TA-14 Admissible Execution Gate repository and live API give the architecture a reference implementation surface. They are not the whole TA-14 architecture. Together, they demonstrate the key operational principle: a consequence-bearing route should be evaluated before execution is allowed.
TA-14 Admissible Execution Gate
Public reference MVP demonstrating admissibility-gated execution.
Live TA-14 API Sandbox
Interactive Swagger interface for testing the public reference evaluation routes.
Request Gate Review
Submit a workflow, AI route, evidence process, environmental pathway, or execution route for TA-14 review.
What the gate proves
The gate proves that TA-14 can move from doctrine into operational control.
01
Execution can be gated
The gate shows that admissible-execution doctrine can become a control layer, not just a paper concept.
02
Refusal can be structural
Refusal does not have to depend only on human memory, policy language, or after-the-fact review. It can be designed into the route.
03
Evidence can govern action
The gate demonstrates that evidence, continuity, authority, and thresholds can be evaluated before the system creates consequence.
The most important proof
A system can be technically capable of executing and still not be admissibly ready to execute. The gate makes that distinction operational.
Public reference versus production scope
The sandbox demonstrates the decision surface. Production binds it to evidence.
The public sandbox evaluates route conditions submitted by the caller. A submitted value such as
authority_in_scope, evidence_sufficient, or continuity_preserved is a declared
condition supplied for reference evaluation. The sandbox does not claim that every declaration has already
been independently authenticated against an external source.
P
Public reference API
- Interactive Swagger testing
- OpenAPI machine-readable contract
- Typed request and response structures
- Deterministic ALLOW, HOLD, DENY, or ESCALATE classification
- Failed-link, warning, reason, and next-step outputs
- Public chain and decision specifications
E
Evidence-connected production implementation
- Authenticated identity and delegated-authority records
- Source-bound evidence objects and evidence hashes
- System, policy, model, and ruleset version identifiers
- Sequence, lineage, custody, and continuity validation
- Subject-action binding and commit-point controls
- Signed decision receipts and persistent audit storage
- Expiration, re-evaluation, escalation, and resolution records
- Client-specific rules, risk classes, integrations, and security review
Submitted assertion → referenced evidence → verified chain state → signed decision receipt → governed execution → preserved outcome.
What the gate does not claim
The gate is powerful because its claims are controlled.
The public TA-14 Gate and sandbox are reference implementation and evaluation surfaces. They should not be overstated as universal certification or automatic production clearance. Their controlled public boundary protects the distinction between reference classification and evidence-connected institutional reliance.
Not full certification by default
A gate implementation does not automatically mean a system is TA-14 certified, endorsed, validated, or production-approved.
Not a security audit
The gate is not a penetration test, vulnerability audit, cybersecurity certification, or replacement for software security review.
Not a legal opinion
The gate may reveal evidence, authority, reliance, and consequence issues, but it does not provide legal advice or legal conclusions.
No build before boundary
Gate adaptation, route modeling, evidence-object design, production-readiness mapping, third-party integration guidance, and partner implementation support require defined scope. Public materials can explain the gate. They do not create a free implementation engagement.
Request review
Need a TA-14 Gate review for your system?
Test the public API, request an API Readiness Check, or submit an AI workflow, environmental evidence process, partner architecture, procurement route, institutional decision path, or execution pathway for scoped review and production-readiness mapping.
Direct contact: ta14admissibleexecution@gmail.com