Purpose
What this record standardizes.
Define operational roles, information entitlements, decision authority, escalation, and handoff requirements.
Information asymmetry is only fair when the interface explains who knew what, when, and why.
Normative requirements
What conforming implementations must, should, and may do.
The system record what each role could know at every consequential decision point.
Withheld information follow a declared compartment, access, timing, or source-protection rule.
Debrief reveal role asymmetry when doing so does not violate ongoing source protection.
Game interaction mapping
What players and interfaces do.
Data contract
Inputs and outputs.
Inputs
- Role profile
- Information packet
- Mission state
Outputs
- Handoff record
- Decision record
- Role-specific event
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.information-asymmetry-disclosure.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 ROLE-02 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.
