§02e Jupiter — AIGP & Pre-Invocation — The pre-invocation signal registry
Mars® Spec › §02e Jupiter — AIGP & Pre-Invocation › The pre-invocation signal registry
← The pre-invocation / post-invocation boundary · Section index · Signal typing against the order structure →
3. The pre-invocation signal registry
A pre-invocation signal source must be registered before its outputs are admitted as battery inputs. Registration is a deployment-time act recorded in the specification registry (§02b §3). An unregistered signal source’s outputs are not admissible as battery inputs; they may be noted in Field 6 (falsifier annotations) as out-of-scope observations but may not contribute to the verdict or the IR.
Registration record. Each registered pre-invocation signal source carries:
| Field | Content |
|---|---|
| Source identity | A stable identifier for the pre-invocation system or process: name, version, and provenance hash |
| Source class | The class of pre-invocation governance the source performs: admissibility-gate (evaluates whether the input is admissible), context-enrichment (enriches the input before model execution), output-pre-evaluation (evaluates the output before handing to the post-invocation layer), moderation (classifies the input or output against a policy), human-review (a named human authority reviews and decides), or composite (the source performs more than one class; each component declared separately) |
| Output vocabulary | The typed vocabulary of signal values the source may emit; for tri-state sources: {admit, refuse, refer}; for scored sources: the declared scale and interpretation; for structured sources: the schema of the emitted record |
| Order-typing declaration | The orders against which the source evaluates: the source may declare one or more orders from the governing model, or declare order-agnostic if its evaluation is not order-specific. An order-agnostic source’s signals enter the IR as untyped-pending elements and must be disambiguated before IR-level methods may consume them |
| Witness class | The class of recomputation witness the source produces (§4) |
| Scope conditions | The conditions under which the source’s signals are valid: governing-specification version range, input domain, operating context |
| Governing-specification binding | The registered governing-specification identity against which the source evaluates; or independent if the source operates against its own specification (the source’s own specification identity is then declared separately) |
| Absence posture | The declared behavior when the source produces no signal for a given invocation: signal-required (absence is a battery gap triggering a typed gap referral), signal-optional (absence is a declared valid state recorded in the battery record), or signal-suppressed (the source was configured not to run; recorded as a suppression entry in the battery record) |
Registry requirements. Source registration records are held in the specification registry as first-class governance artifacts. The registry must treat source registration records with the same tamper-evidence, append-only, and content-addressability requirements as certificate records (§02b §3). Additional requirements:
- Versioning. A source registration record carries a version identifier and an effective-date range. When a source’s registration is updated, the prior version is retained as a historical record and the new version takes effect from its declared effective-date. Certificates issued under a prior source registration version remain valid against that version’s declared scope; they are not retroactively invalidated by a registration update unless the update is classified scope-breaking under the delta-attestation lifecycle (§02b §5).
- Delta-attestation participation. A scope-breaking update to a source registration record triggers cascading revocation of all certificates issued under batteries that consumed signals from the prior-version source registration. The cascade record identifies the source registration version that changed and each affected certificate.
- Cross-reference. Each certificate record in the registry carries, in Field 3 and the analysis battery record, a reference to the source registration record version that was in effect when the battery ran.
← The pre-invocation / post-invocation boundary · Section index · Signal typing against the order structure →