# IARPG Operations Standards — IARPG-OPS-2

- **Version:** 2.0.4-wip
- **Status:** Work in progress
- **Updated:** 2026-07-20T12:04:07Z
- **Canonical catalog:** https://iarpg.com/standards
- **Machine catalog:** https://iarpg.com/standards-catalog.json
- **Record count:** 70

> Every authority has objectives. Every operative has a job. Allegiance defines the assignment—not moral alignment.

## Publication boundary

This document defines fictional game-design structures for espionage and intelligence operations. It is not real-world operational authorization, factual certification, legal advice, identity authentication, or a production multiplayer API.

## Normative language

- **MUST:** required for the declared structural conformance level.
- **SHOULD:** recommended unless a documented exception applies.
- **MAY:** optional supported behavior.

## Record index

- [COLL-01 — Collection Discipline Selection](#collection-discipline-selection)
- [HUM-01 — Source Handling](#source-handling)
- [HUM-02 — Source Reliability and Access](#source-reliability)
- [CI-01 — Counterintelligence Investigation](#counterintelligence-investigation)
- [CI-02 — Counterintelligence Case Development](#counterintelligence-case-development)
- [ANAL-01 — Competing Hypotheses and Assessment](#competing-hypotheses-and-assessment)
- [EVID-01 — Observation, Report, Interpretation, and Hypothesis](#observation-report-interpretation-and-hypothesis)
- [EVID-02 — Provenance, Confidence, and Corroboration](#provenance-confidence-and-corroboration)
- [EVID-03 — Evidence Custody and Handoff](#evidence-custody)
- [EVID-04 — Contradiction Handling](#contradiction-handling)
- [EVID-06 — Evidence Custody Difference Resolution](#evidence-custody-difference-resolution)
- [AUTH-01 — Authority Profile Schema](#authority-profile-schema)
- [FOUND-01 — Operational Neutrality and Authority](#operational-neutrality-and-authority)
- [FOUND-02 — Mandate, Customer, and Jurisdiction](#mandate-customer-and-jurisdiction)
- [FOUND-03 — Neutral Authority Profile Contract](#neutral-authority-profile)
- [FOUND-04 — Intelligence Customer Requirements](#intelligence-customer-requirements)
- [A11Y-01 — Accessibility and VR Comfort](#accessibility-and-vr-comfort)
- [CONF-03 — Batch Conformance Review](#batch-conformance-review)
- [GOV-01 — Versioning, Change Control, and Telemetry](#versioning-change-control-and-telemetry)
- [GOV-02 — Release Migration and Backward Compatibility](#release-migration-and-backward-compatibility)
- [GOV-04 — Release Promotion Gates](#release-promotion-gates)
- [SAFE-01 — Safety and Fiction Boundary](#safety-and-fiction-boundary)
- [TEL-01 — Live Operations Telemetry](#live-operations-telemetry)
- [MIG-01 — Lossless Mission and Package Migration](#lossless-mission-and-package-migration)
- [GAME-01 — Player Interaction and Social Stealth](#player-interaction-and-social-stealth)
- [GAME-02 — VR and Browser Role Interdependence](#vr-and-browser-role-interdependence)
- [LOCAL-01 — Browser-Local Saved Work](#browser-local-saved-work)
- [DEBR-02 — Structured Debrief Composition](#structured-debrief-composition)
- [DEBRIEF-01 — Debrief Product Contract](#debrief-product-contract)
- [MISS-01 — Intelligence Requirement](#intelligence-requirement)
- [MISS-02 — Mission Brief Contract](#mission-brief-contract)
- [MISS-03 — Mission Lifecycle](#mission-lifecycle)
- [MISS-04 — Roles and Information Asymmetry](#roles-and-information-asymmetry)
- [MISS-05 — Success, Abort, Extraction, and Debrief](#success-abort-extraction-and-debrief)
- [MISS-06 — Mission Event Logging](#mission-event-logging)
- [MISS-07 — Compromise and Abort Handling](#compromise-abort-handling)
- [PKG-02 — Offline Package Integrity Verification](#offline-package-integrity-verification)
- [PKG-03 — Conflict-aware Operation Package Merge](#conflict-aware-operation-package-merge)
- [DATA-01 — Browser-local Backup and Selective Restore](#browser-local-backup-and-selective-restore)
- [PUB-02 — Operation Package Publication Preview](#operation-package-publication-preview)
- [PKG-01 — Operation Package Format](#operation-package-format)
- [ROLE-01 — Role Handoffs and Decision Authority](#role-handoffs)
- [ROLE-02 — Information Asymmetry Disclosure](#information-asymmetry-disclosure)
- [ROLE-04 — Multi-role Handoff Replay](#multi-role-handoff-replay)
- [SIM-01 — Deterministic Mission State Machines](#deterministic-mission-state-machines)
- [SIM-02 — Simulation Conformance](#simulation-conformance)
- [SIM-03 — Deterministic Scenario Comparison](#deterministic-scenario-comparison)
- [TEST-01 — Deterministic Fixture Conformance](#deterministic-fixture-conformance)
- [AI-01 — Synthetic Source Disclosure and Authority](#synthetic-source-disclosure-and-authority)
- [AI-02 — Mission Claim Verification](#mission-claim-verification)
- [AI-03 — Synthetic Source Claim Packets](#synthetic-source-claim-packets)
- [ECON-01 — Operational Economy and Resource Pressure](#operational-economy-and-resource-pressure)
- [JUR-01 — Evidence-Based Jurisdiction and Warrants](#evidence-based-jurisdiction-and-warrants)
- [LOG-01 — Courier and Handoff State Machine](#courier-and-handoff-state-machine)
- [TASK-01 — Verified and Unverified Tasking](#verified-and-unverified-tasking)
- [COMMS-01 — Operational Communications](#operational-communications)
- [TRADE-01 — Cover Identity and Congruence](#cover-identity-and-congruence)
- [TRADE-02 — Surveillance, Detection, and Counter-Surveillance](#surveillance-detection-and-counter-surveillance)
- [TRADE-03 — Communications and Compartmentation](#communications-and-compartmentation)
- [TRADE-04 — Cover Degradation and Repair](#cover-degradation)
- [DATA-02 — Project Canonical JSON Profile](#project-canonical-json-profile)
- [PKG-04 — Portable Integrity Bundle](#portable-integrity-bundle)
- [PROV-01 — Non-Authenticating Provenance Envelope](#non-authenticating-provenance-envelope)
- [CONF-04 — Round-Trip Preservation](#round-trip-preservation)
- [DATA-03 — Browser-Local Tool Handoff](#browser-local-tool-handoff)
- [REC-01 — Recovery and Quarantine](#recovery-and-quarantine)
- [GOV-05 — Append-Only Review Ledger](#append-only-review-ledger)
- [COMP-01 — Tested Compatibility Matrix](#tested-compatibility-matrix)
- [HOST-01 — Target Hosting Smoke Evidence](#target-hosting-smoke-evidence)
- [A11Y-02 — Accessibility Evidence Publication](#accessibility-evidence-publication)

## COLL-01 — Collection Discipline Selection

<a id="collection-discipline-selection"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Collection
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/collection-discipline-selection
- **JSON:** https://iarpg.com/records/collection-discipline-selection.json

### Summary

HUMINT, SIGINT, OSINT, cyber, imagery, geospatial, and technical methods produce different evidence and exposure profiles.

### Purpose

Define how players and synthetic characters gather information while preserving source class, access path, reliability, and collection limitations.

### Rationale

Collection is useful only when the game can explain where information came from and what the collector could actually observe.

### Normative requirements

- **MUST** Every collection method declare what it can observe, what it cannot establish, and what exposure it creates.
- **MUST** Collection output identify source discipline and acquisition context.
- **SHOULD** Missions offer at least two plausible collection approaches when the environment supports them.
- **MAY** Collection disciplines conflict, requiring players to reconcile timing, identity, or attribution differences.

### Mission phases

- Plan
- Access
- Collect

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Approach source
- Observe environment
- Collect signal or document
- Record access limitations

### Inputs

- Collection requirement
- Source profile
- Access plan

### Outputs

- Source report
- Observation
- Collection log

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [The intelligence disciplines](/docs/report/typology-of-intelligence-operatives-and-tradecraft-frameworks-a-comprehensive-architecture-for-clandestine-beh#the-intelligence-disciplines-the-ints) — A multi-discipline intelligence taxonomy.
- [Technical and signals operatives](/docs/report/intelligence-operative-archetypes-and-tradecraft#technical-and-signals-operatives) — Technical collection roles and constraints.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## HUM-01 — Source Handling

<a id="source-handling"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Collection
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/source-handling
- **JSON:** https://iarpg.com/records/source-handling.json

### Summary

Human sources are relationships with access, motivation, reliability, vulnerability, and independent agency.

### Purpose

Define how players and synthetic characters gather information while preserving source class, access path, reliability, and collection limitations.

### Rationale

Collection is useful only when the game can explain where information came from and what the collector could actually observe.

### Normative requirements

- **MUST** Represent source access, motivation, placement, reliability history, and protection risk separately.
- **MUST** Store source statements as reports with attribution and context, not as direct game truth.
- **SHOULD** Allow sources to refuse, misunderstand, omit, exaggerate, or change cooperation based on treatment and risk.
- **MAY** Permit source relationships to outlive individual operations and change future access.

### Mission phases

- Access
- Collect
- Validate
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Approach source
- Observe environment
- Collect signal or document
- Record access limitations

### Inputs

- Collection requirement
- Source profile
- Access plan

### Outputs

- Source report
- Observation
- Collection log

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [HUMINT operatives](/docs/report/intelligence-operative-archetypes-and-tradecraft#humint-operatives) — Case officers, agents, sources, and relationship-centered collection.
- [State intelligence and HUMINT operatives](/docs/report/typology-of-intelligence-operatives-and-tradecraft-frameworks-a-comprehensive-architecture-for-clandestine-beh#state-intelligence-architecture-and-humint-operatives) — Source and case officer roles within an operational system.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## HUM-02 — Source Reliability and Access

<a id="source-reliability"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Collection
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/source-reliability
- **JSON:** https://iarpg.com/records/source-reliability.json

### Summary

Defines reliability, access, motivation, corroboration, handling restrictions, and change over time for sources.

### Purpose

Define how players and synthetic characters gather information while preserving source class, access path, reliability, and collection limitations.

### Rationale

Collection is useful only when the game can explain where information came from and what the collector could actually observe.

### Normative requirements

- **MUST** A source record separate access from reliability and reliability from truth of a specific report.
- **MUST** Reliability changes require a recorded event and reason rather than silent score mutation.
- **SHOULD** Motivation, placement, handling restrictions, and possible manipulation be visible to authorized roles.

### Mission phases

- Plan
- Collect
- Validate
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Approach source
- Observe environment
- Collect signal or document
- Record access limitations

### Inputs

- Collection requirement
- Source profile
- Access plan

### Outputs

- Source report
- Observation
- Collection log

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Player trust and reputation networks](/docs/report/hallucinated-ai-quest-design-in-vr-mmorpgs#player-trust-deception-and-reputation-networks) — Reliability learning and shared verification patterns.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## CI-01 — Counterintelligence Investigation

<a id="counterintelligence-investigation"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Counterintelligence
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/counterintelligence-investigation
- **JSON:** https://iarpg.com/records/counterintelligence-investigation.json

### Summary

Counterintelligence identifies compromise through competing explanations, evidence provenance, access analysis, behavioral change, and controlled tests.

### Purpose

Model detection, manipulation, insider risk, compromise, and competing explanations without omniscient accusation.

### Rationale

Counterintelligence play depends on case development, corroboration, and procedural consequences rather than instant server certainty.

### Normative requirements

- **MUST** Separate access, opportunity, action, motive, and attribution as distinct investigative questions.
- **MUST** Counterintelligence consequences require case evidence and reason codes rather than omniscient server accusation.
- **SHOULD** Offer controlled tests, source validation, audit, surveillance, and damage assessment as different investigative tools.
- **MAY** The apparent compromise be a deception operation intended to redirect investigators.

### Mission phases

- Task
- Plan
- Collect
- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Open suspect file
- Test contradiction
- Review access anomaly
- Escalate or close case

### Inputs

- Anomalies
- Access logs
- Witness reports
- Behavioral indicators

### Outputs

- Case file
- Compromise assessment
- Protective action

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Alliance leak investigation workflow](/docs/report/counterintelligence-directive-alliance-leak-investigation#investigative-workflow-and-timeline) — A structured fictional counterintelligence investigation.
- [Counterintelligence matrix](/docs/report/typology-of-intelligence-operatives-and-tradecraft-frameworks-a-comprehensive-architecture-for-clandestine-beh#the-counterintelligence-matrix-and-the-double-agent-paradigm) — Double-agent and insider-risk archetypes.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## CI-02 — Counterintelligence Case Development

<a id="counterintelligence-case-development"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Counterintelligence
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/counterintelligence-case-development
- **JSON:** https://iarpg.com/records/counterintelligence-case-development.json

### Summary

Defines anomaly intake, suspect files, corroboration, protective actions, warrant thresholds, and closure.

### Purpose

Model detection, manipulation, insider risk, compromise, and competing explanations without omniscient accusation.

### Rationale

Counterintelligence play depends on case development, corroboration, and procedural consequences rather than instant server certainty.

### Normative requirements

- **MUST** The case distinguish anomaly, suspect file, confirmed finding, and active protective action.
- **MUST** Escalation identify evidence threshold, jurisdiction, reviewing authority, and reversible versus irreversible consequence.
- **SHOULD** Alternative explanations remain available until explicitly closed.

### Mission phases

- Access
- Collect
- Validate
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Open suspect file
- Test contradiction
- Review access anomaly
- Escalate or close case

### Inputs

- Anomalies
- Access logs
- Witness reports
- Behavioral indicators

### Outputs

- Case file
- Compromise assessment
- Protective action

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Dual-axis case development](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Severity and evidentiary certainty as separate case dimensions.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## ANAL-01 — Competing Hypotheses and Assessment

<a id="competing-hypotheses-and-assessment"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Evidence & Analysis
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/competing-hypotheses-and-assessment
- **JSON:** https://iarpg.com/records/competing-hypotheses-and-assessment.json

### Summary

Analysis compares multiple explanations and records what evidence would discriminate among them.

### Purpose

Keep observations, reports, interpretations, hypotheses, assessments, and decisions distinct and traceable.

### Rationale

A reviewable intelligence game requires uncertainty and contradiction to survive the user interface rather than being flattened into a single truth score.

### Normative requirements

- **MUST** Material assessments identify at least one plausible alternative explanation when evidence is incomplete.
- **MUST** Each hypothesis list supporting, contradicting, and non-discriminating evidence.
- **SHOULD** Collection planning prioritize evidence that can distinguish among leading hypotheses.
- **MAY** Allow analysts to publish dissenting assessments with separate confidence and reasoning.

### Mission phases

- Plan
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Create evidence node
- Link support or contradiction
- Compare hypotheses
- Publish assessment

### Inputs

- Observations
- Source reports
- Documents
- Sensor events

### Outputs

- Hypotheses
- Assessment
- Decision support
- Evidence packet

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Alliance leak threat assessment](/docs/report/counterintelligence-directive-alliance-leak-investigation#threat-assessment) — Counterintelligence investigation with multiple suspects and evidence types.
- [Investigation workflow](/docs/report/counterintelligence-directive-alliance-leak-investigation#investigative-workflow-and-timeline) — Structured collection and analysis over time.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## EVID-01 — Observation, Report, Interpretation, and Hypothesis

<a id="observation-report-interpretation-and-hypothesis"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Evidence & Analysis
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/observation-report-interpretation-and-hypothesis
- **JSON:** https://iarpg.com/records/observation-report-interpretation-and-hypothesis.json

### Summary

The game separates what was observed, what a source reported, what an analyst inferred, and what explanation is being tested.

### Purpose

Keep observations, reports, interpretations, hypotheses, assessments, and decisions distinct and traceable.

### Rationale

A reviewable intelligence game requires uncertainty and contradiction to survive the user interface rather than being flattened into a single truth score.

### Normative requirements

- **MUST** Classify every dossier item as observation, source report, interpretation, hypothesis, assessment, or decision.
- **MUST** Preserve author, time, context, source, and revision lineage for each item.
- **SHOULD** Allow players to challenge, annotate, supersede, or retain competing interpretations without deleting the original record.
- **MAY** Display disagreements between roles as parallel analytic notes.

### Mission phases

- Collect
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Create evidence node
- Link support or contradiction
- Compare hypotheses
- Publish assessment

### Inputs

- Observations
- Source reports
- Documents
- Sensor events

### Outputs

- Hypotheses
- Assessment
- Decision support
- Evidence packet

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Strategic fit with explainable evidence](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Observation, report, interpretation, and hypothesis should remain distinct.
- [Counterintelligence data collection methodology](/docs/report/counterintelligence-directive-alliance-leak-investigation#data-collection-and-analysis-methodology) — Structured collection and suspect isolation.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## EVID-02 — Provenance, Confidence, and Corroboration

<a id="provenance-confidence-and-corroboration"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Evidence & Analysis
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/provenance-confidence-and-corroboration
- **JSON:** https://iarpg.com/records/provenance-confidence-and-corroboration.json

### Summary

Confidence is earned through source context, provenance, independence, consistency, and discriminating evidence.

### Purpose

Keep observations, reports, interpretations, hypotheses, assessments, and decisions distinct and traceable.

### Rationale

A reviewable intelligence game requires uncertainty and contradiction to survive the user interface rather than being flattened into a single truth score.

### Normative requirements

- **MUST** Every material claim carry provenance, source type, acquisition time, confidence, and reason codes.
- **MUST** Independent corroboration be required for mission-defined irreversible actions.
- **SHOULD** Confidence changes reference the specific evidence or contradiction responsible for the update.
- **MAY** Mission authors define different evidence thresholds for public attribution, operational action, and internal warning.

### Mission phases

- Collect
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Create evidence node
- Link support or contradiction
- Compare hypotheses
- Publish assessment

### Inputs

- Observations
- Source reports
- Documents
- Sensor events

### Outputs

- Hypotheses
- Assessment
- Decision support
- Evidence packet

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Recommended warrant architecture](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Severity and evidentiary certainty are separate axes.
- [Mission verification guidelines](/docs/report/hallucinated-ai-quest-design-in-vr-mmorpgs#mitigation-strategies-and-design-guidelines) — Verification tools and intentional reliability signals.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## EVID-03 — Evidence Custody and Handoff

<a id="evidence-custody"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Evidence & Analysis
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/evidence-custody
- **JSON:** https://iarpg.com/records/evidence-custody.json

### Summary

Defines custody, transformation, duplication, access, and handoff events for evidence packets.

### Purpose

Keep observations, reports, interpretations, hypotheses, assessments, and decisions distinct and traceable.

### Rationale

A reviewable intelligence game requires uncertainty and contradiction to survive the user interface rather than being flattened into a single truth score.

### Normative requirements

- **MUST** Each custody event identify the evidence item, prior custodian, new custodian, UTC time, location or system context, and transformation status.
- **MUST** Derived copies retain a link to the originating evidence item.
- **SHOULD** Broken custody reduce confidence or admissibility without automatically erasing informational value.

### Mission phases

- Collect
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Create evidence node
- Link support or contradiction
- Compare hypotheses
- Publish assessment

### Inputs

- Observations
- Source reports
- Documents
- Sensor events

### Outputs

- Hypotheses
- Assessment
- Decision support
- Evidence packet

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Evidence-based justice](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Evidence continuity and reviewable procedural consequences.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## EVID-04 — Contradiction Handling

<a id="contradiction-handling"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Evidence & Analysis
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/contradiction-handling
- **JSON:** https://iarpg.com/records/contradiction-handling.json

### Summary

Defines explicit contradiction relationships, review states, resolution, and preserved dissent.

### Purpose

Keep observations, reports, interpretations, hypotheses, assessments, and decisions distinct and traceable.

### Rationale

A reviewable intelligence game requires uncertainty and contradiction to survive the user interface rather than being flattened into a single truth score.

### Normative requirements

- **MUST** Contradictions remain visible until resolved by a new evidence event or documented analytic judgment.
- **MUST** Resolution identify which claim changed, why, and whether the superseded claim remains historically relevant.
- **SHOULD** The interface support unresolved dissent in final assessments.

### Mission phases

- Validate
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Create evidence node
- Link support or contradiction
- Compare hypotheses
- Publish assessment

### Inputs

- Observations
- Source reports
- Documents
- Sensor events

### Outputs

- Hypotheses
- Assessment
- Decision support
- Evidence packet

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Contradiction-based verification](/docs/report/hallucinated-ai-quest-design-in-vr-mmorpgs#sanity-check-mechanics-and-skill-based-detection) — Contradictions as player-facing verification interactions.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## EVID-06 — Evidence Custody Difference Resolution

<a id="evidence-custody-difference-resolution"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Evidence & Analysis
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/evidence-custody-difference-resolution
- **JSON:** https://iarpg.com/records/evidence-custody-difference-resolution.json

### Summary

Compare Evidence Packets, identify changed provenance and custody, and preserve unresolved disputes until an explicit resolution is recorded.

### Purpose

Compare Evidence Packets, identify changed provenance and custody, and preserve unresolved disputes until an explicit resolution is recorded.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Compare Evidence Packets, identify changed provenance and custody, and preserve unresolved disputes until an explicit resolution is recorded.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Collect
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Compare
- Resolve
- Annotate
- Export

### Inputs

- Two Evidence Packets
- Custody events
- Relationships

### Outputs

- Difference record
- Resolution record
- Preserved packets

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## AUTH-01 — Authority Profile Schema

<a id="authority-profile-schema"></a>

- **Status:** Guidance
- **Version:** 2.0.4-wip
- **Category:** Foundation
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/authority-profile-schema
- **JSON:** https://iarpg.com/records/authority-profile-schema.json

### Summary

Defines the machine-readable authority profile used by the directory and mission workbench.

### Purpose

Define the authority, customer, jurisdiction, mandate, and neutrality rules that make an operation intelligible without assigning permanent moral alignment.

### Rationale

A mission cannot be reviewed when its sponsor, customer, limits, and desired effect remain implicit.

### Normative requirements

- **MUST** Profiles validate stable identifiers, names, organizational type, customer, mandate, jurisdiction, motivations, priorities, constraints, blind spots, resources, style, and mission types.
- **MUST** The schema omit universal moral alignment.
- **MAY** Implementations extend profiles with local visual or narrative fields.

### Mission phases

- Task
- Plan

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review authority dossier
- Compare mandate constraints
- Accept or decline tasking
- Record conflict of interest

### Inputs

- Authority profile
- Customer requirement
- Jurisdiction profile

### Outputs

- Tasking context
- Mandate boundary
- Authority-specific success definition

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Authority and role taxonomy](/docs/report/intelligence-operative-archetypes-and-tradecraft#intelligence-operative-archetypes-and-tradecraft) — Structured profiles for operational worldbuilding.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## FOUND-01 — Operational Neutrality and Authority

<a id="operational-neutrality-and-authority"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Foundation
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/operational-neutrality-and-authority
- **JSON:** https://iarpg.com/records/operational-neutrality-and-authority.json

### Summary

Authorities define mandates, resources, constraints, and customers; the system does not assign permanent hero or villain status.

### Purpose

Define the authority, customer, jurisdiction, mandate, and neutrality rules that make an operation intelligible without assigning permanent moral alignment.

### Rationale

A mission cannot be reviewed when its sponsor, customer, limits, and desired effect remain implicit.

### Normative requirements

- **MUST** Every operation identify the sponsoring authority, customer, mandate, and jurisdiction before player acceptance.
- **MUST** No authority receive a permanent good, evil, hero, or villain flag in canonical game logic.
- **SHOULD** Conflicting authorities expose different objectives, constraints, and definitions of success without hiding their operational interests.
- **MAY** Authorities cooperate temporarily when requirements overlap, even when their long-term interests conflict.

### Mission phases

- Task
- Plan
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Review authority dossier
- Compare mandate constraints
- Accept or decline tasking
- Record conflict of interest

### Inputs

- Authority profile
- Customer requirement
- Jurisdiction profile

### Outputs

- Tasking context
- Mandate boundary
- Authority-specific success definition

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Geopolitical agnosticism and faction ecology](/docs/report/systemic-subterfuge-architecting-a-geopolitically-neutral-classless-espionage-mmo#architectural-pillar-i-geopolitical-agnosticism-and-dynamic-faction-ecology) — Neutral authority architecture and fluid loyalty.
- [Post-national worldbuilding](/docs/report/architectural-and-narrative-design-specifications-for-a-vr-first-post-national-espionage-mmo#post-national-worldbuilding-and-the-elimination-of-geopolitical-bias) — International representation without nationality-based moral assignment.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## FOUND-02 — Mandate, Customer, and Jurisdiction

<a id="mandate-customer-and-jurisdiction"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Foundation
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/mandate-customer-and-jurisdiction
- **JSON:** https://iarpg.com/records/mandate-customer-and-jurisdiction.json

### Summary

Operational authority is bounded by who requested the work, where it applies, what methods are permitted, and what review follows.

### Purpose

Define the authority, customer, jurisdiction, mandate, and neutrality rules that make an operation intelligible without assigning permanent moral alignment.

### Rationale

A mission cannot be reviewed when its sponsor, customer, limits, and desired effect remain implicit.

### Normative requirements

- **MUST** Tasking declare a customer, intelligence requirement, legal or organizational authority, and operating jurisdiction.
- **MUST** The mission distinguish authorized methods from prohibited or unsupported methods.
- **SHOULD** Cross-jurisdiction work declare which authority can recognize, deny, contest, or punish an action.
- **MAY** A mission include compartmented customers whose identities are revealed only when the player has the required access.

### Mission phases

- Task
- Plan
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Review authority dossier
- Compare mandate constraints
- Accept or decline tasking
- Record conflict of interest

### Inputs

- Authority profile
- Customer requirement
- Jurisdiction profile

### Outputs

- Tasking context
- Mandate boundary
- Authority-specific success definition

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [The multi-polar intelligence ecosystem](/docs/report/typology-of-intelligence-operatives-and-tradecraft-frameworks-a-comprehensive-architecture-for-clandestine-beh#the-multi-polar-intelligence-ecosystem) — State, private, corporate, and independent operational customers.
- [Recommended warrant architecture](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Jurisdiction and evidence thresholds remain separate from severity.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## FOUND-03 — Neutral Authority Profile Contract

<a id="neutral-authority-profile"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Foundation
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/neutral-authority-profile
- **JSON:** https://iarpg.com/records/neutral-authority-profile.json

### Summary

Defines the minimum public profile for a fictional authority without moral-alignment labels.

### Purpose

Define the authority, customer, jurisdiction, mandate, and neutrality rules that make an operation intelligible without assigning permanent moral alignment.

### Rationale

A mission cannot be reviewed when its sponsor, customer, limits, and desired effect remain implicit.

### Normative requirements

- **MUST** Every authority profile declare organizational type, customer, mandate, jurisdiction, motivations, priorities, constraints, blind spots, resources, and typical mission types.
- **MUST** Profiles omit permanent good, evil, hero, villain, righteous, or corrupt alignment fields.
- **SHOULD** Conflicts are expressed as incompatible requirements, methods, jurisdictions, incentives, or consequences.

### Mission phases

- Task
- Plan

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review authority dossier
- Compare mandate constraints
- Accept or decline tasking
- Record conflict of interest

### Inputs

- Authority profile
- Customer requirement
- Jurisdiction profile

### Outputs

- Tasking context
- Mandate boundary
- Authority-specific success definition

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Authority-neutral operational framing](/docs/report/intelligence-operative-archetypes-and-tradecraft#humint-operatives) — Authority and tradecraft context for multipolar assignments.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## FOUND-04 — Intelligence Customer Requirements

<a id="intelligence-customer-requirements"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Foundation
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/intelligence-customer-requirements
- **JSON:** https://iarpg.com/records/intelligence-customer-requirements.json

### Summary

Defines how a customer states the decision, deadline, acceptable uncertainty, and dissemination boundary behind a requirement.

### Purpose

Define the authority, customer, jurisdiction, mandate, and neutrality rules that make an operation intelligible without assigning permanent moral alignment.

### Rationale

A mission cannot be reviewed when its sponsor, customer, limits, and desired effect remain implicit.

### Normative requirements

- **MUST** The customer declare the decision or action the intelligence is intended to support.
- **MUST** The requirement identify deadline, acceptable uncertainty, dissemination boundary, and consequences of delay.
- **SHOULD** The customer distinguish desired evidence from a preferred conclusion.

### Mission phases

- Task
- Plan
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review authority dossier
- Compare mandate constraints
- Accept or decline tasking
- Record conflict of interest

### Inputs

- Authority profile
- Customer requirement
- Jurisdiction profile

### Outputs

- Tasking context
- Mandate boundary
- Authority-specific success definition

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Intelligence requirements and customers](/docs/report/intelligence-operative-archetypes-and-tradecraft#humint-operatives) — Operational archetypes and customer-facing intelligence work.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## A11Y-01 — Accessibility and VR Comfort

<a id="accessibility-and-vr-comfort"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance & Safety
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/accessibility-and-vr-comfort
- **JSON:** https://iarpg.com/records/accessibility-and-vr-comfort.json

### Summary

Defines equivalent access to operational information, controls, motion settings, and non-VR participation.

### Purpose

Maintain versioned publication, telemetry, accessibility, fiction boundaries, and reviewable change control.

### Rationale

A public standard needs explicit status, migration, limitations, and safety boundaries to remain durable.

### Normative requirements

- **MUST** Essential mission information have non-color, non-audio, non-motion, and non-VR-only equivalents.
- **MUST** Comfort controls include seated play, turn mode, locomotion option, vignette or equivalent, subtitle control, and reduced motion where relevant.
- **SHOULD** Role interactions remain possible through keyboard and assistive technology on browser workstations.

### Mission phases

- Plan
- Access
- Collect
- Validate
- Deliver
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect version
- Review reason code
- Choose comfort option
- Read change notice

### Inputs

- Release record
- Telemetry
- Accessibility profile

### Outputs

- Change log
- Migration note
- Conformance report

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [VR comfort considerations](/docs/report/carceral-mechanics-and-the-mental-hospital-loop-systems-design-for-virtual-reality-mmorpgs#vection-mitigation-and-vr-comfort) — Locomotion and motion-comfort research, used only as accessibility evidence.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## CONF-03 — Batch Conformance Review

<a id="batch-conformance-review"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance & Safety
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/batch-conformance-review
- **JSON:** https://iarpg.com/records/batch-conformance-review.json

### Summary

Review a local deterministic input set and publish aggregate plus per-artifact structural results without external transmission.

### Purpose

Review a local deterministic input set and publish aggregate plus per-artifact structural results without external transmission.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Review a local deterministic input set and publish aggregate plus per-artifact structural results without external transmission.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Plan
- Validate
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Import
- Classify
- Validate
- Export

### Inputs

- Multiple local JSON artifacts
- Project schemas
- Stable filenames

### Outputs

- Aggregate report
- Per-artifact results
- Input-set digest

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## GOV-01 — Versioning, Change Control, and Telemetry

<a id="versioning-change-control-and-telemetry"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance & Safety
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/versioning-change-control-and-telemetry
- **JSON:** https://iarpg.com/records/versioning-change-control-and-telemetry.json

### Summary

Public standard records are versioned, citable, machine-readable, and changed through visible release notes and test evidence.

### Purpose

Maintain versioned publication, telemetry, accessibility, fiction boundaries, and reviewable change control.

### Rationale

A public standard needs explicit status, migration, limitations, and safety boundaries to remain durable.

### Normative requirements

- **MUST** Every standard record publish code, version, status, canonical URL, summary, requirements, related records, and research links.
- **MUST** Breaking changes increment the major version and retain the superseded public record.
- **MUST** Current, guidance, experimental, planned, and retired states remain visibly distinct.
- **SHOULD** Mission implementations attach validation evidence and telemetry before claiming conformance.
- **MAY** Publish machine-readable catalogs, schemas, examples, and discovery manifests beside human-readable pages.

### Mission phases

- Task
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Inspect version
- Review reason code
- Choose comfort option
- Read change notice

### Inputs

- Release record
- Telemetry
- Accessibility profile

### Outputs

- Change log
- Migration note
- Conformance report

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Telemetry and live-ops tuning](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#telemetry-and-live-ops-tuning) — Instrumentation and controlled regional pilots.
- [Simulation and validation plan](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#simulation-validation-plan) — Shock testing and acceptance criteria before launch.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## GOV-02 — Release Migration and Backward Compatibility

<a id="release-migration-and-backward-compatibility"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance & Safety
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/release-migration-and-backward-compatibility
- **JSON:** https://iarpg.com/records/release-migration-and-backward-compatibility.json

### Summary

Defines versioning, migration, deprecation, compatibility windows, and preservation of prior mission records.

### Purpose

Maintain versioned publication, telemetry, accessibility, fiction boundaries, and reviewable change control.

### Rationale

A public standard needs explicit status, migration, limitations, and safety boundaries to remain durable.

### Normative requirements

- **MUST** Published mission and evidence records retain the standard version used when they were created.
- **MUST** Breaking field or behavior changes increment the major or minor release and publish a migration document.
- **SHOULD** WIP archives increment at least the patch number and include the -wip suffix; publishable releases increment the minor version.

### Mission phases

- Task
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect version
- Review reason code
- Choose comfort option
- Read change notice

### Inputs

- Release record
- Telemetry
- Accessibility profile

### Outputs

- Change log
- Migration note
- Conformance report

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Policy cycle and review](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#anti-exploit-and-governance-rules) — Published change windows and reversible policy updates.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## GOV-04 — Release Promotion Gates

<a id="release-promotion-gates"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance & Safety
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/release-promotion-gates
- **JSON:** https://iarpg.com/records/release-promotion-gates.json

### Summary

Require explicit pass, fail, or not-tested evidence for every gate before removing the WIP suffix and incrementing the minor version.

### Purpose

Require explicit pass, fail, or not-tested evidence for every gate before removing the WIP suffix and incrementing the minor version.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Require explicit pass, fail, or not-tested evidence for every gate before removing the WIP suffix and incrementing the minor version.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review
- Link evidence
- Decide
- Publish

### Inputs

- Validation record
- Release notes
- Gate evidence

### Outputs

- Promotion decision
- Stable target version
- Unresolved-gate list

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## SAFE-01 — Safety and Fiction Boundary

<a id="safety-and-fiction-boundary"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance & Safety
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/safety-and-fiction-boundary
- **JSON:** https://iarpg.com/records/safety-and-fiction-boundary.json

### Summary

Public material stays fictional, game-system focused, and clearly separated from real-world medical, legal, investigative, or tactical authority.

### Purpose

Maintain versioned publication, telemetry, accessibility, fiction boundaries, and reviewable change control.

### Rationale

A public standard needs explicit status, migration, limitations, and safety boundaries to remain durable.

### Normative requirements

- **MUST** Label organizations, authorities, operations, jurisdictions, and examples as fictional where ambiguity could cause harm.
- **MUST** Keep psychiatric status separate from guilt, danger, credibility, alignment, and punishment mechanics.
- **MUST** Do not investigate, validate, or amplify a visitor's real-world espionage or surveillance claims.
- **MUST** Keep public tradecraft documentation abstract and game-oriented rather than practically actionable for real-world wrongdoing.
- **SHOULD** Link real-world grounding and urgent-help information to the separate EspionagePsychosis.com resource.
- **MAY** Use content warnings and accessibility controls for distressing fictional scenarios.

### Mission phases

- Task
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Inspect version
- Review reason code
- Choose comfort option
- Read change notice

### Inputs

- Release record
- Telemetry
- Accessibility profile

### Outputs

- Change log
- Migration note
- Conformance report

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Strategic fit and representation boundary](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Avoid psychiatric framing as guilt or punishment.
- [Post-national worldbuilding and bias mitigation](/docs/report/architectural-and-narrative-design-specifications-for-a-vr-first-post-national-espionage-mmo#mitigating-techno-orientalism-and-casual-colonialism) — Representation constraints for international fiction.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## TEL-01 — Live Operations Telemetry

<a id="live-operations-telemetry"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance & Safety
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/live-operations-telemetry
- **JSON:** https://iarpg.com/records/live-operations-telemetry.json

### Summary

Defines privacy-conscious event telemetry, fairness indicators, operational health metrics, and change review.

### Purpose

Maintain versioned publication, telemetry, accessibility, fiction boundaries, and reviewable change control.

### Rationale

A public standard needs explicit status, migration, limitations, and safety boundaries to remain durable.

### Normative requirements

- **MUST** Telemetry fields be documented, purpose-limited, UTC timestamped, and separable from player-authored mission content.
- **MUST** Balance changes preserve a public reason, affected records, migration note, and rollback condition.
- **SHOULD** Metrics include false-positive restrictions, abort rates, evidence reversals, role imbalance, and accessibility failures.

### Mission phases

- Task
- Plan
- Access
- Collect
- Validate
- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect version
- Review reason code
- Choose comfort option
- Read change notice

### Inputs

- Release record
- Telemetry
- Accessibility profile

### Outputs

- Change log
- Migration note
- Conformance report

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Ledger and dashboard telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Immutable UTC telemetry and monitoring patterns.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MIG-01 — Lossless Mission and Package Migration

<a id="lossless-mission-and-package-migration"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance and Migration
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** WIP implemented
- **Canonical:** https://iarpg.com/standard/lossless-mission-and-package-migration
- **JSON:** https://iarpg.com/records/lossless-mission-and-package-migration.json

### Summary

Migrates OPS-1, early OPS-2, isolated component records, and current Operation Packages without silently discarding fields.

### Purpose

Migrates OPS-1, early OPS-2, isolated component records, and current Operation Packages without silently discarding fields.

### Rationale

The operations design system requires portable, inspectable, recoverable records so mission decisions and consequences can be reviewed across tools and release boundaries.

### Normative requirements

- **MUST** Produce a field-by-field migration report identifying original field, destination field, transformed value, action, reason, standard, and warning level.
- **MUST** Preserve unsupported or unknown data in an explicit extensions.unmapped_data collection.
- **SHOULD** Retain source release, source version, migration timestamp in UTC, and migration-tool version.
- **MAY** Apply reversible aliases for renamed fields where no semantic transformation is required.

### Mission phases

- Task
- Plan
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review structured record
- Load related local tool
- Inspect standards and report links
- Export normalized JSON
- Record UTC result

### Inputs

- Mission or package identifier
- Applicable authority and roles
- Evidence and state records
- Release and conformance metadata

### Outputs

- Human-readable publication view
- Machine-readable JSON
- Reason-coded validation findings
- Deep links to related standards and reports

### Evidence and provenance

- Record UTC timestamps, source identifiers, component versions, and reason codes.
- Preserve evidence class boundaries and unknown extension data.

### Failure behavior

Reject invalid structure with explicit findings, preserve the original input, and never discard unknown fields silently.

### Recovery behavior

Allow the user to repair input, restore a local draft, export preserved unmapped data, or restart from a published fixture.

### Supporting research

- [Immutable reversal pattern](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Corrections and migrations remain reviewable rather than deleting prior state.

### Revision history

- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## GAME-01 — Player Interaction and Social Stealth

<a id="player-interaction-and-social-stealth"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Interaction & Interfaces
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/player-interaction-and-social-stealth
- **JSON:** https://iarpg.com/records/player-interaction-and-social-stealth.json

### Summary

Social stealth evaluates behavioral congruence, access, timing, environment, and explanation rather than invisibility or costume alone.

### Purpose

Define what players actually do across VR and browser roles and how information asymmetry is represented accessibly.

### Rationale

Distinct roles need complementary information and meaningful actions rather than duplicated screens.

### Normative requirements

- **MUST** Suspicion derive from observable incongruence, restricted actions, known records, and environmental context.
- **MUST** Provide nonviolent paths for access, collection, recovery, and extraction when the mission design supports them.
- **SHOULD** NPC reactions communicate what changed through behavior, dialogue, posture, access, or attention.
- **MAY** Players recover from minor mistakes through explanation, assistance, delay, or role-consistent action.

### Mission phases

- Access
- Collect
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Observe
- Handle object
- Mark contradiction
- Coordinate handoff
- Request corroboration

### Inputs

- Role profile
- Mission state
- Information entitlement

### Outputs

- Interaction event
- Role handoff
- Updated mission state

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Social stealth and behavioral mimicry](/docs/report/architectural-and-narrative-design-specifications-for-a-vr-first-post-national-espionage-mmo#social-stealth-and-behavioral-mimicry) — Behavioral congruence as stealth.
- [Anatomy of suspicion and congruence](/docs/report/systemic-subterfuge-architecting-a-geopolitically-neutral-classless-espionage-mmo#the-anatomy-of-suspicion-and-congruence) — Suspicion from context and mismatch.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## GAME-02 — VR and Browser Role Interdependence

<a id="vr-and-browser-role-interdependence"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Interaction & Interfaces
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/vr-and-browser-role-interdependence
- **JSON:** https://iarpg.com/records/vr-and-browser-role-interdependence.json

### Summary

Embodied VR, desktop, mobile, and browser roles coordinate through complementary information and actions.

### Purpose

Define what players actually do across VR and browser roles and how information asymmetry is represented accessibly.

### Rationale

Distinct roles need complementary information and meaningful actions rather than duplicated screens.

### Normative requirements

- **MUST** Define unique responsibilities for embodied and non-embodied roles within the same mission requirement.
- **MUST** Synchronize authoritative mission state while allowing role-specific latency, visibility, and presentation.
- **SHOULD** Non-VR roles support short sessions, asynchronous continuity, and accessibility without trivializing field decisions.
- **MAY** The system adapt role distribution when a cell has fewer players than available roles.

### Mission phases

- Plan
- Access
- Collect
- Validate
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Observe
- Handle object
- Mark contradiction
- Coordinate handoff
- Request corroboration

### Inputs

- Role profile
- Mission state
- Information entitlement

### Outputs

- Interaction event
- Role handoff
- Updated mission state

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Asymmetric cross-platform multiplayer](/docs/report/architectural-and-narrative-design-specifications-for-a-vr-first-post-national-espionage-mmo#the-asymmetric-cross-platform-multiplayer-paradigm) — Cross-dimensional role design.
- [Mirrored interdependence and collaboration](/docs/report/architectural-and-narrative-design-specifications-for-a-vr-first-post-national-espionage-mmo#mirrored-interdependence-and-collaboration) — Complementary roles and shared operation state.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## LOCAL-01 — Browser-Local Saved Work

<a id="browser-local-saved-work"></a>

- **Status:** Guidance
- **Version:** 2.0.4-wip
- **Category:** Interface and Accessibility
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** WIP implemented
- **Canonical:** https://iarpg.com/standard/browser-local-saved-work
- **JSON:** https://iarpg.com/records/browser-local-saved-work.json

### Summary

Defines named, exportable, recoverable local drafts for missions, evidence packets, simulations, debriefs, packages, comparisons, and migration reports without accounts or server transmission.

### Purpose

Defines named, exportable, recoverable local drafts for missions, evidence packets, simulations, debriefs, packages, comparisons, and migration reports without accounts or server transmission.

### Rationale

The operations design system requires portable, inspectable, recoverable records so mission decisions and consequences can be reviewed across tools and release boundaries.

### Normative requirements

- **MUST** Keep saved work browser-local unless the user explicitly exports a file.
- **MUST** Provide named drafts, UTC modified time, rename, duplicate, export, delete confirmation, storage usage, and malformed-record recovery.
- **SHOULD** Keep saved records namespaced by release and content type and preserve unknown fields.
- **MAY** Provide import-all and export-all bundles for user-controlled backup.

### Mission phases

- Task
- Plan
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review structured record
- Load related local tool
- Inspect standards and report links
- Export normalized JSON
- Record UTC result

### Inputs

- Mission or package identifier
- Applicable authority and roles
- Evidence and state records
- Release and conformance metadata

### Outputs

- Human-readable publication view
- Machine-readable JSON
- Reason-coded validation findings
- Deep links to related standards and reports

### Evidence and provenance

- Record UTC timestamps, source identifiers, component versions, and reason codes.
- Preserve evidence class boundaries and unknown extension data.

### Failure behavior

Reject invalid structure with explicit findings, preserve the original input, and never discard unknown fields silently.

### Recovery behavior

Allow the user to repair input, restore a local draft, export preserved unmapped data, or restart from a published fixture.

### Supporting research

- [Player control and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#incarceration-and-player-experience) — Reliable controls and recoverable state protect the player-facing social contract.

### Revision history

- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## DEBR-02 — Structured Debrief Composition

<a id="structured-debrief-composition"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** WIP implemented
- **Canonical:** https://iarpg.com/standard/structured-debrief-composition
- **JSON:** https://iarpg.com/records/structured-debrief-composition.json

### Summary

Builds a debrief from mission, evidence, role handoffs, extraction state, and simulation events while separating facts, reports, interpretations, hypotheses, assessments, and decisions.

### Purpose

Builds a debrief from mission, evidence, role handoffs, extraction state, and simulation events while separating facts, reports, interpretations, hypotheses, assessments, and decisions.

### Rationale

The operations design system requires portable, inspectable, recoverable records so mission decisions and consequences can be reviewed across tools and release boundaries.

### Normative requirements

- **MUST** Separate observed facts, source reports, interpretations, hypotheses, assessments, decisions, unresolved contradictions, and missing evidence.
- **MUST** Record extraction state, source-protection actions, cover-recovery actions, authority-specific consequences, and follow-on intelligence requirements.
- **SHOULD** Link every material conclusion to evidence IDs, simulation event IDs, role handoffs, and reason codes.
- **MAY** Permit human editing before export while retaining machine-generated provenance notes.

### Mission phases

- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review structured record
- Load related local tool
- Inspect standards and report links
- Export normalized JSON
- Record UTC result

### Inputs

- Mission or package identifier
- Applicable authority and roles
- Evidence and state records
- Release and conformance metadata

### Outputs

- Human-readable publication view
- Machine-readable JSON
- Reason-coded validation findings
- Deep links to related standards and reports

### Evidence and provenance

- Record UTC timestamps, source identifiers, component versions, and reason codes.
- Preserve evidence class boundaries and unknown extension data.

### Failure behavior

Reject invalid structure with explicit findings, preserve the original input, and never discard unknown fields silently.

### Recovery behavior

Allow the user to repair input, restore a local draft, export preserved unmapped data, or restart from a published fixture.

### Supporting research

- [Evidence separation](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Severity and evidentiary certainty remain separate and reviewable.
- [Source reliability](/docs/report/hallucinated-ai-quest-design-in-vr-mmorpgs#player-trust-deception-and-reputation-networks) — Debriefs preserve source and claim reliability rather than flattening accounts into truth.

### Revision history

- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## DEBRIEF-01 — Debrief Product Contract

<a id="debrief-product-contract"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/debrief-product-contract
- **JSON:** https://iarpg.com/records/debrief-product-contract.json

### Summary

Defines the minimum human- and machine-readable output after success, partial success, conversion, abort, compromise, or failure.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** The debrief record objective status, evidence acquired, unresolved uncertainty, source impact, cover impact, access preserved or lost, and follow-on requirements.
- **MUST** The debrief preserve dissent and contradictory evidence.
- **SHOULD** The debrief distinguish player performance from authority satisfaction and broader operational consequence.

### Mission phases

- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [After-action reporting](/docs/report/after-action-report-operation-redacted#after-action-report-operation-redacted) — Example fictional after-action record structure.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MISS-01 — Intelligence Requirement

<a id="intelligence-requirement"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/intelligence-requirement
- **JSON:** https://iarpg.com/records/intelligence-requirement.json

### Summary

Every mission begins with a question or decision need that collection and analysis are meant to support.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** State the primary intelligence requirement as a decision-oriented question.
- **MUST** Separate the requirement from assumptions, preferred explanations, and desired political outcomes.
- **SHOULD** Define priority intelligence gaps and the minimum evidence needed to close them.
- **MAY** Include secondary requirements that become active when new evidence changes the operational picture.

### Mission phases

- Task
- Plan

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Case officer and operations cycle](/docs/report/typology-of-intelligence-operatives-and-tradecraft-frameworks-a-comprehensive-architecture-for-clandestine-beh#the-case-officer-and-the-intelligence-operations-cycle) — Requirement-driven tasking and operational coordination.
- [Strategic fit with evidence-based play](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Consequences should follow evidence and explainable reasons.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MISS-02 — Mission Brief Contract

<a id="mission-brief-contract"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/mission-brief-contract
- **JSON:** https://iarpg.com/records/mission-brief-contract.json

### Summary

A mission brief is a reviewable contract connecting authority, requirement, roles, constraints, evidence thresholds, abort conditions, and extraction.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** Include title, authority, mandate, intelligence requirement, jurisdiction, roles, known facts, assumptions, constraints, abort condition, extraction plan, and debrief deliverable.
- **MUST** Disclose whether rewards are engine-verified, authority-reviewed, or dependent on an unverified sponsor.
- **SHOULD** Expose evidence thresholds for irreversible actions and major consequence states.
- **MAY** Hide compartmented details behind role access while preserving the shared mission contract.

### Mission phases

- Task
- Plan
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Verified and unverified contract design](/docs/report/social-deception-and-player-generated-fake-quests#quest-design-unverified-vs-verified-contracts) — Transparent risk tiers for tasking and payment.
- [Escrow, verification, and reputation](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Trust signals, histories, and settlement boundaries.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MISS-03 — Mission Lifecycle

<a id="mission-lifecycle"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/mission-lifecycle
- **JSON:** https://iarpg.com/records/mission-lifecycle.json

### Summary

Operations progress through explicit lifecycle states from tasking to debrief, with observable transitions and recoverable failure states.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** Represent Task, Plan, Access, Collect, Validate, Deliver, Extract, and Debrief as distinct states or reviewable milestones.
- **MUST** Persist accepted brief revision, evidence state, role assignments, and consequence state across transitions.
- **SHOULD** Permit fail-forward transitions when a planned path closes but the intelligence requirement remains answerable.
- **MAY** Allow parallel collection tasks to converge into a shared validation state.

### Mission phases

- Task
- Plan
- Access
- Collect
- Validate
- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Case officer and intelligence operations cycle](/docs/report/typology-of-intelligence-operatives-and-tradecraft-frameworks-a-comprehensive-architecture-for-clandestine-beh#the-case-officer-and-the-intelligence-operations-cycle) — Role coordination through an intelligence cycle.
- [Fail-forward mission design](/docs/report/systemic-implementation-of-delusional-ai-and-hallucinated-mission-vectors-in-virtual-reality-mmorpgs#balancing-risk-reward-the-fail-forward-paradigm) — Failure changes the operation instead of erasing player time.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MISS-04 — Roles and Information Asymmetry

<a id="roles-and-information-asymmetry"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/roles-and-information-asymmetry
- **JSON:** https://iarpg.com/records/roles-and-information-asymmetry.json

### Summary

Operative, handler, analyst, technical, liaison, and support roles receive different information and actions while contributing to one requirement.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** Each assigned role have at least one unique information source, decision, or action that materially affects the operation.
- **MUST** Shared mission truth remain server-authoritative even when roles receive incomplete or conflicting views.
- **SHOULD** Role coordination reward concise handoffs, explicit uncertainty, and timely escalation.
- **MAY** One player occupy multiple low-intensity support roles when population is limited, provided information boundaries remain visible.

### Mission phases

- Plan
- Access
- Collect
- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Operative archetypes and support roles](/docs/report/intelligence-operative-archetypes-and-tradecraft#analytical-liaison-and-support-roles) — Distinct analytical, liaison, and support responsibilities.
- [Operative and handler interdependence](/docs/report/architectural-and-narrative-design-specifications-for-a-vr-first-post-national-espionage-mmo#interactive-cross-dimensional-media-the-operative-and-the-handler) — Asymmetric cross-platform interaction design.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MISS-05 — Success, Abort, Extraction, and Debrief

<a id="success-abort-extraction-and-debrief"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/success-abort-extraction-and-debrief
- **JSON:** https://iarpg.com/records/success-abort-extraction-and-debrief.json

### Summary

Operations define success beyond completion, permit professional aborts, and require extraction and debrief as first-class gameplay.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** Define complete success, partial success, professional abort, compromised extraction, and failed debrief outcomes.
- **MUST** Record why the operation ended and which intelligence gaps remain.
- **SHOULD** Reward source protection, cover preservation, evidence quality, and decision usefulness independently of objective completion.
- **MAY** Convert an unsuccessful collection attempt into future access, counterintelligence warning, or environmental discovery.

### Mission phases

- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Operational egress and contingencies](/docs/report/operational-directive-analog-tradecraft-and-counter-surveillance-in-high-density-virtual-urban-environments#operational-egress-and-contingencies) — Egress and contingency planning as part of the operation.
- [Mitigating zero-payout frustration](/docs/report/systemic-implementation-of-delusional-ai-and-hallucinated-mission-vectors-in-virtual-reality-mmorpgs#mitigating-the-frustration-of-zero-payout) — Fail-forward value and meaningful secondary outcomes.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MISS-06 — Mission Event Logging

<a id="mission-event-logging"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/mission-event-logging
- **JSON:** https://iarpg.com/records/mission-event-logging.json

### Summary

Requires durable UTC event records for consequential mission-state changes.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** Every consequential transition write an immutable event identifier, UTC timestamp, mission state, actor or system role, reason code, and related evidence identifiers.
- **MUST** Corrections append compensating events rather than deleting history.
- **SHOULD** The interface expose a human-readable explanation beside machine fields.

### Mission phases

- Task
- Plan
- Access
- Collect
- Validate
- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Immutable UTC ledger principles](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Double-entry and reversal patterns adapted to mission events.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## MISS-07 — Compromise and Abort Handling

<a id="compromise-abort-handling"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Mission Design
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/compromise-abort-handling
- **JSON:** https://iarpg.com/records/compromise-abort-handling.json

### Summary

Defines compromise indicators, decision authority, abort states, conversion, extraction, and recovery.

### Purpose

Turn an intelligence requirement into a playable, reviewable operation with explicit states, roles, evidence thresholds, abort conditions, extraction, and debriefing.

### Rationale

Structured mission contracts keep narrative, player interaction, and server-authoritative outcomes synchronized.

### Normative requirements

- **MUST** Mission briefs identify observable compromise indicators and who may declare abort, conversion, or emergency extraction.
- **MUST** An abort preserve collected evidence, source-protection obligations, and debrief requirements.
- **SHOULD** Partial success and converted objectives remain distinct from failure.

### Mission phases

- Access
- Collect
- Validate
- Deliver
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Read brief
- Assign roles
- Plan collection
- Select abort conditions
- Approve extraction

### Inputs

- Intelligence requirement
- Known facts
- Assumptions
- Authority constraints

### Outputs

- Mission brief
- Role tasking
- State machine
- Debrief contract

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Compromise and extraction doctrine](/docs/report/intelligence-operative-archetypes-and-tradecraft#intelligence-operative-archetypes-and-tradecraft) — Operative and handler responsibilities around compromise.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## PKG-02 — Offline Package Integrity Verification

<a id="offline-package-integrity-verification"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Package Lifecycle
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/offline-package-integrity-verification
- **JSON:** https://iarpg.com/records/offline-package-integrity-verification.json

### Summary

Recalculate canonical component hashes, validate package manifests, explain mismatches, and preserve failed imports unchanged.

### Purpose

Recalculate canonical component hashes, validate package manifests, explain mismatches, and preserve failed imports unchanged.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Recalculate canonical component hashes, validate package manifests, explain mismatches, and preserve failed imports unchanged.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Verify
- Record
- Export

### Inputs

- Package manifest
- Canonical package components
- Declared digests

### Outputs

- Integrity report
- Component mismatch findings
- Package digest

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## PKG-03 — Conflict-aware Operation Package Merge

<a id="conflict-aware-operation-package-merge"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Package Lifecycle
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/conflict-aware-operation-package-merge
- **JSON:** https://iarpg.com/records/conflict-aware-operation-package-merge.json

### Summary

Merge two packages without silent overwrite, preserve unknown extensions, and require explicit resolution for every content conflict.

### Purpose

Merge two packages without silent overwrite, preserve unknown extensions, and require explicit resolution for every content conflict.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Merge two packages without silent overwrite, preserve unknown extensions, and require explicit resolution for every content conflict.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Plan
- Validate
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Compare
- Resolve
- Record
- Export

### Inputs

- Two Operation Packages
- Source checksums
- Resolution choices

### Outputs

- Merged package
- Conflict record
- Merged component checksums

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## DATA-01 — Browser-local Backup and Selective Restore

<a id="browser-local-backup-and-selective-restore"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Publication & Data
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/browser-local-backup-and-selective-restore
- **JSON:** https://iarpg.com/records/browser-local-backup-and-selective-restore.json

### Summary

Export an indexed saved-work backup, detect duplicates, quarantine malformed records, and selectively restore exact record IDs and payloads.

### Purpose

Export an indexed saved-work backup, detect duplicates, quarantine malformed records, and selectively restore exact record IDs and payloads.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Export an indexed saved-work backup, detect duplicates, quarantine malformed records, and selectively restore exact record IDs and payloads.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Plan
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Save
- Backup
- Restore
- Quarantine

### Inputs

- Local work vault
- Record checksums
- Selection

### Outputs

- Backup manifest
- Restored records
- Quarantine log

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## PUB-02 — Operation Package Publication Preview

<a id="operation-package-publication-preview"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Publication & Data
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/operation-package-publication-preview
- **JSON:** https://iarpg.com/records/operation-package-publication-preview.json

### Summary

Render one package as a compact human brief, role packet, evidence index, simulation expectation, debrief contract, standards matrix, and machine-link set.

### Purpose

Render one package as a compact human brief, role packet, evidence index, simulation expectation, debrief contract, standards matrix, and machine-link set.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Render one package as a compact human brief, role packet, evidence index, simulation expectation, debrief contract, standards matrix, and machine-link set.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Task
- Plan
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Preview
- Print
- Copy link
- Export

### Inputs

- Selected Operation Package
- Schemas
- Standards catalog

### Outputs

- Human publication preview
- Print view
- Machine artifact links

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## PKG-01 — Operation Package Format

<a id="operation-package-format"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Publication and Interchange
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** WIP implemented
- **Canonical:** https://iarpg.com/standard/operation-package-format
- **JSON:** https://iarpg.com/records/operation-package-format.json

### Summary

Bundles a mission brief, authority, roles, evidence, deterministic simulation, debrief contract, conformance, migration metadata, and component checksums into one portable local record.

### Purpose

Bundles a mission brief, authority, roles, evidence, deterministic simulation, debrief contract, conformance, migration metadata, and component checksums into one portable local record.

### Rationale

The operations design system requires portable, inspectable, recoverable records so mission decisions and consequences can be reviewed across tools and release boundaries.

### Normative requirements

- **MUST** Include release metadata, mission brief, authority profile, role profiles, evidence packet, simulation configuration, debrief contract, conformance report, migration metadata, and component checksums.
- **MUST** Preserve unknown extension fields during import, editing, migration, and export.
- **SHOULD** Deep-link each component to applicable standards, mission examples, and canonical reports.
- **MAY** Include local saved-work metadata that is ignored by authoritative game services.

### Mission phases

- Task
- Plan
- Collect
- Validate
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review structured record
- Load related local tool
- Inspect standards and report links
- Export normalized JSON
- Record UTC result

### Inputs

- Mission or package identifier
- Applicable authority and roles
- Evidence and state records
- Release and conformance metadata

### Outputs

- Human-readable publication view
- Machine-readable JSON
- Reason-coded validation findings
- Deep links to related standards and reports

### Evidence and provenance

- Record UTC timestamps, source identifiers, component versions, and reason codes.
- Preserve evidence class boundaries and unknown extension data.

### Failure behavior

Reject invalid structure with explicit findings, preserve the original input, and never discard unknown fields silently.

### Recovery behavior

Allow the user to repair input, restore a local draft, export preserved unmapped data, or restart from a published fixture.

### Supporting research

- [Deterministic contract state machines](/docs/report/systemic-framework-for-trustless-escrow-and-courier-contracts-in-virtual-reality-massively-multiplayer-online-#3-2-the-deterministic-contract-state-machine) — Structured state and settlement records support portable operational packages.
- [Ledger and telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Immutable UTC events and reversals inform component checksums and audit records.

### Revision history

- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## ROLE-01 — Role Handoffs and Decision Authority

<a id="role-handoffs"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Roles & Handoffs
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/role-handoffs
- **JSON:** https://iarpg.com/records/role-handoffs.json

### Summary

Defines what each role transfers, what must be acknowledged, and who can approve consequential decisions.

### Purpose

Define operational roles, information entitlements, decision authority, escalation, and handoff requirements.

### Rationale

Information asymmetry is only fair when the interface explains who knew what, when, and why.

### Normative requirements

- **MUST** A handoff identify sender, recipient, information scope, classification or compartment, required acknowledgement, and unresolved gaps.
- **MUST** Decision authority be distinct from information access.
- **SHOULD** Failed or delayed acknowledgements create visible mission risk.

### Mission phases

- Plan
- Collect
- Validate
- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Open workstation
- Receive role packet
- Request handoff
- Escalate decision

### Inputs

- Role profile
- Information packet
- Mission state

### Outputs

- Handoff record
- Decision record
- Role-specific event

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Operative archetypes and handoffs](/docs/report/intelligence-operative-archetypes-and-tradecraft#intelligence-operative-archetypes-and-tradecraft) — Role specialization and interdependence.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## ROLE-02 — Information Asymmetry Disclosure

<a id="information-asymmetry-disclosure"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Roles & Handoffs
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/information-asymmetry-disclosure
- **JSON:** https://iarpg.com/records/information-asymmetry-disclosure.json

### Summary

Defines fair role-specific knowledge, withheld information, entitlement, and post-mission disclosure.

### Purpose

Define operational roles, information entitlements, decision authority, escalation, and handoff requirements.

### Rationale

Information asymmetry is only fair when the interface explains who knew what, when, and why.

### Normative requirements

- **MUST** The system record what each role could know at every consequential decision point.
- **MUST** Withheld information follow a declared compartment, access, timing, or source-protection rule.
- **SHOULD** Debrief reveal role asymmetry when doing so does not violate ongoing source protection.

### Mission phases

- Task
- Plan
- Access
- Collect
- Validate
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Open workstation
- Receive role packet
- Request handoff
- Escalate decision

### Inputs

- Role profile
- Information packet
- Mission state

### Outputs

- Handoff record
- Decision record
- Role-specific event

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Role-specific information](/docs/report/intelligence-operative-archetypes-and-tradecraft#intelligence-operative-archetypes-and-tradecraft) — Role capability and information boundaries.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## ROLE-04 — Multi-role Handoff Replay

<a id="multi-role-handoff-replay"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Roles & Interaction
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/multi-role-handoff-replay
- **JSON:** https://iarpg.com/records/multi-role-handoff-replay.json

### Summary

Replay what each role knew, transmitted, withheld, acknowledged, or missed in stable UTC order.

### Purpose

Replay what each role knew, transmitted, withheld, acknowledged, or missed in stable UTC order.

### Rationale

Integrity-aware local tooling is useful only when state changes, conflicts, evidence custody, and release decisions remain inspectable and reversible.

### Normative requirements

- **MUST** Replay what each role knew, transmitted, withheld, acknowledged, or missed in stable UTC order.
- **MUST** The implementation preserve imported source content and unknown fields unless a user explicitly selects and records a transformation.
- **SHOULD** The interface expose applicable standards, UTC event times, reason codes, and exportable machine-readable records.

### Mission phases

- Task
- Plan
- Access
- Collect
- Validate
- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Replay
- Filter
- Acknowledge
- Review

### Inputs

- Role handoff events
- Information boundaries
- Mission state

### Outputs

- Role timeline
- Acknowledgement record
- State-effect explanation

### Evidence and provenance

- Every consequential result records source identifiers, UTC event time, canonical digest where applicable, responsible local action, and reason code.
- Integrity results distinguish equality from authenticity and never identify a human signer.

### Failure behavior

Fail closed for publication or irreversible merge output. Preserve every imported artifact, explain the failure, and permit export of the original plus the failure record.

### Recovery behavior

Return to the last preserved source state, select or annotate an explicit resolution, recalculate affected digests, and record the new result without altering the originals.

### Supporting research

- [Evidence-based justice and review](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#strategic-fit-with-rogue-intelligence) — Supports explainable reasons, evidence continuity, and reviewable consequences.
- [Trust and explicit contract risk](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Supports transparent risk, escrow, verification, and durable transaction records.

### Revision history

- **2.0.3-wip · 2026-07-19T18:45:50Z** — Initial IARPG-OPS-2 2.0.3-wip publication.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## SIM-01 — Deterministic Mission State Machines

<a id="deterministic-mission-state-machines"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Simulation & Conformance
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/deterministic-mission-state-machines
- **JSON:** https://iarpg.com/records/deterministic-mission-state-machines.json

### Summary

Defines mission states, allowed transitions, guards, effects, event records, and reproducible simulation input.

### Purpose

Represent operations as deterministic, inspectable state machines with reproducible logs and declared conformance levels.

### Rationale

Simulation claims are meaningful only when the transition rules, inputs, seed, and event log are inspectable.

### Normative requirements

- **MUST** A simulatable mission declare finite states, allowed transitions, guard conditions, effects, and terminal outcomes.
- **MUST** Given the same mission version, seed, and action sequence, the simulator produce the same event log.
- **SHOULD** Randomness influence uncertainty without hiding transition rules.

### Mission phases

- Task
- Plan
- Access
- Collect
- Validate
- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Load mission
- Choose action
- Advance state
- Export event log

### Inputs

- Mission JSON
- State rules
- Deterministic seed

### Outputs

- Simulation record
- Conformance result
- Event log

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Finite state machine architecture](/docs/report/systemic-architecture-for-trustless-escrow-and-courier-contracts-in-a-virtual-reality-mmorpg#2-1-finite-state-machine-fsm-architecture) — Deterministic contract state machine patterns adapted to operations.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## SIM-02 — Simulation Conformance

<a id="simulation-conformance"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Simulation & Conformance
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/simulation-conformance
- **JSON:** https://iarpg.com/records/simulation-conformance.json

### Summary

Defines Level D — Simulatable and the limits of structural simulation conformance.

### Purpose

Represent operations as deterministic, inspectable state machines with reproducible logs and declared conformance levels.

### Rationale

Simulation claims are meaningful only when the transition rules, inputs, seed, and event log are inspectable.

### Normative requirements

- **MUST** Level D include explicit states, transitions, interactions, evidence events, failure paths, extraction states, and debrief outputs.
- **MUST** Conformance reports identify what was structurally checked and what remains outside the validator scope.
- **SHOULD** Examples include reproducible seeds and expected terminal states.

### Mission phases

- Plan
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Load mission
- Choose action
- Advance state
- Export event log

### Inputs

- Mission JSON
- State rules
- Deterministic seed

### Outputs

- Simulation record
- Conformance result
- Event log

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Simulation and validation plan](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#simulation-validation-plan) — Stress-test and acceptance-criteria patterns.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## SIM-03 — Deterministic Scenario Comparison

<a id="deterministic-scenario-comparison"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Simulation and Testing
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** WIP implemented
- **Canonical:** https://iarpg.com/standard/deterministic-scenario-comparison
- **JSON:** https://iarpg.com/records/deterministic-scenario-comparison.json

### Summary

Compares two decision branches from the same mission, starting state, evidence packet, authority, role allocation, and visible seed.

### Purpose

Compares two decision branches from the same mission, starting state, evidence packet, authority, role allocation, and visible seed.

### Rationale

The operations design system requires portable, inspectable, recoverable records so mission decisions and consequences can be reviewed across tools and release boundaries.

### Normative requirements

- **MUST** Use the same normalized starting package and deterministic seed for both compared branches.
- **MUST** Explain every divergent state transition, meter change, evidence outcome, extraction state, and debrief conclusion.
- **SHOULD** Produce a normalized JSON comparison artifact and accessible nonvisual difference table.
- **MAY** Allow a designer to replay either branch inside the simulator.

### Mission phases

- Task
- Plan
- Access
- Collect
- Validate
- Deliver
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review structured record
- Load related local tool
- Inspect standards and report links
- Export normalized JSON
- Record UTC result

### Inputs

- Mission or package identifier
- Applicable authority and roles
- Evidence and state records
- Release and conformance metadata

### Outputs

- Human-readable publication view
- Machine-readable JSON
- Reason-coded validation findings
- Deep links to related standards and reports

### Evidence and provenance

- Record UTC timestamps, source identifiers, component versions, and reason codes.
- Preserve evidence class boundaries and unknown extension data.

### Failure behavior

Reject invalid structure with explicit findings, preserve the original input, and never discard unknown fields silently.

### Recovery behavior

Allow the user to repair input, restore a local draft, export preserved unmapped data, or restart from a published fixture.

### Supporting research

- [Agent-based validation](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#simulation-validation-plan) — Controlled scenario tests reveal unstable decision and economic behavior.
- [Verification loops](/docs/report/hallucinated-ai-quest-design-in-vr-mmorpgs#sanity-check-mechanics-and-skill-based-detection) — Branch comparisons show the impact of corroboration versus unverified acceptance.

### Revision history

- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## TEST-01 — Deterministic Fixture Conformance

<a id="deterministic-fixture-conformance"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Simulation and Testing
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** WIP implemented
- **Canonical:** https://iarpg.com/standard/deterministic-fixture-conformance
- **JSON:** https://iarpg.com/records/deterministic-fixture-conformance.json

### Summary

Defines build-time and browser-local fixture checks for missions, evidence, simulation, migration, debrief, comparison, and Operation Packages.

### Purpose

Defines build-time and browser-local fixture checks for missions, evidence, simulation, migration, debrief, comparison, and Operation Packages.

### Rationale

The operations design system requires portable, inspectable, recoverable records so mission decisions and consequences can be reviewed across tools and release boundaries.

### Normative requirements

- **MUST** Check required fields, referential integrity, declared conformance, stable normalized export, deterministic replay, migration preservation, and valid standards and report links.
- **MUST** Avoid claiming complete JSON Schema draft compliance unless a complete compliant validator is actually used.
- **SHOULD** Publish summarized fixture results in VALIDATION.txt and machine-readable JSON.
- **MAY** Expose a browser view that lets readers inspect fixture results without modifying them.

### Mission phases

- Task
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Review structured record
- Load related local tool
- Inspect standards and report links
- Export normalized JSON
- Record UTC result

### Inputs

- Mission or package identifier
- Applicable authority and roles
- Evidence and state records
- Release and conformance metadata

### Outputs

- Human-readable publication view
- Machine-readable JSON
- Reason-coded validation findings
- Deep links to related standards and reports

### Evidence and provenance

- Record UTC timestamps, source identifiers, component versions, and reason codes.
- Preserve evidence class boundaries and unknown extension data.

### Failure behavior

Reject invalid structure with explicit findings, preserve the original input, and never discard unknown fields silently.

### Recovery behavior

Allow the user to repair input, restore a local draft, export preserved unmapped data, or restart from a published fixture.

### Supporting research

- [Simulation validation plan](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#simulation-validation-plan) — Long-running shock and archetype tests inform acceptance criteria.

### Revision history

- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## AI-01 — Synthetic Source Disclosure and Authority

<a id="synthetic-source-disclosure-and-authority"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Synthetic Sources
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/synthetic-source-disclosure-and-authority
- **JSON:** https://iarpg.com/records/synthetic-source-disclosure-and-authority.json

### Summary

Synthetic characters and generated dialogue are visibly disclosed and cannot create authoritative game facts, inventory, permissions, or settlement.

### Purpose

Bound generated dialogue and unreliable synthetic claims so language generation cannot silently control authoritative game truth.

### Rationale

Players must be able to distinguish a synthetic claim from a verified location, object, reward, warrant, or mission outcome.

### Normative requirements

- **MUST** Disclose synthetic characters and generated responses in the interaction surface.
- **MUST** Keep mission facts, inventory, access, rewards, legal status, and world state server-authoritative.
- **MUST** Treat synthetic output as a report or claim unless validated against authoritative state.
- **SHOULD** Store only reviewed, scoped continuity in durable character memory.
- **MAY** Synthetic sources intentionally mislead when the mission clearly supports verification and fail-forward outcomes.

### Mission phases

- Access
- Collect
- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Inspect source disclosure
- Verify claim packet
- Compare reliability history
- Accept, defer, or reject claim

### Inputs

- Synthetic statement
- Server claim packet
- Source history

### Outputs

- Verified claim
- Contradiction
- Deferred tasking
- Reliability update

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Controlled generative architecture](/docs/report/systemic-implementation-of-delusional-ai-and-hallucinated-mission-vectors-in-virtual-reality-mmorpgs#generative-architectures-for-delusional-npcs) — Separate mechanical truth from narrative generation.
- [Mitigation strategies and design guidelines](/docs/report/hallucinated-ai-quest-design-in-vr-mmorpgs#mitigation-strategies-and-design-guidelines) — Reliability signaling, player agency, and bounded falsehoods.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## AI-02 — Mission Claim Verification

<a id="mission-claim-verification"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Synthetic Sources
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/mission-claim-verification
- **JSON:** https://iarpg.com/records/mission-claim-verification.json

### Summary

Potentially unreliable tasking is checked against records, world state, source history, logic, location, and mission economics before acceptance.

### Purpose

Bound generated dialogue and unreliable synthetic claims so language generation cannot silently control authoritative game truth.

### Rationale

Players must be able to distinguish a synthetic claim from a verified location, object, reward, warrant, or mission outcome.

### Normative requirements

- **MUST** Provide at least one accessible method to test high-impact mission claims before commitment.
- **MUST** Distinguish object, relation, event, location, authority, and reward claims in the verification model.
- **SHOULD** Use reliability history, contradiction checks, coordinate checks, source comparison, and authority confirmation as complementary tools.
- **SHOULD** False or misleading tasking still produce some recoverable intelligence, discovery, or progression value when pursued in good faith.
- **MAY** Player skills prioritize anomalies but never output infallible truth labels.

### Mission phases

- Task
- Plan
- Validate

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Inspect source disclosure
- Verify claim packet
- Compare reliability history
- Accept, defer, or reject claim

### Inputs

- Synthetic statement
- Server claim packet
- Source history

### Outputs

- Verified claim
- Contradiction
- Deferred tasking
- Reliability update

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Sanity-check mechanics and skill-based detection](/docs/report/hallucinated-ai-quest-design-in-vr-mmorpgs#sanity-check-mechanics-and-skill-based-detection) — Verification as an active gameplay loop.
- [Taxonomy of hallucinated vectors](/docs/report/systemic-implementation-of-delusional-ai-and-hallucinated-mission-vectors-in-virtual-reality-mmorpgs#the-taxonomy-of-hallucinated-vectors) — Object, relation, and event falsehood classes.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## AI-03 — Synthetic Source Claim Packets

<a id="synthetic-source-claim-packets"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Synthetic Sources
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/synthetic-source-claim-packets
- **JSON:** https://iarpg.com/records/synthetic-source-claim-packets.json

### Summary

Defines the machine-readable boundary between generated language, claimed entities or events, verification state, and authoritative game records.

### Purpose

Bound generated dialogue and unreliable synthetic claims so language generation cannot silently control authoritative game truth.

### Rationale

Players must be able to distinguish a synthetic claim from a verified location, object, reward, warrant, or mission outcome.

### Normative requirements

- **MUST** Every consequential synthetic claim identify claim type, referenced entity, source, UTC time, confidence, verification state, and authoritative lookup result.
- **MUST** Generated language cannot create objects, locations, rewards, warrants, contracts, or mission completion.
- **SHOULD** Unreliable claims provide intentional and accessible verification opportunities.

### Mission phases

- Collect
- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect source disclosure
- Verify claim packet
- Compare reliability history
- Accept, defer, or reject claim

### Inputs

- Synthetic statement
- Server claim packet
- Source history

### Outputs

- Verified claim
- Contradiction
- Deferred tasking
- Reliability update

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Structured claim generation](/docs/report/systemic-implementation-of-delusional-ai-and-hallucinated-mission-vectors-in-virtual-reality-mmorpgs#the-taxonomy-of-hallucinated-vectors) — Separation of narrative output and mechanical truth.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## ECON-01 — Operational Economy and Resource Pressure

<a id="operational-economy-and-resource-pressure"></a>

- **Status:** Guidance
- **Version:** 2.0.4-wip
- **Category:** Tasking & Logistics
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/operational-economy-and-resource-pressure
- **JSON:** https://iarpg.com/records/operational-economy-and-resource-pressure.json

### Summary

Currency, access, time, cover, source trust, equipment, transport, and safe locations are operational resources with explicit creation, transfer, lock, and destruction semantics.

### Purpose

Define trusted and untrusted tasking, deterministic handoffs, operational resources, jurisdiction, and support systems.

### Rationale

Operational logistics must expose risk, settlement, custody, and failure states before a player commits time or collateral.

### Normative requirements

- **MUST** Classify currency events as creation, destruction, transfer, lock, or unlock in an immutable UTC ledger.
- **MUST** Treat escrow and frozen funds as temporary locks unless a separate rule destroys or forfeits value.
- **SHOULD** Compose mission rewards from currency, access, intelligence, reputation, supplies, and persistent opportunities rather than raw cash alone.
- **SHOULD** Measure newcomer and operational affordability before changing sinks or payouts.
- **MAY** Use property, communications, transport, cover maintenance, and logistics as mission-relevant sinks.

### Mission phases

- Task
- Plan
- Deliver
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Accept tasking
- Lock escrow
- Carry package
- Complete handoff
- Review warrant reason

### Inputs

- Task contract
- Cargo or intelligence packet
- Jurisdiction state

### Outputs

- Settlement event
- Handoff record
- Warrant or clearance event

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Currency flow definitions](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#currency-flow-definitions) — Creation, destruction, transfer, lock, and unlock semantics.
- [Ledger schema and telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Immutable double-entry records with UTC timestamps.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## JUR-01 — Evidence-Based Jurisdiction and Warrants

<a id="evidence-based-jurisdiction-and-warrants"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Tasking & Logistics
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/evidence-based-jurisdiction-and-warrants
- **JSON:** https://iarpg.com/records/evidence-based-jurisdiction-and-warrants.json

### Summary

Severity and evidentiary certainty are separate axes; jurisdiction determines who can observe, investigate, restrict, pursue, or review.

### Purpose

Define trusted and untrusted tasking, deterministic handoffs, operational resources, jurisdiction, and support systems.

### Rationale

Operational logistics must expose risk, settlement, custody, and failure states before a player commits time or collateral.

### Normative requirements

- **MUST** Track offense severity separately from evidentiary certainty.
- **MUST** Use anomaly, suspect file, confirmed warrant, and active manhunt as distinguishable case states.
- **MUST** Expose reason codes, jurisdiction, evidence basis, review path, and applicable restrictions.
- **SHOULD** Fund bounty outcomes through fines, bonds, seized value, or capped budgets rather than unconstrained currency creation.
- **SHOULD** Provide surrender, appeal, restitution, review, evasion, and lawful resolution paths.
- **MAY** Different jurisdictions recognize or contest the same case differently based on evidence and agreements.

### Mission phases

- Collect
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Accept tasking
- Lock escrow
- Carry package
- Complete handoff
- Review warrant reason

### Inputs

- Task contract
- Cargo or intelligence packet
- Jurisdiction state

### Outputs

- Settlement event
- Handoff record
- Warrant or clearance event

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Recommended warrant architecture](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Dual-axis severity and certainty model.
- [Economy and anti-exploit controls](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#economy-and-anti-exploit-controls) — Bounty funding and anti-collusion constraints.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## LOG-01 — Courier and Handoff State Machine

<a id="courier-and-handoff-state-machine"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Tasking & Logistics
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/courier-and-handoff-state-machine
- **JSON:** https://iarpg.com/records/courier-and-handoff-state-machine.json

### Summary

Physical or digital operational handoffs use deterministic states, accessible destinations, tamper evidence, timeouts, and reviewable settlement.

### Purpose

Define trusted and untrusted tasking, deterministic handoffs, operational resources, jurisdiction, and support systems.

### Rationale

Operational logistics must expose risk, settlement, custody, and failure states before a player commits time or collateral.

### Normative requirements

- **MUST** Use Created, Accepted, In Transit, Delivered, Breached, Expired, and Canceled states with atomic settlement.
- **MUST** Verify destination accessibility before posting and protect accepted couriers from later access revocation or obstruction.
- **MUST** Keep reward, collateral, cargo ownership, and fees distinct in the economic ledger.
- **SHOULD** Physicalized cargo communicate burden and tamper state without exposing protected contents by default.
- **MAY** Support remote perimeter deposit when post-acceptance obstruction would otherwise make delivery impossible.

### Mission phases

- Plan
- Deliver
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Accept tasking
- Lock escrow
- Carry package
- Complete handoff
- Review warrant reason

### Inputs

- Task contract
- Cargo or intelligence packet
- Jurisdiction state

### Outputs

- Settlement event
- Handoff record
- Warrant or clearance event

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Finite state machine architecture](/docs/report/systemic-architecture-for-trustless-escrow-and-courier-contracts-in-a-virtual-reality-mmorpg#2-1-finite-state-machine-fsm-architecture) — Deterministic contract lifecycle.
- [Universal perimeter receptacle](/docs/report/systemic-architecture-for-trustless-escrow-and-courier-contracts-in-a-virtual-reality-mmorpg#5-0-systemic-resolutions-the-universal-perimeter-receptacle-upr) — Delivery access separated from private structure permissions.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## TASK-01 — Verified and Unverified Tasking

<a id="verified-and-unverified-tasking"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Tasking & Logistics
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/verified-and-unverified-tasking
- **JSON:** https://iarpg.com/records/verified-and-unverified-tasking.json

### Summary

Verified tasking uses engine-backed terms and settlement; unverified tasking exposes disclosed counterparty and deception risk.

### Purpose

Define trusted and untrusted tasking, deterministic handoffs, operational resources, jurisdiction, and support systems.

### Rationale

Operational logistics must expose risk, settlement, custody, and failure states before a player commits time or collateral.

### Normative requirements

- **MUST** Label tasking as verified, authority-reviewed, reputation-backed, or unverified before acceptance.
- **MUST** Verified tasking lock reward terms and use deterministic completion or review rules.
- **MUST** Unverified tasking disclose that objective, reward, or sponsor claims may fail without engine settlement.
- **SHOULD** Expose issuer history, proof of interaction, dispute record, and relevant reputation without presenting them as infallible truth.
- **MAY** Unverified tasking offer higher potential reward or unique access to justify risk.

### Mission phases

- Task
- Plan
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Accept tasking
- Lock escrow
- Carry package
- Complete handoff
- Review warrant reason

### Inputs

- Task contract
- Cargo or intelligence packet
- Jurisdiction state

### Outputs

- Settlement event
- Handoff record
- Warrant or clearance event

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Quest design: unverified vs verified](/docs/report/social-deception-and-player-generated-fake-quests#quest-design-unverified-vs-verified-contracts) — Safety-with-fee versus freedom-with-risk.
- [Trust recovery through escrow and reputation](/docs/report/trust-deception-and-virtual-economies#escrow-verification-and-reputation-systems) — Layered trust signals and dispute histories.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## COMMS-01 — Operational Communications

<a id="operational-communications"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Tradecraft
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/operational-communications
- **JSON:** https://iarpg.com/records/operational-communications.json

### Summary

Defines channel purpose, authentication, delay, compromise indicators, fallback, and communication records at a game abstraction level.

### Purpose

Translate cover, access, surveillance awareness, communications, and compartmentation into fictional game interactions.

### Rationale

Tradecraft becomes meaningful when player behavior, access rationale, and operational signatures affect mission state.

### Normative requirements

- **MUST** A communications plan declare channel purpose, authorized roles, failure indicator, and fallback.
- **MUST** The game avoid presenting fictional communication mechanics as practical real-world evasion instruction.
- **SHOULD** Channel compromise produce explainable latency, loss, deception, or compartment effects.

### Mission phases

- Plan
- Access
- Collect
- Deliver
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Maintain cover
- Read attention cues
- Use compartmented channel
- Change route or meeting plan

### Inputs

- Cover profile
- Access rationale
- Communications plan

### Outputs

- Cover-integrity state
- Exposure indicators
- Operational communications record

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Operational communications](/docs/report/intelligence-operative-archetypes-and-tradecraft#intelligence-operative-archetypes-and-tradecraft) — High-level communication and compartmentation concepts.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## TRADE-01 — Cover Identity and Congruence

<a id="cover-identity-and-congruence"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Tradecraft
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/cover-identity-and-congruence
- **JSON:** https://iarpg.com/records/cover-identity-and-congruence.json

### Summary

Cover is a persistent system of identity, access, behavior, records, competence, relationships, and exposure—not a costume slot.

### Purpose

Translate cover, access, surveillance awareness, communications, and compartmentation into fictional game interactions.

### Rationale

Tradecraft becomes meaningful when player behavior, access rationale, and operational signatures affect mission state.

### Normative requirements

- **MUST** A cover define identity, occupation, purpose, access rationale, expected competence, records, relationships, and exposure indicators.
- **MUST** Suspicion respond to incongruence among behavior, environment, documentation, and known history rather than a hidden alignment score.
- **SHOULD** Cover consequences persist across operations and permit repair, reinforcement, compartmentation, or retirement.
- **MAY** Multiple covers coexist with separate access, relationships, and risk histories.

### Mission phases

- Plan
- Access
- Collect
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Maintain cover
- Read attention cues
- Use compartmented channel
- Change route or meeting plan

### Inputs

- Cover profile
- Access rationale
- Communications plan

### Outputs

- Cover-integrity state
- Exposure indicators
- Operational communications record

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Taxonomy of cover identities](/docs/report/cover-identities-and-tradecraft-in-espionage-executive-summary#taxonomy-of-cover-identities) — Cover types, verification, and risk.
- [Maintaining the legend](/docs/report/the-architecture-of-deception-constructing-and-maintaining-cover-backgrounds-in-modern-espionage#maintaining-the-legend-operational-tradecraft-and-communications) — Persistent identity maintenance and communications.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## TRADE-02 — Surveillance, Detection, and Counter-Surveillance

<a id="surveillance-detection-and-counter-surveillance"></a>

- **Status:** Guidance
- **Version:** 2.0.4-wip
- **Category:** Tradecraft
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/surveillance-detection-and-counter-surveillance
- **JSON:** https://iarpg.com/records/surveillance-detection-and-counter-surveillance.json

### Summary

Surveillance is represented as pattern recognition, route pressure, environmental observation, and exposure management within fictional game spaces.

### Purpose

Translate cover, access, surveillance awareness, communications, and compartmentation into fictional game interactions.

### Rationale

Tradecraft becomes meaningful when player behavior, access rationale, and operational signatures affect mission state.

### Normative requirements

- **MUST** Keep public documentation at fictional, abstract, game-system level and avoid practical real-world targeting instructions.
- **MUST** Represent surveillance through observable game patterns, uncertainty, and resource trade-offs.
- **SHOULD** Provide more than one response to suspected surveillance, including delay, route change, abort, decoy, or controlled exposure.
- **MAY** Use accessibility settings to surface patterns through visual, audio, or interface cues.

### Mission phases

- Plan
- Access
- Collect
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Maintain cover
- Read attention cues
- Use compartmented channel
- Change route or meeting plan

### Inputs

- Cover profile
- Access rationale
- Communications plan

### Outputs

- Cover-integrity state
- Exposure indicators
- Operational communications record

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Philosophy of urban counter-surveillance](/docs/report/operational-directive-analog-tradecraft-and-counter-surveillance-in-high-density-virtual-urban-environments#the-philosophy-of-urban-counter-surveillance) — Fictional urban surveillance mechanics and cognitive load.
- [Maintaining cover and counter-surveillance](/docs/report/cover-identities-and-tradecraft-in-espionage-executive-summary#maintaining-cover-and-counter-surveillance-tradecraft) — Cover maintenance and detection risk.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## TRADE-03 — Communications and Compartmentation

<a id="communications-and-compartmentation"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Tradecraft
- **Conformance:** Level B — Playable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/communications-and-compartmentation
- **JSON:** https://iarpg.com/records/communications-and-compartmentation.json

### Summary

Operational information moves through role-aware channels with explicit need-to-know boundaries, delivery state, and exposure cost.

### Purpose

Translate cover, access, surveillance awareness, communications, and compartmentation into fictional game interactions.

### Rationale

Tradecraft becomes meaningful when player behavior, access rationale, and operational signatures affect mission state.

### Normative requirements

- **MUST** Operational messages identify sender role, intended recipient, mission context, sensitivity, and delivery status.
- **MUST** Compartmented information remain inaccessible to roles without a declared need-to-know path.
- **SHOULD** Communication methods expose latency, reliability, interception, and attribution trade-offs.
- **MAY** Allow deliberate misinformation inside the game when it is bounded, discoverable, and separated from authoritative system truth.

### Mission phases

- Plan
- Collect
- Deliver
- Extract

### Applicable roles

- Operative
- Handler
- Intelligence Analyst

### Game interaction mapping

- Maintain cover
- Read attention cues
- Use compartmented channel
- Change route or meeting plan

### Inputs

- Cover profile
- Access rationale
- Communications plan

### Outputs

- Cover-integrity state
- Exposure indicators
- Operational communications record

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Clandestine communications and physical exchanges](/docs/report/typology-of-intelligence-operatives-and-tradecraft-frameworks-a-comprehensive-architecture-for-clandestine-beh#clandestine-communications-and-physical-exchanges) — Communication and exchange methods in the tradecraft taxonomy.
- [Pre-exchange protocol](/docs/report/operational-directive-analog-tradecraft-and-counter-surveillance-in-high-density-virtual-urban-environments#pre-exchange-protocol-the-analog-signal) — Fictional signaling and exchange preparation.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## TRADE-04 — Cover Degradation and Repair

<a id="cover-degradation"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Tradecraft
- **Conformance:** Level C — Auditable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/cover-degradation
- **JSON:** https://iarpg.com/records/cover-degradation.json

### Summary

Defines how repeated inconsistencies, exposure, competence gaps, and relationship damage degrade a cover and how it may be repaired.

### Purpose

Translate cover, access, surveillance awareness, communications, and compartmentation into fictional game interactions.

### Rationale

Tradecraft becomes meaningful when player behavior, access rationale, and operational signatures affect mission state.

### Normative requirements

- **MUST** Cover degradation arise from inspectable events rather than a hidden arbitrary meter.
- **MUST** The interface distinguish document mismatch, behavioral mismatch, competence mismatch, relationship damage, and direct exposure.
- **SHOULD** Repair require plausible time, resources, relationships, or changed access rather than an instant reset.

### Mission phases

- Plan
- Access
- Collect
- Extract
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Maintain cover
- Read attention cues
- Use compartmented channel
- Change route or meeting plan

### Inputs

- Cover profile
- Access rationale
- Communications plan

### Outputs

- Cover-integrity state
- Exposure indicators
- Operational communications record

### Evidence and provenance

- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.

### Failure behavior

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

### Recovery behavior

Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.

### Supporting research

- [Cover construction and maintenance](/docs/report/the-architecture-of-deception-constructing-and-maintaining-cover-backgrounds-in-modern-espionage#the-architecture-of-deception-constructing-and-maintaining-cover-backgrounds-in-modern-espionage) — Long-form cover background and congruence research.

### Revision history

- **1.0.0 · 2026-07-19** — Initial IARPG-OPS-1 publication.
- **2.0.1-wip · 2026-07-19** — Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
- **2.0.2-wip · 2026-07-19T16:42:07Z** — 
- **2.0.3-wip · 2026-07-19T18:45:50Z** — Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
- **2.0.4-wip · 2026-07-20T12:04:07Z** — Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

## DATA-02 — Project Canonical JSON Profile

<a id="project-canonical-json-profile"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Data and Portability
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/project-canonical-json-profile
- **JSON:** https://iarpg.com/records/project-canonical-json-profile.json

### Summary

Defines the IARPG-CJSON-1 bytes used for deterministic content equality, checksums, fixtures, and browser-local handoffs.

### Purpose

Defines the IARPG-CJSON-1 bytes used for deterministic content equality, checksums, fixtures, and browser-local handoffs.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Importers reject duplicate object keys, malformed UTF-8, unpaired Unicode surrogates, non-finite numbers, unsafe integers, and invalid _utc values before canonicalization.
- **MUST** Canonical serialization sort object keys by Unicode scalar value while preserving significant array order and unknown extensions.
- **MUST** Browser and build-time implementations produce identical bytes and SHA-256 values for every published passing vector.
- **SHOULD** Interfaces preserve both original and normalized representations whenever normalization changes bytes.

### Mission phases

- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial DATA-02 publication for IARPG-OPS-2 release-candidate hardening.

## PKG-04 — Portable Integrity Bundle

<a id="portable-integrity-bundle"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Packages and Integrity
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/portable-integrity-bundle
- **JSON:** https://iarpg.com/records/portable-integrity-bundle.json

### Summary

Defines a separate exportable integrity record that accompanies an Operation Package without changing the package.

### Purpose

Defines a separate exportable integrity record that accompanies an Operation Package without changing the package.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** An integrity bundle identify package, profile, algorithm, build, tool version, UTC generation time, result, failures, and evidence links.
- **MUST** A failed bundle and the original package remain exportable unchanged.
- **MUST** The interface state that digest equality does not prove identity, authorship, approval, authorization, or legal authenticity.
- **MAY** Unknown extension data be preserved inside the bundle extensions object.

### Mission phases

- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial PKG-04 publication for IARPG-OPS-2 release-candidate hardening.

## PROV-01 — Non-Authenticating Provenance Envelope

<a id="non-authenticating-provenance-envelope"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Evidence and Provenance
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/non-authenticating-provenance-envelope
- **JSON:** https://iarpg.com/records/non-authenticating-provenance-envelope.json

### Summary

Records file-based workflow ancestry and declared local role labels without claiming human identity or approval.

### Purpose

Records file-based workflow ancestry and declared local role labels without claiming human identity or approval.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Each envelope record artifact digest, parent artifacts, workflow action, tool build, UTC time, reason code, standards, and preserved extensions.
- **MUST** Declared role labels remain local workflow labels and never be presented as authenticated identity.
- **MUST** Publication views show the authenticity limitation beside the provenance chain.
- **SHOULD** A structured list accompany every visual provenance graph.

### Mission phases

- Plan
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial PROV-01 publication for IARPG-OPS-2 release-candidate hardening.

## CONF-04 — Round-Trip Preservation

<a id="round-trip-preservation"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Conformance
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/round-trip-preservation
- **JSON:** https://iarpg.com/records/round-trip-preservation.json

### Summary

Defines import, normalization, export, reimport, comparison, and preservation evidence for portable artifacts.

### Purpose

Defines import, normalization, export, reimport, comparison, and preservation evidence for portable artifacts.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Round-trip tests compare original, parsed, normalized, exported, and reimported representations separately.
- **MUST** Record IDs, UTC timestamps, significant array order, and unknown extensions survive a declared lossless round trip.
- **MUST** Invalid input remain exportable and never be silently rewritten as the original.
- **SHOULD** Results distinguish exact byte match, semantic equality, canonical equality, and field loss.

### Mission phases

- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial CONF-04 publication for IARPG-OPS-2 release-candidate hardening.

## DATA-03 — Browser-Local Tool Handoff

<a id="browser-local-tool-handoff"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Data and Portability
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/browser-local-tool-handoff
- **JSON:** https://iarpg.com/records/browser-local-tool-handoff.json

### Summary

Defines explicit, digest-bound handoffs among the mission, evidence, simulation, review, migration, and publication tools.

### Purpose

Defines explicit, digest-bound handoffs among the mission, evidence, simulation, review, migration, and publication tools.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Every handoff identify artifact type and version, source and destination tools, UTC time, record ID, digest, unknown-field policy, and recovery behavior.
- **MUST** An incompatible destination reject the handoff with a reason while leaving the source untouched.
- **MUST** Unknown fields follow the declared preserve, quarantine, or reject-with-source-untouched policy.
- **SHOULD** Handoff acceptance and rejection be written to the local review ledger.

### Mission phases

- Plan
- Collect
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial DATA-03 publication for IARPG-OPS-2 release-candidate hardening.

## REC-01 — Recovery and Quarantine

<a id="recovery-and-quarantine"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Recovery
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/recovery-and-quarantine
- **JSON:** https://iarpg.com/records/recovery-and-quarantine.json

### Summary

Defines non-destructive handling for malformed, unsupported, conflicting, partial, or checksum-failing local artifacts.

### Purpose

Defines non-destructive handling for malformed, unsupported, conflicting, partial, or checksum-failing local artifacts.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Malformed or incompatible artifacts enter quarantine with their original payload and a reason.
- **MUST** Recovery actions clone into a repaired draft rather than mutating the quarantined original.
- **MUST** Users can export the original payload and recovery report before deletion.
- **MUST** Recovery interfaces state that repair does not establish source trustworthiness.

### Mission phases

- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial REC-01 publication for IARPG-OPS-2 release-candidate hardening.

## GOV-05 — Append-Only Review Ledger

<a id="append-only-review-ledger"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/append-only-review-ledger
- **JSON:** https://iarpg.com/records/append-only-review-ledger.json

### Summary

Defines browser-local lifecycle evidence where corrections are new reversal or superseding entries rather than edits.

### Purpose

Defines browser-local lifecycle evidence where corrections are new reversal or superseding entries rather than edits.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Every ledger entry include unique ID, UTC time, artifact ID and digest, action, result, reason code, standard, parent IDs, and extensions.
- **MUST** Historical entries never be mutated in place.
- **MUST** Corrections use a new reversal or superseding entry linked to the earlier entry.
- **SHOULD** Ledger exports remain deterministic under IARPG-CJSON-1.

### Mission phases

- Plan
- Validate
- Deliver
- Debrief

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial GOV-05 publication for IARPG-OPS-2 release-candidate hardening.

## COMP-01 — Tested Compatibility Matrix

<a id="tested-compatibility-matrix"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/tested-compatibility-matrix
- **JSON:** https://iarpg.com/records/tested-compatibility-matrix.json

### Summary

Publishes explicit import, export, migration, round-trip, unknown-field, limitation, and fixture evidence by release and artifact type.

### Purpose

Publishes explicit import, export, migration, round-trip, unknown-field, limitation, and fixture evidence by release and artifact type.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Every compatibility claim identify the tested release, artifact type, support mode, unknown-field policy, limitations, standards, and fixture evidence.
- **MUST** Untested combinations be labeled not tested rather than inferred compatible.
- **SHOULD** The matrix distinguish direct support, migration-only support, partial round trip, and unsupported states.
- **MAY** A stable release add compatibility evidence without changing an earlier artifact.

### Mission phases

- Plan
- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial COMP-01 publication for IARPG-OPS-2 release-candidate hardening.

## HOST-01 — Target Hosting Smoke Evidence

<a id="target-hosting-smoke-evidence"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Governance
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/target-hosting-smoke-evidence
- **JSON:** https://iarpg.com/records/target-hosting-smoke-evidence.json

### Summary

Defines safe, removable evidence for PHP, rewrites, headers, protected paths, assets, JSON delivery, UTC, and writable local storage on the actual host.

### Purpose

Defines safe, removable evidence for PHP, rewrites, headers, protected paths, assets, JSON delivery, UTC, and writable local storage on the actual host.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** The diagnostic endpoint disclose no secrets, environment variables, absolute paths, session contents, or private configuration.
- **MUST** Stable promotion require evidence from the actual target hosting account.
- **MUST** The documentation instruct operators to remove or disable the endpoint after testing.
- **SHOULD** Each result include pass, fail, or not-tested with a non-sensitive explanation.

### Mission phases

- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial HOST-01 publication for IARPG-OPS-2 release-candidate hardening.

## A11Y-02 — Accessibility Evidence Publication

<a id="accessibility-evidence-publication"></a>

- **Status:** Current
- **Version:** 2.0.4-wip
- **Category:** Accessibility
- **Conformance:** Level D — Simulatable
- **Implementation maturity:** Published WIP
- **Canonical:** https://iarpg.com/standard/accessibility-evidence-publication
- **JSON:** https://iarpg.com/records/accessibility-evidence-publication.json

### Summary

Defines an evidence matrix for keyboard, focus, labels, live regions, tables, fallback views, zoom, motion, contrast, mobile, print, and touch.

### Purpose

Defines an evidence matrix for keyboard, focus, labels, live regions, tables, fallback views, zoom, motion, contrast, mobile, print, and touch.

### Rationale

Portable intelligence-operation artifacts require inspectable boundaries, deterministic evidence, explicit recovery, and no silent loss or identity overclaim.

### Normative requirements

- **MUST** Evidence records use pass, fail, or not-tested states with method, date, limitations, and evidence links.
- **MUST** The publication avoid claiming WCAG certification from project-local checks.
- **MUST** Every graph or timeline expose an equivalent structured representation.
- **SHOULD** Release-blocking accessibility failures be visible in the promotion dashboard.

### Mission phases

- Plan
- Validate
- Deliver

### Applicable roles

- Operative
- Handler
- Intelligence Analyst
- Technical Operator
- Counterintelligence Officer
- Liaison Officer
- Logistics Specialist
- Source Handler

### Game interaction mapping

- Inspect artifact
- Compare evidence
- Record reason code
- Export local result

### Inputs

- Browser-local artifact
- Applicable standard
- Declared source context

### Outputs

- Reviewable result
- Reason code
- Local export
- Preserved original

### Evidence and provenance

- Record source artifact ID, canonical digest, UTC event time, responsible local role label, and reason code.
- Do not convert a digest, label, or generated statement into an identity or authoritative fact claim.

### Failure behavior

Fail closed for irreversible publication or overwrite. Preserve original content, show the failing requirement, and allow export or non-destructive recovery.

### Recovery behavior

Retain the original artifact and review event, clone any repaired draft, and require a new explicit validation event before continuing.

### Supporting research

- [Immutable records and UTC telemetry](/docs/report/monetary-architecture-genesis-allowance-and-economic-stabilization#ledger-schema-and-telemetry) — Supports immutable records, reversals, and UTC event time.
- [Evidence-based review and jurisdiction](/docs/report/justice-system-and-warrant-escalation-for-rogue-intelligence#recommended-warrant-architecture) — Supports explainable evidence thresholds and reviewable decisions.

### Revision history

- **2.0.4-wip · 2026-07-20T12:04:07Z** — Initial A11Y-02 publication for IARPG-OPS-2 release-candidate hardening.