§02e Jupiter — AIGP & Pre-Invocation — The pre-invocation / post-invocation boundary
Mars® Spec › §02e Jupiter — AIGP & Pre-Invocation › The pre-invocation / post-invocation boundary
← What this layer covers · Section index · The pre-invocation signal registry →
2. The pre-invocation / post-invocation boundary
The boundary is the point at which the AI model produces its output.
Everything before that point is pre-invocation: determining whether a prompt is admissible, enriching a context-starved prompt, governing which model executes and under what constraints, retaining admission witnesses. Everything after that point is post-invocation: verifying the output against a governing specification, certifying conformance, governing downstream actuation, and — on the AIGP side — persistence, observation, and reflection over the completed invocation.
The phases are not the protocols. AIGP is the admissibility gate before the boundary and the manager of the completed invocation after it; Mars® is the governed runtime of the invocation and the certifying and forensic layer that follows. Both operate on both sides; what distinguishes them is the obligation each discharges at each phase, not which side of the boundary it sits on.
The boundary is not a wall. The governed round-trip depends on continuity: the recomputation witnesses retained on the pre-invocation side are the soundness anchors (§02a §3a) that the conformance certificate issued on the post-invocation side inherits. The boundary contract is the mechanism by which that continuity is maintained across the structural divide.
Streamed and incremental output. Where model output is produced incrementally, the boundary is crossed incrementally: each increment released to any consumer outside the governed pipeline is produced output, and release gating is a declared, registered mode of the deployment. Two modes are admitted: (a) hold-and-release — no increment is released before the output validation verdict; this is the default, and absent a declared mode it is the required behavior; or (b) incremental validation — increments are released under a running output-validation verdict computed per increment or per declared window, using the same incremental-record machinery as the streaming certificate governance form (§02c §4.2): each released increment carries a running content hash and witness chain link. A REFUSE arising mid-stream halts release immediately, and the already-released prefix is recorded as a typed partial-emission event carrying the increment hashes and the halting verdict, propagated to every downstream consumer of the prefix. Releasing streamed output under neither mode — release before any verdict, without the incremental machinery — is non-conforming. Streaming does not relax the output-validation obligation; it changes only the granularity at which the obligation is discharged.
Four artifact classes cross the boundary. The following artifact classes are defined at the boundary:
| Artifact class | Direction | Description |
|---|---|---|
| Pre-execution admission verdict | Pre → post | Tri-state verdict (ADMIT/REFUSE/REFER) produced before model execution; spec-version-stamped with recomputation witness |
| Order-typed enriched prompt | Pre → post | The governed input artifact the model executed on; original prompt plus traversed context plus typed gap record, witness-bound |
| Output validation verdict | Pre → post | Tri-state verdict produced at the output locus before handoff to Mars® |
| Retained admission witnesses | Pre → post | Recomputation witnesses for each pre-invocation governance decision; soundness anchors for Mars®-issued certificates |
These artifact classes define what may cross the boundary. Neither side needs internal knowledge of the other side’s implementation. What passes between them is typed, witness-bound, and independently verifiable.
← What this layer covers · Section index · The pre-invocation signal registry →