Purpose
What this record standardizes.
Define the authority, customer, jurisdiction, mandate, and neutrality rules that make an operation intelligible without assigning permanent moral alignment.
A mission cannot be reviewed when its sponsor, customer, limits, and desired effect remain implicit.
Normative requirements
What conforming implementations must, should, and may do.
Every operation identify the sponsoring authority, customer, mandate, and jurisdiction before player acceptance.
No authority receive a permanent good, evil, hero, or villain flag in canonical game logic.
Conflicting authorities expose different objectives, constraints, and definitions of success without hiding their operational interests.
Authorities cooperate temporarily when requirements overlap, even when their long-term interests conflict.
Game interaction mapping
What players and interfaces do.
Data contract
Inputs and outputs.
Inputs
- Authority profile
- Customer requirement
- Jurisdiction profile
Outputs
- Tasking context
- Mandate boundary
- Authority-specific success definition
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.operational-neutrality-and-authority.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 FOUND-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.
