Purpose
What this record standardizes.
Keep observations, reports, interpretations, hypotheses, assessments, and decisions distinct and traceable.
A reviewable intelligence game requires uncertainty and contradiction to survive the user interface rather than being flattened into a single truth score.
Normative requirements
What conforming implementations must, should, and may do.
Classify every dossier item as observation, source report, interpretation, hypothesis, assessment, or decision.
Preserve author, time, context, source, and revision lineage for each item.
Allow players to challenge, annotate, supersede, or retain competing interpretations without deleting the original record.
Display disagreements between roles as parallel analytic notes.
Game interaction mapping
What players and interfaces do.
Data contract
Inputs and outputs.
Inputs
- Observations
- Source reports
- Documents
- Sensor events
Outputs
- Hypotheses
- Assessment
- Decision support
- Evidence packet
State contract
Allowed or expected transitions.
| From | Event | To |
|---|---|---|
| not-applicable | record requirement evaluated | conforming-or-documented-exception |
Evidence and provenance
Review requirements for claims and consequential state.
- 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.
User-interface requirements
How the requirement must appear at the point of use.
- Show the record code and requirement level at the point of use.
- Expose the reason for blocked, failed, escalated, or irreversible actions.
- Provide a direct link to the canonical standard and machine-readable record.
Accessibility requirements
Equivalent access to essential information and controls.
- Essential information is available without reliance on color, audio, motion, or a VR-only gesture.
- Keyboard, screen-reader, reduced-motion, seated-play, and high-contrast equivalents are documented where the interaction applies.
Telemetry events
Minimum event records for implementation review.
standard.observation-report-interpretation-and-hypothesis.evaluated
Required fields:
Abuse and exploit cases
What the implementation must anticipate.
- A participant attempts to omit required context so another role accepts a misleading task.
- A generated or user-authored statement is presented as server-authoritative without verification.
- A consequential state transition occurs without a durable reason code.
Failure and recovery
Fail-closed behavior and recovery path.
Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.
Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.
Example implementation
A concise fictional game implementation.
A mission interface evaluates EVID-01 before advancing the relevant state and writes the result to the local event log with a UTC timestamp and reason code.
Open complete mission examples →Related records and examples
Continue through the operating model.
Supporting research
Deep links into complete canonical reports.
Revision history
Published changes to this record.
Initial IARPG-OPS-1 publication.
Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.