§02e Jupiter — AIGP & Pre-Invocation — Signal typing against the order structure
Mars® Spec › §02e Jupiter — AIGP & Pre-Invocation › Signal typing against the order structure
← The pre-invocation signal registry · Section index · Witness classes and chain integration →
4. Signal typing against the order structure
Every admitted pre-invocation signal must be order-typed before it may be used as a battery input at the IR level or above. Order-typing assigns each signal element to one or more orders of the governing domain model under the same order-shape contract (§02a §5) that governs all other battery inputs.
Order-typed signal. A signal element whose source declared one or more specific orders in its registration enters the IR as a fully order-typed element in those orders. It satisfies the order-shape contract for those orders immediately and may be consumed by IR-level methods without further disambiguation.
Order-agnostic signal. A signal element from a source that declared order-agnostic enters the IR as an untyped-pending element. It carries the signal value and the source identity but no order assignment. The pipeline must assign it to one or more orders through the disambiguation mechanism (§02a §5a.1) before IR-level methods may consume it. If no order assignment can be made, the element is carried as a declared-irreducible entry (§02a §5a.4) with irreducibility basis authority-unavailable if the source cannot provide order context, or formally-undecidable if the signal’s content cannot be mapped to any declared order.
Multi-order signals. A single pre-invocation signal may carry elements across multiple orders — a composite admission decision that evaluated the input on both prescriptive and procedural grounds, for example. Each order-typed component is a separate IR element, tagged with its order and carrying a reference to the originating signal record. The originating signal record is the shared anchor for all components of a multi-order signal.
Attack/quality fork. When an admissibility-gate source evaluates a prompt, its signal elements are typed by order in a structurally significant way: a finding that the prompt constitutes an express attack — a jailbreak, prompt injection, encoded override, or equivalent prescriptive-order violation — is typed to the prescriptive order and disposed to REFUSE with a falsifier. A finding that the prompt has a quality deficiency — lack of clarity, specificity, or groundedness — is typed to the descriptive order and disposed to REFER or coaching, never REFUSE. These two dispositions are structurally distinct and may never be conflated: a quality finding may not produce a REFUSE disposition, and an attack finding may not be down-graded to a REFER without a structural basis for doing so. A pre-invocation source that conflates the two — that issues REFUSE on a quality finding, or that issues only REFER when an express attack is identified with a falsifier — produces a structurally malformed signal and its output is treated as a W2 or W3 attestation only, not a conforming admissibility-gate W1 signal. The attack/quality fork is a structural property of order-typed admissibility evaluation, not a policy choice of the source.
Canonicalization-by-lift. A pre-invocation source that performs order-typed lift of the prompt canonicalizes the prompt’s surface form to its order-typed meaning before evaluating admissibility. This canonicalization is what makes the admissibility verdict invariant to surface obfuscation: encoding, homoglyph substitution, translation, and delimiter obfuscation are defeated structurally because the lift normalizes all surface forms of the same order-typed meaning to the same representation. A prompt that is base64-encoded, phonetically transcribed, or delimiter-escaped yields the same order-typed meaning as its plain restatement and is evaluated under the same admissibility predicates. A source that evaluates surface strings rather than lifted order-typed meaning is not performing canonicalization-by-lift; its signal enters the IR as order-agnostic and is treated accordingly. Canonicalization-by-lift is a property of the source’s lift method, declared in the source registration record.
Multi-turn accumulation. A pre-invocation source that evaluates accumulated multi-turn context decides admissibility over the order-structured accumulation of the conversation — not the atomic current prompt alone. A sequence of individually-admissible prompts that is jointly out-of-bounds under the governing specification is refused at the accumulating turn. The accumulation is order-structured: each prior turn’s order-typed signal elements are carried in the accumulated record and evaluated together with the current prompt’s elements. A source that evaluates only the current prompt’s surface form, without order-typed accumulation of prior turns, is not performing multi-turn accumulation; its signal covers only the current turn’s scope, declared in its evaluation-scope field.
Segment-provenance typing. A pre-invocation source may type each segment of the prompt by provenance — user-authored, retrieved, or tool-returned — as an order-index on that segment’s signal element. Provenance-differentiated admissibility applies: a retrieved or tool-returned segment is not well-typed to carry instructions to the model. A prompt segment typed as retrieved or tool-returned that carries an instruction-form predicate is a prescriptive-order concern and is evaluated under the attack fork, not the quality fork. A source that does not perform segment-provenance typing evaluates the prompt as a homogeneous artifact; the indirect-injection surface is not defended by that source’s signal. Segment provenance is declared per signal element in the evaluation-scope field.
Signal element structure. Each order-typed signal element carried in the IR holds:
| Field | Content |
|---|---|
| Signal source identity | Reference to the registered source record |
| Signal value | The typed value from the source’s declared output vocabulary |
| Order tag | The order(s) to which this element is assigned |
| Evaluation scope | The portion of the input or output the source evaluated to produce this signal element; expressed as an order-typed scope expression over the governing model |
| Signal timestamp | When the signal was produced |
| Signal record hash | Tamper-evident binding over this element’s fields |
← The pre-invocation signal registry · Section index · Witness classes and chain integration →