IARPG-OPS-2 · 2.0.11-wip Game concept + open mission-design system Six examples · local tools · standards · research · no live MMO claim
IARPG.COM INTELLIGENCE AGENT ROLE PLAYING GAME
Work in progress IARPG-OPS-2 2.0.11-wip
Updated Source hierarchy Corrections International fairness Evidence archive

Global publication search

Search the operations design system

Type to search standards, missions, roles, authorities, reports, sources, pages, schemas, and UAI memory.

AUTH-01GuidanceFoundationPublished WIP

Authority Profile Schema

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

Direct answer

What does AUTH-01 standardize?

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

Category
Foundation
Requirement level
Level C — Auditable
Implementation
Published WIP
Machine record
/records/authority-profile-schema.json

Purpose

What this record standardizes.

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

What conforming implementations must, should, and may do.

01
MUSTrequired for conformance

Profiles validate stable identifiers, names, organizational type, customer, mandate, jurisdiction, motivations, priorities, constraints, blind spots, resources, style, and mission types.

02
MUSTrequired for conformance

The schema omit universal moral alignment.

03
MAYoptional supported behavior

Implementations extend profiles with local visual or narrative fields.

Game interaction mapping

What players and interfaces do.

01Review authority dossier
02Compare mandate constraints
03Accept or decline tasking
04Record conflict of interest
TaskPlan

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.

Allowed state transitions for this standard
FromEventTo
not-applicablerecord requirement evaluatedconforming-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.authority-profile-schema.evaluated

Required fields:

event_idtimestamp_utcmission_idrecord_coderesultreason_code

Abuse and exploit cases

What the implementation must anticipate.

  1. A participant attempts to omit required context so another role accepts a misleading task.
  2. A generated or user-authored statement is presented as server-authoritative without verification.
  3. A consequential state transition occurs without a durable reason code.

Failure and recovery

Fail-closed behavior and recovery path.

FAILURE

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

RECOVERY

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 AUTH-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

Supporting research

Deep links into complete canonical reports.

Revision history

Published changes to this record.

1.0.02026-07-19 UTC

Initial IARPG-OPS-1 publication.

2.0.1-wip2026-07-19 UTC

Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.

2.0.2-wip2026-07-19T16:42:07Z UTC

2.0.3-wip2026-07-19T18:45:50Z UTC

Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.

2.0.4-wip2026-07-20T12:04:07Z UTC

Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

Connected tools and standards

Explore the wider AI ecosystem.