Skip to content

Orix Certification Standard

Orix Certification Standard

Status: GOVERNING Version: 2.0 (Consolidated from LCS-A v1) Authority: CI Enforcement

Mandatory compliance requirements for all Orix code, enforced automatically by CI and analyzers.


Quick Reference

SectionPurposeKey Rule
DETDeterminismSame inputs = same outputs always
MEMMemoryNo allocation in hot paths
NETNetworkingBounded, versioned, validated
DODData-OrientedCache-friendly, SoA layouts
VERVerificationClaims must have proof
AGENTAI AgentsMechanical compliance, no guessing
TRACETraceabilityClaims linked to evidence

DET: Determinism

Core Requirement

Given identical inputs and state, produce identical outputs across all executions, machines, and time.

Determinism Scope

Applies to all code affecting observable state:

  • Simulation logic
  • Prediction/rollback
  • Serialization/deserialization
  • Snapshot generation
  • Network reconciliation
  • Test execution

Forbidden Sources

SourceReplacement
float, doubleDFixed64
DateTime.NowTick
System.RandomOrixRandom(seed)
Guid.NewGuid()Entity allocation
Dictionary<K,V>UnsafeMap<K,V>
HashSet<T>UnsafeSet<T>
Thread schedulingSingle-threaded

Violation Levels

  • DET-ERROR: Local risk, contained
  • DET-BLOCKING: Uncertain, must resolve
  • DET-CRITICAL: Proven non-deterministic

MEM: Memory & Allocation

Core Requirement

Memory behavior must be explicit, intentional, and auditable.

Hot Path Definition

Any execution path that:

  • Runs at fixed frequency (tick-based)
  • Scales with entity/connection count
  • Executes during prediction, rollback, serialization
  • Contributes to frame/tick budget

Hot Path Rules

Absolutely forbidden:

  • Heap allocation
  • Boxing
  • Iterator allocation
  • Garbage-producing abstractions
  • Lazy initialization

Allowed Allocation

Only in cold paths, must be:

  • Explicit
  • Intentional
  • Bounded
  • Traceable

Collections in Hot Paths

ForbiddenRequired
List<T>UnsafeList<T>
Dictionary<K,V>UnsafeMap<K,V>
HashSet<T>UnsafeSet<T>
Queue<T>UnsafeQueue<T>

NET: Networking

Core Requirements

  1. All messages bounded in size
  2. All formats versioned
  3. All inputs validated
  4. All costs bounded per-peer

Message Rules

  • Maximum message size defined
  • Serialization fully deterministic
  • No unbounded arrays from peers
  • Rate limiting enforced

Trust Boundaries

  • Peer input is untrusted
  • Validate sizes/offsets before use
  • No peer-controlled loops
  • Explicit authority model

DOD: Data-Oriented Design

Core Requirement

Data layout optimizes for cache efficiency and deterministic processing.

Required Patterns

  • Structure of Arrays (SoA) for hot data
  • Contiguous memory layouts
  • Predictable access patterns
  • Entity-Component architecture

Forbidden Patterns

  • Deep object hierarchies
  • Pointer chasing in hot paths
  • Scattered allocations
  • Virtual dispatch in tight loops

VER: Verification

Core Requirement

Claims are false until proven with reproducible evidence.

Proof Obligations

Every claim about:

  • Determinism
  • Allocation-freedom
  • Safety
  • Correctness
  • Performance bounds

Must have verifiable evidence.

Test Requirements

  • Tests are executable contracts
  • Flaky tests = determinism failure
  • All tests repeatable
  • Evidence is permanent artifact

AGENT: AI Agent Compliance

Core Requirement

Agents are actors bound by the same rules as humans.

Agent Obligations (MUST)

  1. Comply with all certification sections
  2. Treat documentation as authoritative
  3. Treat ambiguity as stop condition
  4. Produce trace artifacts for actions
  5. Refuse to proceed in illegal states

Agent Prohibitions (MUST NOT)

  1. Guess missing requirements
  2. Infer undocumented intent
  3. Proceed “reasonably” under uncertainty
  4. Resolve conflicts by synthesis
  5. Rely on chat history as source of truth
  6. Hide uncertainty behind confident language

Ambiguity Protocol

  1. Surface the ambiguity explicitly
  2. Halt work until resolved
  3. Request clarification or DEC
  4. Never assume or guess

TRACE: Traceability

Core Requirement

Every claim must be linked to evidence.

Traceability Requirements

  • Claims reference evidence
  • Decisions reference rationale
  • Code references specifications
  • Tests reference requirements

Trace Artifacts

All significant actions produce:

  • What was done
  • Why it was done
  • What evidence supports it
  • What decisions were made

Violation Classification

LevelDescriptionAction
ERRORLocal risk, fixableMust fix before merge
BLOCKINGUncertainty, unverifiedMust resolve, halt progress
CRITICALProven violationHalt all work, escalate

Severity Escalation

  • Multiple ERRORs in same area → BLOCKING
  • Unresolved BLOCKING → CRITICAL
  • Any CRITICAL → Halt deployment

Compliance Statement

All Orix code MUST comply with this standard. No exceptions. No waivers without DEC.

Partial compliance is non-compliance.


See Also


Consolidated from LCS-A v1 (14 sections) - see docs/archive/standards-v1/LCS-A-INDEX.md for original