IARPG-OPS-1 online Intelligence operations standard Fictional missions · neutral authorities

Governance and release discipline

Canonical records first.
Claims follow evidence.

IARPG-OPS-1 is maintained as a public, versioned game-design standard. Changes must preserve stable record codes, machine routes, deep research references, explicit status, and a dated release trail.

Publication authority

The public record is the source of truth.

Canonical HTML records, companion JSON documents, the mission schema, examples, validator behavior, roadmap, and changelog form one reviewable publication surface. Marketing copy cannot silently widen the standard.

  • Record codes and slugs remain stable after publication.
  • Normative changes require a version or dated changelog entry.
  • Current, guidance, experimental, deprecated, and withdrawn statuses are explicit.
  • Machine JSON and human pages must describe the same requirement.
  • Deep report links preserve the complete reasoning and source lineage.
  • Support boundaries are published alongside implementation claims.

Record status model

Every support claim has a visible state.

Status is not decoration. It tells designers, implementers, reviewers, and players how strongly a record may be relied upon in the current release.

Current

Normative baseline

Part of the current release and expected in conforming designs unless the record itself identifies a narrower scope.

Guidance

Recommended operating practice

Published and supported as guidance, but not required for every conformance claim.

Experimental

Under active evaluation

Available for trials and telemetry, but not yet stable enough for broad support claims.

Deprecated

Supported transition only

Retained for compatibility or migration while a replacement record is identified.

Withdrawn

No longer supported

Preserved for historical traceability but excluded from current conformance.

Change-control path

A standard changes through reviewable stages.

The process favors small, attributable changes over unannounced rewrites. Telemetry and playtest evidence can inform a proposal, but a proposal is not current support until the public record changes.

  1. 01

    Identify the operational problem.

    Name the mission failure, ambiguity, exploit, player-friction point, or review gap. Link the affected record, implementation evidence, and supporting report sections.

  2. 02

    Draft the smallest viable change.

    State whether the proposal changes a requirement, schema field, example, validator check, status, or explanatory note.

  3. 03

    Review neutrality and boundaries.

    Confirm that the change remains centered on fictional intelligence operations, preserves authority neutrality, and does not create real-world operational instruction.

  4. 04

    Test human and machine surfaces.

    Update the catalog, record page, JSON companion, schema or example when applicable, validator behavior, UAI memory, route checks, and deep-link validation.

  5. 05

    Publish status and release evidence.

    Add a dated changelog entry, update version metadata, preserve old records when needed, and keep current versus future support explicit.

Current non-claims

A clear boundary
is part of trust.

IARPG-OPS-1 does not claim formal certification, legal approval, factual truth, real-world operational validity, security assurance, accessibility conformance, production readiness, or endorsement of any authority or political objective.

The local validator checks structural mission fields only. The game remains a fictional design environment, and the public research archive preserves exploratory material that may not represent current product decisions.

Connected tools and standards

Explore the wider AI ecosystem.