Skip to content
Mars® Protocol

Appendix A: Use Cases

Mars® Protocol — Appendix A: Use Cases

Version 1.0-draft

This appendix illustrates how the Mars® governance architecture applies to representative deployment contexts. Each use case identifies the governing layers exercised, the artifact classes in play, the perspective specifications that apply, and the conformance certificate path. These are non-limiting examples; the architecture is domain-invariant.

A.1 Clinical Decision Support (HIPAA jurisdiction)

Context. A hospital deploys an AI system that receives patient records (non-linguistic inputs), synthesizes a diagnostic or treatment suggestion, and routes the suggestion to a clinician for review. The clinician’s acceptance or modification of the suggestion is an actuation act. The jurisdiction is HIPAA; the governed class is clinical-decision-support.

Modeling layer (§01). The domain model is decomposed over three orders:

  • Descriptive order — patient demographics, diagnoses, medications, allergies, lab values, imaging findings
  • Prescriptive order — clinical guidelines, contraindications, drug-interaction rules, dosing constraints, documentation obligations under HIPAA
  • Procedural order — the clinical workflow: intake → assessment → differential → recommendation → clinician review → actuation

Boundary-closure attestation requires per-consideration traceability to the clinical guideline or regulatory clause from which each prescriptive consideration was derived. Coverage narrowing (e.g., removing a contraindication consideration) triggers at minimum a scope-restricting delta.

Base analysis (§02a). The patient record (the non-linguistic engineering result) is certified as a Class B certificate: it requires a non-linguistic provenance chain record in Field 1 establishing the chain from the raw record to the normalized representation. Bootstrap provenance in Field 2 must trace to the authoritative clinical guideline source (e.g., FDA labeling, UpToDate, institutional protocol) with attestation statistic.

Integrated analysis (§02b). The inbound non-language-provenance anchor binds the patient record (Field 1: EHR system identity + record content hash), the analysis specification (Field 3: the clinical domain model identity + bootstrap provenance), and the interpretation-generation specification (Field 4: the suggestion-generation specification identity + joint-authority attestation). Field 5 carries the interpretation-execution record; Field 6 carries the faithfulness attestation signed by the clinical authority.

The actuation anchor (outbound boundary) binds the suggestion to the clinician’s actuation act. Field 7 carries the co-signature of the named clinical authority (the responsible clinician or the institution’s medical director for automated actuation). Field 4 requires a non-trivial transformation record from the order-typed predicate to the clinical suggestion text — identity transformation is not admissible.

Pre-invocation governance (AIGP) (§02c). AIGP’s pre-execution admissibility gate evaluates the inbound prompt (the clinical query, the patient context) against the clinical governing specification before the AI model executes. Segment-provenance assignment: the patient record entered via EHR integration is typed tool-returned regardless of whether a human entered it; it is not user-authored. The fail-closed base case applies: in a DDIL state (EHR system unavailable, partial record), the verdict is REFER, not ADMIT. The fail-closed base case is a clinical safety property.

AIGP’s post-hoc forensic record attributes any diagnostic anomaly to a causal dimension: a missing lab value routes to data attribution → sync-KB; a model that systematically under-weights a drug class routes to model attribution → swap-model; a prompt template that frames all queries as low-urgency routes to prompt attribution → review-prompt.

Per-subject behavioral-posture state tracks, per patient, prescriptive-order scrutiny separately from descriptive-order scrutiny — a patient with documented non-compliance with prescriptive constraints (e.g., repeatedly declining a recommended medication) has elevated prescriptive-order scrutiny without affecting descriptive-order scrutiny of their reported symptoms.

AIGP witness retention discipline: the HIPAA minimum retention period (6 years from creation or last effective date) bounds the licensee-declared retention floor. The retention period must be no shorter than AIGP’s governance reinforcement loop interval.

Perspective specification. A HIPAA-jurisdiction perspective specification activates: clinical-guideline-derived prescriptive primitives, HIPAA-compliant data sources only (PHI restrictions enforced at the data-source-admissibility rule), and a steering rule that routes any finding touching identifiable patient data through the named clinical authority’s co-signature path.

Certificate path. The grounded conformance verdict ({conforming / non-conforming / conditionally-conforming}) for the diagnostic suggestion is carried in Certificate Field 4. The three-tuple recomputation witness (traversal trace over the clinical KB, evidence record of guideline citations, uncertainty-reduction record per diagnostic step) is in Field 7. The temporal validity window (Field 8) is set per-clinical-shift — the certificate expires at shift boundary and requires re-attestation for the next shift’s clinician.

A.2 Financial Services Compliance (SEC/FCA/MAS jurisdiction)

Context. A financial institution deploys an AI system that analyzes client portfolios and generates investment recommendations or alerts. The governed class is suitability-assessment or regulatory-reporting. Multiple jurisdictions apply simultaneously (SEC, FCA, MAS).

Modeling layer (§01). Three orders:

  • Descriptive order — client profile (risk tolerance, investment horizon, holdings, net worth), market instrument properties, counterparty data
  • Prescriptive order — suitability rules (MiFID II best-interest, SEC Reg BI, MAS FAA obligations), fiduciary duties, reporting obligations, prohibited instruments by jurisdiction
  • Procedural order — recommendation workflow: client assessment → suitability check → instrument screening → recommendation generation → compliance sign-off → documentation

The multi-jurisdiction prescriptive order requires multiple registered perspective specifications — one per jurisdiction — rather than a single merged specification. This is the key structural point: jurisdictions are not merged into a unified prescriptive order; each is a registered perspective specification that produces an independent perspective-bound verdict. An instrument that is suitable under MAS rules but not under FCA rules produces two distinct verdicts, not one merged verdict.

Integrated analysis (§02b). Enforcement constraint NB5 (no silent scope extrapolation) is directly applicable: the scope-of-applicability certificate constrains the verdict to the declared jurisdiction(s). An output claiming MiFID II conformance must carry a scope certificate explicitly bounded to MiFID II — the system may not extrapolate that MiFID II conformance implies Reg BI conformance.

Enforcement constraint NB2 (no implicit cross-domain ontology equivalence) applies when a “suitability” definition in one jurisdiction’s specification is mapped to a “best-interest” definition in another’s. The registered cross-domain typed interface for this mapping must carry a loss-of-information record documenting what the MiFID II suitability predicate captures that Reg BI best-interest does not, and vice versa.

Pre-invocation governance (AIGP) (§02c). AIGP’s post-hoc forensic record composes per-interval suitability assessments (per review cycle) into a longitudinal verdict. Degradation over time (a client’s risk profile shifting while the model continues recommending the same instruments) is detected as model-degradation or data-staleness attribution and routes to the appropriate reinforcement action.

AIGP’s sycophancy gate applies: the sycophancy bracket for financial advice is the domain “investment recommendations” × “the response must not affirm a client-stated investment preference the governing specification marks unsuitable.” A bracket-crossing recommendation — one that agrees with the client’s stated preference despite the suitability check refusing it — is refused or revised before emission.

Multi-perspective certificate. For a cross-border recommendation, the system issues three independent perspective-bound verdicts (SEC, FCA, MAS), each with its own three-tuple recomputation witness. These are not merged. A downstream compliance gate checks that a valid current certificate exists under each required jurisdiction’s perspective specification before the recommendation is transmitted.

A.3 Defense / Coalition AI Governance (Rules-of-Engagement)

Context. A coalition military deployment operates an AI-assisted command-decision support system. The governed class is rules-of-engagement (ROE) compliance assessment. Multiple coalition members have distinct ROE specifications; the system must assess a proposed action against each member’s ROE independently before any actuation recommendation.

Modeling layer (§01). Three orders:

  • Descriptive order — the operational environment: entities (friendly, neutral, civilian, adversary), locations, assets, time windows, sensor inputs
  • Prescriptive order — ROE constraints per coalition member: target-discrimination rules, proportionality constraints, precautionary obligations, prohibited means and methods
  • Procedural order — the decision workflow: situation assessment → target identification → ROE check per coalition member → command review → authorization → actuation

Each coalition member’s ROE is a distinct registered governing specification. They are not merged. The prescriptive order is not a unified coalition ROE; it is a set of per-member perspectives applied independently. This is architecturally enforced by the perspective specification mechanism.

Integrated analysis (§02b). Named-authority standing is load-bearing here. Each coalition member’s commanding authority must hold a registered named-authority standing declaration (4-field record: verified identity, authorized actuation classes, scope-of-applicability, public key) before their ROE can govern an actuation recommendation. The public key is used to verify the co-signature on the actuation anchor’s Field 7. An actuation recommendation without a valid co-signature from an authorized named authority for each coalition member’s ROE does not complete the outbound boundary.

Enforcement constraint NB3 (no origination of named-authority decisions) is directly applicable: the system records the action condition (the proposed actuation) and routes it to the named authority for the accept/modify/reject/refer decision. The system does not originate the authorization; it informs it with a grounded, recomputable conformance verdict.

Pre-invocation governance (AIGP) (§02c). The pre-invocation admissibility gate (AIGP) evaluates the inbound prompt — here, the proposed action description. Segment-provenance is critical: sensor data entered via automated feeds is typed tool-returned; a human operator’s narrative assessment is typed user-authored. The segment-provenance typing governs which admissibility predicates apply to each segment. An automated sensor report cannot carry instructions that a human-provenance segment could carry.

Fail-closed base case: in a DDIL state (comms degraded, sensor feed intermittent), the admissibility gate verdict is REFER, not ADMIT. No actuation recommendation is issued on degraded situational awareness. This is an architectural property, not a policy decision — the fail-closed base case is structural.

Per-subject behavioral-posture state: per entity under track, the system maintains an order-typed posture state distinguishing descriptive-order uncertainty (uncertain sensor classification) from prescriptive-order concern (known ROE-triggering behavior). A sensor classification dispute raises descriptive-order scrutiny; a confirmed threatening act raises prescriptive-order scrutiny independently.

Certificate path. The conformance verdict for a proposed action is issued per coalition member’s perspective specification. Each verdict is independently recomputable. A recommended actuation carries the full set of per-member perspective-bound verdicts, each in its own certificate, consumed by the named authority’s authorization gate before any actuation is transmitted.

A.4 Enterprise AI Governance (Internal Deployment)

Context. A large enterprise deploys multiple AI systems across business units (HR, legal, finance, operations). The governed class is internal enterprise AI deployment. The governing authority is the enterprise’s AI governance office.

Modeling layer (§01). The enterprise operates a single order-decomposed domain model shared across business units, with unit-specific perspective specifications layered over it.

  • Descriptive order — organizational entities, roles, data assets, systems, processes
  • Prescriptive order — enterprise policies (data governance, acceptable use, privacy, legal hold obligations), regulatory obligations (GDPR for EU employees, CCPA for California consumers, applicable labor law)
  • Procedural order — business process workflows per unit: HR (hiring, performance, termination), legal (contract review, litigation hold), finance (forecasting, reporting), operations (procurement, logistics)

The enterprise governing specification is the canonical registered artifact. Business-unit perspective specifications activate the subset of the prescriptive order relevant to their domain and constrain data-source admissibility (HR queries may not consult financial records; legal queries under litigation hold may not consult records under hold without named-authority authorization).

Delta-attestation lifecycle in practice. When the enterprise’s AI governance policy is updated — a new data-retention obligation added, a new prohibited use case identified — the update is processed as a versioned delta with a four-valued classification:

  • A new data-retention obligation that extends existing scope is scope-extending: downstream consumers may opt in immediately; the delta cascades on the declared window.
  • A new prohibited use case that restricts prior scope is scope-restricting: all prior certificates covering the now-prohibited use case must be re-discharged within the declared deadline.
  • A policy change that renders a prior-version predicate directly invalid (e.g., a prior authorization is rescinded) is scope-breaking: prior-version predicates are immediately invalidated; no downstream consumer may rely on them after the cascade.

AIGP governance reinforcement loop in practice. A finding that a business unit’s AI system is producing outputs that systematically exceed its declared scope (scope extrapolation) is attributed to the prompt dimension (the prompt template is framing queries outside declared scope) and routes the review-prompt action to the business unit’s prompt owner. The before-stage rule change (tightening the admitted scope) is applied as an order-typed, witness-bound event; the governance office’s AIGP governance reinforcement trace records the entire finding → attribution → action → rule-change → closure arc as a recomputable audit trail.

Certificate consumption at gates. Each business unit’s AI-assisted process has declared gates where a conformance certificate is a precondition for proceeding. A contract review output requires a valid certificate under the legal perspective specification before the contract can be routed for signature. A termination recommendation requires a valid certificate under the HR perspective specification and a named-authority co-signature from the HR named authority before the recommendation reaches the manager. These gates are licensee-declared; the architecture specifies what must be present at the gate (a valid current certificate), not where in the business process the gate sits.

A.5 AI Model Development and Hardening (Internal R&D)

Context. An AI research organization uses the Mars® infrastructure to govern its own model development lifecycle — from dataset generation through model evaluation and deployment qualification. This use case exercises AIGP’s model-moderation capabilities across the full development pipeline.

AIGP’s dataset generation capability. The organization generates training datasets and candidate models relative to governing assets (domain model, specification, existing KBs). Each generated artifact is order-typed: a training example is tagged with the order(s) it exercises, the aspect it covers, and the governing specification version under which it was generated. A recomputation witness binds each generated artifact to its governing assets. Dataset provenance is fully traceable; no generated artifact enters training without a recomputation witness.

AIGP’s iterative development loop. The benchmark and dataset are co-generated relative to the governing orders. The loop terminates on a declared order-typed criterion (e.g., “prescriptive-order conformance rate ≥ 0.95 on the declared benchmark, measured under the governing specification version at loop initiation”). Each iteration is witness-bound. The governing-order snapshot is fixed at loop initiation; no mid-iteration governance changes alter the termination criterion. If the governance policy changes during a long training run, the change queues for the next loop initiation.

AIGP’s model characterization capability. The characterization dimensions are the governing orders, not independently chosen evaluation categories. A model characterization is multi-order (descriptive / prescriptive / procedural), multi-perspective (safety, security, quality, cost), and multi-dimensional (within each order × perspective). The composite characterization judgment is recomputable: an independent inspector can re-derive the characterization from retained per-measure witnesses without executing the original characterization run. Version-to-version delta distinguishes intentional improvement (prescriptive-order conformance increases on prior test vectors) from degradation (prescriptive-order conformance decreases on prior test vectors).

AIGP’s runtime governance capability. Adversarial probing is performed against benchmarks generated under the same governing orders as the training and evaluation. A jailbreak probe that succeeds on a prescriptive-order constraint is attributed to the model dimension; the reinforcement action is swap-model or re-probe with additional hardening. AIGP’s output validation gate at the output locus initiates the conformance certificate path — an output that passes output validation receives a certificate recording the verdict; an output that fails receives a falsifier annotation. Behavioral baselines and drift detection operate over the governing orders: drift is measured as order-typed divergence from the recomputable baseline, not as a general distributional shift.

AIGP’s KB synthesis capability (when corpus is unavailable). When training data in a required domain is absent or insufficient, AIGP’s KB synthesis capability reverse-synthesizes a data source or KB from available governing assets. The synthesized artifact is order-typed, grounded-verified before use, and carries typed gap signals ({data-source-gap, knowledge-base-gap}) identifying where reverse-synthesis produced lower-quality coverage than primary sources would provide. These gap signals are logged but do not block use of the synthesized artifact; they are inputs to AIGP’s governance reinforcement loop for future improvement.

AIGP’s witness retention discipline in the R&D context. Every admission decision made during the model-development pipeline (e.g., a training example admitted or refused at the pre-execution admissibility gate, a generated artifact admitted or refused at the output-validation gate) has a recomputation witness retained under AIGP’s witness retention discipline. The retention period must be no shorter than the longest governance reinforcement loop interval across the development pipeline. A model that was trained on admitted examples can, at any point in its deployment lifetime, be audited by re-deriving the admission decisions from retained witnesses — without access to the original training run or the original deployment.

A.6 Cross-Domain Knowledge Base Construction

Context. An organization is building a knowledge base spanning multiple professional domains (legal, medical, technical). The KB must serve downstream AI systems operating in each domain independently, without cross-domain contamination.

Structural constraint. Cross-domain KB construction must respect enforcement constraint NB2 (no implicit cross-domain ontology equivalence). A “consideration” in the legal domain and a “consideration” in the medical domain are not the same type, even if the natural-language term is shared. The registered cross-domain typed interface governs any translation between the two domains; the loss-of-information record documents what each domain’s concept captures that the other’s does not.

KB creation (§03). The corpus is analyzed per domain through its domain-specific governing model. The legal domain’s prescriptive-order extraction produces legal considerations (statutes, regulations, obligations). The medical domain’s prescriptive-order extraction produces clinical considerations (guidelines, contraindications, dosing rules). These are stored in separate co-indexed representations with separate aspect-identifier namespaces — the legal aspect identifier encodes (prescriptive, legal-obligation-tree position, legal-domain-model version); the medical aspect identifier encodes (prescriptive, clinical-guideline-tree position, medical-domain-model version). They are not merged.

Cross-domain retrieval. A query that spans both domains (e.g., “what are the legal and clinical constraints on off-label prescribing?”) exercises the registered cross-domain typed interface. The interface maps the legal-domain prescriptive aspects to the medical-domain prescriptive aspects via the declared translation-rule set. The loss-of-information record surfaces in the response: the gap between what the legal framework requires and what the clinical guideline specifies is reported as a cross-locus gap, not silently reconciled.

Gap report. The multi-locus gap report (§03 §2.4) identifies cross-domain gaps as multi-locus gap events with a locus-set spanning {domain-model (legal), domain-model (medical)} — a single record with a two-element locus-set, not two separate records. The typed reinforcement signal is the union of the two model-gap signals, each targeting the respective domain model for consideration.

Versioning. When the legal domain model is updated (a new regulation is passed), the delta-attestation lifecycle fires for the legal domain model. The cascade does not propagate to the medical domain model — the two domain models are independently versioned. A downstream AI system that operates only in the medical domain is unaffected. A downstream AI system that operates in both domains re-discharges its cross-domain scope-of-applicability certificate if the updated legal prescriptive order changes the scope of the cross-domain typed interface.

A.7 Automated Document Review with Human-in-the-Loop Authorization

Context. A legal services firm deploys an AI system that reviews contracts for compliance with a master services agreement (MSA). The system produces a conformance verdict; a human attorney reviews and authorizes (or modifies) the verdict before it is recorded in the matter management system. This is the interaction-mediated execution case.

Inbound boundary. The contract under review is the non-linguistic engineering result (Field 1 of the non-language-provenance anchor). It enters the system from a document management system (typed tool-returned at the source-introduction boundary). The analysis specification (Field 3) is the MSA-derived governing specification. The interpretation-generation specification (Field 4) carries the joint-authority attestation hash co-signed by the supervising partner.

Field 5 (interpretation-execution record) carries the interaction-mediated co-signature requirement: the reviewing attorney’s identity, the timestamped content hash of each annotation or modification the attorney made during review, and the attestation co-signature from the supervising partner (a named authority distinct from the reviewing attorney). The co-signature is required because the verdict that exits the system is attributed to an identifiable human-authority decision, not only to the AI output.

CHECK in the document-review context. The inbound prompt is the review query (e.g., “does this clause conform to MSA §7.3?”). The governing specification is the MSA-derived formal specification. Segment-provenance: the clause text retrieved from the contract is typed tool-returned; the attorney’s annotation is typed user-authored. An annotation that attempts to instruct the model to ignore a governing-specification constraint is not well-typed to carry that instruction (segment-provenance admissibility) — the model may not accept the instruction regardless of the annotation’s content.

Output-validation and certificate path. The system’s verdict on the contract clause (conforming / non-conforming / conditionally-conforming) is validated at AIGP’s output validation gate before it is presented to the attorney. A non-conforming verdict with a falsifier annotation is presented to the attorney for review. The attorney’s decision (accept / modify / reject / refer) is recorded in the actuation anchor Field 7 as the named-authority co-signature. The final certificate carries both the AI-derived grounded verdict (Field 4) and the attorney co-signature (actuation anchor Field 7), making the certificate’s verdict attributable to a named human authority.

AIGP governance reinforcement in the document-review context. Repeated findings that a particular contract template produces non-conforming clauses under MSA §7.3 route to the prompt attribution dimension → review-prompt action targeting the template owner. AIGP’s governance reinforcement loop applies a before-stage rule change that amends the admitted scope of the prompt template to require that §7.3-adjacent queries carry additional context. The change is a registered, witness-bound event; the supervising partner’s delta-attestation triggers a scope-restricting cascade to all prior certificates issued under the old template scope.

A.8 Model Drift Detection and Remediation

Context. A production AI system has been operating for several months. Its governing specification has not changed, but its behavior has shifted: prescriptive-order conformance on a subset of queries is lower than it was at deployment qualification. The organization needs to determine whether the drift is real, what caused it, and what to do about it — with a recomputable record of the entire determination.

Why conventional monitoring is insufficient. Standard model monitoring detects distributional shift (input or output distributions moving relative to a reference window) and reports a drift score. It does not answer: which governing constraint is the model violating, why, and what specific remediation closes the gap. Without order-typed structure, the drift finding is a signal without an address.

The drift detection path. AIGP’s model characterization capability establishes the recomputable behavioral baseline at deployment qualification: per-order, per-perspective, per-dimension measures, all witness-bound. The baseline is not a statistical summary; it is a recomputable judgment — an independent inspector can re-derive it from retained witnesses. AIGP’s runtime governance capability measures current behavior against this baseline as an order-structured, recomputable finding. Drift is detected as a specific order-typed divergence: “prescriptive-order conformance on drug-interaction considerations has decreased from 0.94 to 0.81 since deployment qualification.” This finding is not a scalar; it names the order, the aspect class, and the magnitude.

Causal attribution via AIGP’s post-hoc forensic record. The drift finding enters AIGP’s forensic record as a post-hoc finding. The pre-invocation forensic record (AIGP) attributes it to a causal dimension:

  • If recent training-data updates introduced new drug-interaction patterns inconsistent with the prescriptive-order KB: data attribution → sync-KB
  • If the model was recently fine-tuned on a corpus that underrepresents drug-interaction caution: model attribution → swap-model
  • If the prompt template was modified to favor brevity in a way that suppresses full contraindication disclosure: prompt attribution → review-prompt

The attribution is evidenced: the forensic record carries the cited evidence (which KB primitives, which test vectors, which specification clauses) from which the causal dimension was derived. An independent inspector can re-derive the attribution from retained witnesses.

AIGP’s governance reinforcement loop closes the loop. The attributed finding routes through the governance reinforcement loop (AIGP): finding → attribution → action → before/during rule change → closure. The rule change (e.g., tightening the prescriptive-order admission criterion for drug-interaction queries at the pre-execution admissibility gate) is applied as a witness-bound event. The closure arc produces new evidence (post-rule-change conformance measurements) that either confirms remediation or seeds the next loop iteration. The entire arc is recomputable end-to-end: asked why the admission criterion for drug-interaction queries was tightened on a given date, the system yields the causal chain back to the original drift finding and its evidence.

What makes this different from a hotfix. A conventional hotfix updates the model or prompt and re-tests. The Mars® path produces a recomputable audit trail that a regulator, a patient, or a court can inspect: what drifted, when it was detected, what caused it, what was changed, and whether the change worked. The causal attribution and the remediation action are not assertions by the deploying organization — they are independently re-derivable from retained witnesses.

A.9 Sycophancy Detection and Runtime Gating

Context. An AI system deployed in a high-stakes advisory role (financial planning, legal research, medical second opinion) is exhibiting a systematic pattern: it adjusts its recommendations toward the user’s stated preferences even when those preferences conflict with the governing specification’s prescriptive constraints. This is the sycophancy problem — agreement at the cost of correctness — and it is structural, not occasional.

Why sycophancy is a governance problem, not a model tuning problem. A model that is sycophantic on prescriptive-order constraints cannot be fixed by adjusting a system prompt that says “don’t agree with the user.” The constraint is behavioral: the model has learned, from RLHF or preference fine-tuning, that agreement increases reward signals. The fix requires a formal representation of what “agreement at the cost of correctness” means in the governed domain, evaluated at runtime, independent of model internals.

The sycophancy bracket. The bracket is the boundary-defining act. For a financial planning deployment: domain = “retirement portfolio recommendations,” audience = “individual investor,” order-class = prescriptive, bracket-target = “the response must not recommend an instrument the governing specification marks unsuitable for the client’s declared risk profile.” Without the bracket, sycophancy is undefined. With it, any response that affirms a client-stated preference for a specification-marked unsuitable instrument crosses the bracket boundary — mechanically, recomputably, without access to the model’s internal reward signal.

Dual locus — why both matter. AIGP’s sycophancy gate operates at two loci using the same bracket representation:

Post-hoc detection (AIGP’s forensic record): The system analyzes the evidence trail — sequences of exchanges where the model’s recommendation shifted toward the user’s stated preference — and scores each session against the bracket. A session where the model recommended an unsuitable instrument after the client expressed a preference for it is a bracket-crossing event, scored and attributed to the model causal dimension. The finding routes to AIGP’s governance reinforcement loop: model attribution → swap-model or review-prompt, depending on whether the sycophancy is a model property or a prompt-induced behavior.

Runtime gating (output locus): Before emission, the candidate response is evaluated against the same bracket. AIGP’s sycophancy gate refuses or revises a response that crosses the bracket boundary — recommending a specification-marked unsuitable instrument — before the user sees it. This is not a content filter; it is a formal evaluation against an order-typed specification predicate. The gate verdict is recomputable: an independent inspector can re-derive whether the response crossed the boundary from the bracket specification and the response text, without model access.

Consistency between loci. The same bracket representation governs both loci. This enforces a consistency property: the runtime gate cannot clear a response that post-hoc analysis would flag as sycophantic. If the bracket changes (the broker’s suitability rules are updated), the bracket version is updated under the delta-attestation lifecycle, a new bracket version is registered, and both the forensic record and the runtime gate operate from the same new version for subsequent invocation sequences. Prior invocation sequences retain their bracket version in the recomputation witness, allowing retrospective analysis under the old and new brackets independently.

Attribution to the right cause. Sycophancy findings from AIGP distinguish model sycophancy from prompt-induced sycophancy. A model that crosses the bracket boundary on neutral prompts is a model-dimension finding (the model itself exhibits the behavior). A model that crosses the bracket only when the prompt template frames the query as “the client strongly prefers X” is a prompt-dimension finding (the template is the cause). The distinction matters for remediation: model-dimension findings route to swap-model; prompt-dimension findings route to review-prompt. AIGP’s forensic record carries the evidence distinguishing the two.

A.10 Harm Gating and Attributable Authorization

Context. An AI system receives a request that is not an express attack (which would be REFUSE-with-falsifier) but is in a zone where harm is possible depending on context that cannot be resolved automatically: a chemistry question that is legitimate for a researcher and harmful for an adversary; a medical dosage question that is appropriate for a clinician and dangerous for a layperson; an operational planning query that is authorized for a credentialed operator and restricted for others. The system cannot ADMIT (the request may cause harm) and cannot REFUSE (no falsifier is present). The REFER disposition is the structural answer, not a failure mode.

The REFER path is not a dead end. REFER routes the decision to a named authority with a grounded, recomputable record of what was found and why admission could not be granted. The named authority receives: the order-typed prompt, the aspect(s) that triggered the referral, the evidence gathered (what context was present, what context was absent), the typed gap (which KB or data-source information would have resolved the admission decision), and the recomputation witness binding these together. The authority’s decision — admit with conditions, refuse with falsifier, refer further — is recorded as an actuation act in the actuation anchor, co-signed, and witness-bound.

Harm gating with context enrichment (AIGP). Before the REFER is issued, AIGP’s pre-execution context enrichment runs: it traverses available KBs and data sources to gather the context the prompt presupposes but does not carry. A chemistry question from an account flagged as affiliated with a credentialed research institution may be resolved to ADMIT once the KB traversal retrieves the account’s institutional affiliation and the specification’s research-exemption clause is satisfied. The same question from an account with no retrievable context remains a typed gap → REFER. The REFER is issued with the traversal record: what was searched, what was found, what was not found, and why the gap could not be closed automatically.

Notification vs. gating. Not every harm-adjacent finding requires a gate refusal. The architecture distinguishes:

  • Gating: the actuation is withheld pending named-authority review (REFER at the actuation anchor)
  • Notification: the actuation proceeds but a typed alert is emitted to the named authority (the output validation passes, but a falsifier annotation in Certificate Field 6 records the condition under which the verdict would be falsified)
  • Logging: the actuation proceeds and the finding is recorded in AIGP’s forensic trail for post-hoc review

The governing specification’s prescriptive order declares, per consideration, which of these three dispositions applies. A harm consideration that is declared gating produces a REFER at the actuation anchor. A consideration declared notification-only produces an ADMIT with a falsifier annotation. A consideration declared logging-only produces an ADMIT with a forensic record but no certificate-level annotation. These are specification decisions, not implementation decisions.

Attributable authorization. When a named authority admits a REFER’d request, the authorization is:

  • Attributed to a specific named individual with verified standing for that actuation class
  • Time-stamped and content-bound (the authority signed over the specific request at a specific moment)
  • Witness-bound (the entire REFER → authority-decision → admit arc is in AIGP’s governance reinforcement record, recomputable end-to-end)
  • Scope-limited (the authorization applies to the declared scope of the actuation class; it does not carry over to a broader class without a new authorization act)

This is the structural answer to the question that every high-stakes AI deployment faces: “if this output causes harm, who authorized it and on what basis?” The answer is not “the AI system” and not “the deploying organization” — it is a named individual, holding declared standing, who reviewed a grounded recomputable record and made a documented decision. The authorization is independently verifiable by any qualified third party from retained witnesses alone.

A.11 Model Provider Family and Team Plans

Context. A model provider (an organization offering AI model access as a service) wants to offer shared-access plans: a family plan allowing multiple household members to share a subscription, or a team plan allowing multiple employees to share organizational access. Today, providers are structurally blocked from offering these plans at scale: they cannot establish, with a recomputable record, that a given invocation came from an authorized plan member rather than a credential-sharing violation, and they cannot attribute a harmful invocation to a specific member rather than to the plan-holder or to themselves.

The liability problem without the spec. Without Mars®, a model provider’s compliance posture on a shared-access plan is self-referencing: the provider asserts that their logging system recorded which member made which request, and that assertion is the entire audit trail. A regulator, a harmed third party, or a law enforcement agency cannot independently verify it. The provider cannot prove to themselves that their own logs have not been tampered with in a way that would expose the incorrect member to liability. And the provider cannot offer contractual SLAs to plan members about what is and isn’t attributed to them — because the attribution mechanism is internal and unverifiable.

The Mars® structure for shared-access plans.

Each plan member holds a named-authority standing declaration: an eight-field registered record (§02c §7), of which four are load-bearing in this scenario: verified identity (Field 1), authorized invocation classes (Field 2), scope-of-applicability (Field 3), and the signing key material (Field 8). The member’s public key is issued at plan enrollment; it is registered in the specification registry alongside the governing specification for the plan tier. “Authorized invocation classes” is the scope field: a family-plan member may be authorized for general-purpose queries; a minor may be authorized for a restricted invocation class that excludes adult-content and violence considerations; a team-plan member may be authorized for business-domain queries under the organization’s governing specification.

Each invocation is bound to its member via the inbound non-language-provenance anchor Field 5 (interpretation-execution record): the member’s identity, the timestamped content hash of their input, and the session binding. The member’s private key signs this field. An invocation without a valid member signature does not complete the inbound boundary — it cannot be ADMIT’d. Credential sharing is not just a policy violation; it is architecturally blocked: a second member using the first member’s credentials cannot produce a valid Field 5 signature unless they hold the first member’s private key.

Per-member scope enforcement. The governing specification for the plan tier declares, per invocation class, which considerations apply to which authorized scopes. A minor’s invocation class activates a prescriptive-order perspective specification that adds harm-gating considerations for age-restricted content. This is not a content filter applied post-hoc; it is a specification-level constraint that fires at CHECK before the model executes. The CHECK verdict for a minor’s prompt is evaluated against the minor-scoped prescriptive order; the same prompt from an adult member is evaluated against the adult-scoped prescriptive order. The verdicts may differ; both are independently recomputable.

Attribution of harmful invocations. When a harmful output is produced under a shared-access plan, the certificate carries:

  • Field 1: the target artifact (the output) with its identity
  • The actuation anchor Field 7: the co-signature of the specific named member whose invocation produced the output
  • AIGP’s forensic trail: the finding, the causal attribution, and the recomputation witness binding the output to the specific member’s invocation

The provider can demonstrate to a regulator or a court, from retained witnesses alone, that the harmful output was produced under the authorization of member X (named, with verified identity), under invocation class Y (declared in their standing record), at time T (timestamped in Field 5), and that no other member’s standing record authorizes that invocation class. The provider is not asserting this — they are presenting an independently verifiable record.

Liability break for the provider. The provider’s liability posture changes structurally. Under the current state of practice, a harmful output under a shared plan implicates the provider because the provider is the only authority asserting what happened. Under Mars®, the provider can demonstrate: (a) the member held a valid standing declaration authorizing the invocation class; (b) the governing specification’s CHECK gate evaluated the request and produced ADMIT (or, if REFER was issued, that the authorization chain for the REFER disposition is in the record); (c) the output was validated at the output locus and the verdict is in the certificate. The provider’s role is infrastructure and governance architecture — not the authorizing agent for the specific invocation.

Plan tiers as perspective specifications. Different plan tiers (family, individual, professional, enterprise) are modeled as perspective specifications over the provider’s governing specification. A family-plan perspective activates household-appropriate prescriptive constraints. A professional-plan perspective activates a broader invocation class with additional named-authority standing requirements (the professional’s license or credential). An enterprise-plan perspective integrates with the enterprise’s own governing specification (the plan member’s invocations are evaluated against both the provider’s governing specification and the enterprise’s). These are not separate products; they are registered perspective specifications over a shared governing specification, each independently auditable.

Reading across use cases

Several patterns recur across all eleven use cases:

The perspective specification is the jurisdiction, the tier, and the scope. Whether the governing constraint is a healthcare regulation, a financial rule, a coalition ROE, an enterprise policy, or a plan-tier restriction — it is always a registered perspective specification over a shared domain model. Verdicts are per-perspective and independently recomputable. Constraints are never silently merged.

The fail-closed base case is architectural. In every deployment context, a DDIL state or indeterminate admissibility verdict produces REFER, not ADMIT. A degraded sensor feed, a missing patient record, a context-starved prompt, an ambiguous harm assessment — all route to REFER. This is not a policy setting; it is a structural property of the CHECK gate.

The named authority is always identified. Every actuation requiring human authorization carries a named-authority co-signature with a declared standing record. The system never originates a named-authority decision. In shared-access plans, the named authority is the specific member; in clinical settings, the clinician; in coalition operations, the commanding officer. The authorization is always attributable to a specific person with declared standing.

The recomputation witness is the audit trail. In every use case, the audit trail is not a log of decisions — it is a recomputation witness from which decisions can be re-derived. Re-derivation detects unsound decisions that were never tampered with. A hash log confirms nothing was changed; a recomputation witness confirms the decision was sound in the first place.

Drift, sycophancy, and harm are structural problems with structural solutions. Model drift is detected as order-typed divergence from a recomputable baseline, attributed to a specific causal dimension by AIGP’s forensic record, and remediated via a witness-bound rule change in AIGP’s governance reinforcement loop. Sycophancy is a formal bracket crossing, detected at both loci by the same representation through AIGP’s sycophancy gate, attributed to model or prompt dimension. Harm-adjacent requests route to REFER with a grounded evidence record from AIGP’s pre-execution context enrichment, resolved by a named authority whose decision is witness-bound. None of these are policy problems solved by configuration — they are architectural properties of the governed invocation boundary.

Reinforcement is symmetric. Gap signals surface in all four artifact classes (model, specification, data source, KB) under the same declared policy, in every use case. A KB gap in a clinical KB and a specification gap in a financial specification receive the same reinforcement treatment — different targets, same mechanism.