The Node Contract

3.0 Preamble

Justification

Without a formal contract, “Synixolis-conforming” is a meaningless claim. Any implementation can declare conformance while omitting provenance, ignoring renewal, or treating all memory as a flat namespace. The node contract is the protocol boundary — it defines the minimum set of state structures, operations, lifecycle rules, and telemetry obligations that an implementation MUST satisfy to participate in the Synixolis protocol. Everything outside this contract is policy (Section 5). Everything inside it is non-negotiable.

This is an interface specification, the same concept as a gRPC service definition, a consensus participant contract in Raft/PBFT, or an ERC token standard. It does not prescribe implementation internals. It specifies the observable behavior and structural invariants that other nodes, colony coordination, and the eval subsystem depend on.

Operating Timescale

The contract itself is static — it changes only through the protocol evolution process (Section 7). But the operations it defines span multiple timescales:

Timescale	Operations
Per-operation (ms)	Invariant checks, schema validation, provenance chain validation, conflict detection, content index update
Per-interaction (seconds)	Write path (ingest through link), read path (query through outcome), action cascade routing, execution trace capture
Per-session (minutes to hours)	Session-boundary maintenance (decay pass on ephemeral, heartbeat, trace flush), outcome signal generation, sandbox replay
Periodic (hours to days)	Operational decay pass, impact score update, condensation check, eval trace analysis, task-type register aggregation
Lifecycle (days to weeks)	Structural renewal audit, convention review, compiled rule lifecycle, ground truth quality audit
Evolution (weeks to permanent)	Protocol evolution path (trace, analyze, propose, evaluate, compile, demote)

Distributed Systems Framing

Contract Element	DS Analogue
State partitions	Tiered storage with partition-specific write policies (HSM)
Memory entry format	Schema definition / wire format (Protobuf, Avro)
Write path	Write-ahead pipeline with validation middleware
Read path	Cache hierarchy with page-fault cascade + content-addressable index (L1/L2/L3/disk + full-text search)
Maintenance path	Garbage collection + cache expiry + compaction + hit-rate quality metrics
Evolution path	Online schema migration + configuration hot-reload
Simulation path	Staging environment / shadow traffic / transaction with ROLLBACK
Action cascade	Routing policy with cost-based dispatch
Lifecycle gates	Admission control / circuit breaker thresholds
Telemetry conformance	Structured logging contract (OpenTelemetry span requirements + full payload capture)
Ground truth protocol	Oracle model / label acquisition strategy in active learning

---

3.1 State Partitions

A conforming node MUST maintain state in metabolic regions — partitions with timescale-matched lifecycle physics. This requirement derives from CDR Theorem 2 (Temporal Partitioning): multi-timescale sources require timescale-matched partitions; a single update rate creates aliasing that strictly degrades retention.

Required Regions

The protocol requires a minimum of three regions (fast, slow, permanent). The reference configuration defines five:

regions:
  ephemeral:
    timescale: minutes to hours
    lifecycle: hard-expire at TTL
    purpose: session scratch, transient computation state, working context
    deletion: true  # the ONLY region where true deletion is permitted
    decay: none — entries expire by TTL, not by confidence decay

  operational:
    timescale: days to weeks
    lifecycle: active decay with renewal
    purpose: sprint goals, blockers, action items, raw observations
    decay: continuous confidence decay at region-specific rate
    archival_threshold: confidence drops below configured minimum

  structural:
    timescale: months to quarters
    lifecycle: periodic review cycle
    purpose: architecture decisions, entity knowledge, durable patterns, consolidated themes
    decay: slow confidence decay, review-gated renewal
    archival_threshold: confidence below threshold AND no renewal within review period

  identity:
    timescale: permanent until explicitly changed
    lifecycle: human-gated modification only
    purpose: mission, values, core preferences, non-negotiable constraints
    decay: none — entries persist until explicitly superseded
    modification: requires human approval (modification gate — see Section 5)

  glacier:
    timescale: indefinite
    lifecycle: archived, indexed, retrievable on demand
    purpose: cold storage for entries that fell below active thresholds
    deletion: never — glacier entries are retained permanently
    retrieval: available via page-fault cascade on query miss

Mapping to AAP Context Layers

The regions map to the AAP v0.4.3 context model as follows:

Synixolis Region	AAP Layer	AAP Concept
ephemeral	Layer 0 (execution frame) + transient turn state	Stack frames, push/pop isolation
operational	Layer 1 (session state)	Working heap, budgeted context
structural	Layer 2 (experience / consolidated episodes)	Compression state, consolidated episodes
identity	Layer 3 (stable beliefs, preferences)	Identity fields, policy-gated mutation
glacier	(no AAP equivalent)	Synixolis extension — cold archive with index

Structural Invariants

1. Every memory entry MUST reside in exactly one region at any given time.
2. Region assignment MUST be based on the information’s natural timescale, NOT access frequency. An architectural decision accessed daily is still structural — it persists for months. A meeting action item accessed once is still operational — it expires in days.
3. Movement between regions MUST follow the defined lifecycle operations (condense, archive, expire). Direct region reassignment without lifecycle processing is a protocol violation.
4. The glacier region MUST support indexed retrieval. Archival without an index is equivalent to deletion, which violates CDR Theorem 1 (information loss is irreversible).

---

3.2 Memory Entry Format

Every memory entry MUST conform to the following schema. This is the wire format — the minimum set of fields required for the protocol’s lifecycle, provenance, and eval subsystems to function.

entry:
  # === Identity ===
  id: string                    # REQUIRED. Unique identifier. Format: ENTRY-{UUID-SHORT}
  region: enum                  # REQUIRED. One of: ephemeral, operational, structural, identity, glacier

  # === Temporal ===
  created: ISO-8601             # REQUIRED. Timestamp of initial creation
  last_renewed: ISO-8601        # REQUIRED. Timestamp of most recent renewal event
  renewal_count: integer        # REQUIRED. Number of times this entry has been renewed. Initial value: 0
  ttl: duration | null          # REQUIRED for ephemeral entries. Hard expiry duration. Null for non-ephemeral.

  # === Confidence ===
  confidence: float             # REQUIRED. Range [0.0, 1.0]. Region-specific initial value (policy).
  decay_rate: float             # REQUIRED. Region-specific default, overridable per-entry.
                                # Expressed as confidence loss per unit time (policy defines unit).

  # === Content ===
  content: string               # REQUIRED. The information itself.

  # === Provenance ===
  source: string                # REQUIRED. Provenance reference to the originating input.
                                # One of: user input reference, tool output reference,
                                # or entry ID (for entries derived from other entries).
  provenance: list[string]      # REQUIRED. Ordered chain of citations back to original source.
                                # Each element is a source reference. Chain MUST terminate at
                                # a verifiable external source (user input or tool output).
                                # Circular references are a protocol violation.

  # === Impact ===
  impact_score: float           # REQUIRED. Range [0.0, 1.0]. Initial value: 0.0.
                                # Computed from outcome signals (Section 3.3.2 Stage 4).
                                # Aggregates the outcome quality of all tasks this entry
                                # contributed to. Updated by the maintenance path (Section 3.3.3).
                                # DS analogue: page rank — measuring entry value by the quality
                                # of outcomes it participates in, not just access frequency.

  # === Connectivity ===
  links: list[string]           # REQUIRED (may be empty). References to related entries.
                                # Format: entry IDs or wiki-style link targets.

Schema Invariants

1. The provenance chain MUST be acyclic. Any entry whose provenance chain contains a cycle MUST be rejected at write time.
2. The provenance chain MUST terminate at a verifiable source. An entry whose provenance chain terminates at another entry that itself lacks provenance is invalid (dangling reference).
3. The confidence field MUST be within [0.0, 1.0]. Values outside this range MUST be clamped at the boundary.
4. The id field MUST be unique within the node’s entire memory (across all regions, including glacier).
5. The region field MUST match the region directory in which the entry is stored. Mismatches are a schema violation.
6. The impact_score field MUST be within [0.0, 1.0]. Initial value MUST be 0.0. Values outside this range MUST be clamped at the boundary.

Extension Fields

Implementations MAY add fields beyond the required set. Extension fields MUST NOT conflict with required field names. Extension fields MUST be prefixed with x_ to prevent future collisions with protocol-defined fields.

---

3.3 Required Operations

A conforming node MUST implement five operation paths. Each path is a pipeline — a sequence of stages that MUST execute in order. Individual stages within a path MAY be implemented via LLM inference, compiled rules, or native code (see Section 4: Inference Optimization Path), but the stage ordering and the observable outputs are protocol requirements.

3.3.1 Write Path (System A — Observation)

The write path transforms raw input into stored memory entries. It corresponds to System A (observation/learning) in the DLM framework.

ingest → classify → contradict → write → link

Stage 1: Ingest. Raw input is received and decomposed into discrete factual claims or observations. Each extracted item becomes a candidate memory entry.

• Input: unstructured text (conversation turn, tool output, document excerpt)
• Output: one or more candidate entries with content and source populated
• The ingestion method is policy (triad decomposition, entity extraction, or pass-through are all valid — see Section 5)

Stage 2: Classify. Each candidate entry is assigned to a metabolic region based on the information’s natural timescale.

• Classification MUST be based on information timescale, not access pattern or source type
• Classification heuristics are policy. The classification itself is protocol — every entry MUST be assigned a region before write.
• Output: region field populated on each candidate entry

Stage 3: Contradict. Each candidate entry is checked against existing entries in the target region for semantic contradiction.

• If a contradiction is detected with a higher-confidence existing entry: the candidate MUST still be written, but the conflict MUST be logged as a telemetry event (event class: memory, subtype: contradiction_detected)
• If a contradiction is detected with a lower-confidence existing entry: the existing entry’s confidence MUST be reduced (amount is policy)
• Contradiction detection method is policy (LLM inference, embedding similarity, rule-based). The requirement to check is protocol.
• Output: contradiction log entries (if any), confidence adjustments to existing entries (if any)

Stage 4: Write. The candidate entry is committed to the target region with all required fields populated.

• The entry MUST pass schema validation (Section 3.2) before commit
• The entry MUST pass provenance chain validation (acyclic, terminates at verifiable source)
• Failed validation MUST be logged as a telemetry event (event class: fault, subtype: schema_violation) and the entry MUST be rejected
• Output: entry committed to region, or rejection with logged reason

Stage 5: Link. Cross-references between the new entry and existing entries are established.

• Linking strategy is policy (semantic similarity, explicit mentions, topic clustering)
• The links field on the new entry MUST be populated (empty list is valid if no links are found)
• If the new entry links to existing entries, those entries’ links fields SHOULD be updated symmetrically
• Output: links field populated, related entries updated

3.3.2 Read Path (System B — Action and Feedback)

The read path retrieves memory entries in response to queries. It corresponds to System B (action/inference) in the DLM framework. The critical protocol requirement is reads-as-writes: every query generates telemetry that feeds the eval and maintenance subsystems.

query → retrieve → log → outcome

Stage 1: Query. A retrieval request is received and parsed into a search specification.

• Input: natural language query or structured search criteria
• The query MUST be recorded in the eval trace log before retrieval begins (the query itself is data)
• Output: search specification (terms, filters, scope)

Stage 2: Retrieve. The search specification is executed against the node’s memory. Two retrieval modes are available: the page-fault cascade for directed lookup, and the content-addressable index for discovery/similarity queries.

2a. Page-Fault Cascade

The page-fault cascade is the primary retrieval mechanism for directed queries — the caller knows what they are looking for and the cascade determines where it lives.

ephemeral → operational → structural → identity → glacier

• The cascade MUST proceed in region order (fastest timescale first)
• A match at any level satisfies the query — the cascade SHOULD stop at the first sufficient result unless the query explicitly requests exhaustive search
• A miss at all active levels (ephemeral through identity) MUST trigger a glacier lookup before returning empty
• This is the same mechanism as a CPU cache hierarchy: check L1, then L2, then L3, then main memory. Each level has higher latency and broader scope.
• Output: matched entries (possibly from multiple regions), or empty result

2b. Content-Addressable Index

The content-addressable index is a secondary retrieval mechanism for discovery queries — queries of the form “find all entries related to X” or “what memories are semantically close to this observation?” These queries are prerequisites for cross-region condensation, cross-region contradiction detection, replay trace selection, and gap detection.

The page-fault cascade is a cache hierarchy optimized for lookup. The content-addressable index is a search index optimized for discovery. Both are required.

• DS analogue: full-text search index (Lucene/Elasticsearch) alongside a primary key store. Also: content-addressable storage (CAS) — retrieval by content similarity rather than by location.
• Timescale: index updates are per-write (the index MUST be updated when an entry is written, moved, or archived). Index queries are per-interaction (sub-second).

content_index:
  scope: all regions (ephemeral, operational, structural, identity, glacier)
  update_trigger: every write, archive, or condense operation
  query_interface:
    input: content string or entry reference
    output: ranked list of (entry_id, region, similarity_score)
    parameters:
      max_results: integer (policy, default 20)
      similarity_threshold: float (policy, default 0.5)
      region_filter: list[string] | null (optional scope restriction)
  index_format: policy (embedding vectors, TF-IDF, LSH, hybrid)
  invariant: the index MUST be consistent with the memory store.
             An entry that exists in memory MUST be findable via the index.
             An entry that has been archived to glacier MUST remain in the index.

• The index format and similarity metric are policy. The existence of the index and its cross-region scope are protocol.
• A conforming node MUST maintain the index. An implementation that provides only the page-fault cascade without a content-addressable index cannot support cross-region discovery and is non-conforming.

Stage 3: Log (Reads-as-Writes). The query outcome is recorded as a telemetry event with the following fields:

query_log_entry:
  query: string                    # the original query
  result: HIT | MISS | PARTIAL    # outcome classification
  regions_searched: list[string]   # which regions were consulted
  entries_accessed: list[string]   # entry IDs that were retrieved
  entries_useful: list[string]     # entry IDs the consuming operation actually used
  entries_missing: string | null   # description of information the query needed but did not find
  timestamp: ISO-8601

• The distinction between entries_accessed and entries_useful is critical: it is the signal the maintenance and evolution paths use to identify entries that are retrieved but never useful (candidates for archival) and query patterns that consistently miss (candidates for new memory acquisition)
• MISS results with entries_missing descriptions are the primary input for gap detection in the evolution path

Stage 4: Outcome. Task completion feeds back to the retrievals that supported it.

• When a downstream task completes (user confirms success/failure, tool output is verified, code compiles/fails, etc.), the node MUST emit an outcome signal linking the task result back to the retrievals and entries that contributed to it.
• The outcome signal is written asynchronously — it is NOT part of the synchronous read pipeline. It is generated when the consuming operation completes, which may be seconds to hours after the retrieval.
• The outcome signal is the primary input for the entry impact score (Section 3.2) and the task-type performance register (Section 3.6).
• Without this stage, the system can only learn which entries are accessed, not which entries are valuable. Accessed-but-useless entries cannot be distinguished from accessed-and-critical entries.
• DS analogue: distributed tracing span completion (OpenTelemetry) — the downstream operation reports back to the trace that initiated it. Also: reinforcement signal in online learning systems.

outcome_signal:
  trace_id: string              # Links to the eval trace that initiated the operation
  query_log_refs: list[string]  # References to reads-as-writes entries that fed this task
  entries_contributed: list[string]  # Entry IDs that influenced the outcome
  task_type: string             # Classification of the task (research, operational, routing, etc.)
  outcome_quality: float        # [0.0, 1.0] — quality of the task outcome
  outcome_source: self | human | downstream_system  # Who assessed the quality
  assessment_lag: duration      # Time between retrieval and outcome assessment
  timestamp: ISO-8601

• The outcome_source field MUST be recorded to enable ground truth weighting (Section 3.7). Self-assessed outcomes carry lower weight than human-confirmed or tool-verified outcomes.
• A corresponding outcome subtype MUST be added to the eval telemetry event class (Section 3.6).
• Timescale: per-interaction to per-session. Outcome signals are generated when a task completes (seconds to hours after the retrievals that supported it).

3.3.3 Maintenance Path (CDR Lifecycle)

The maintenance path implements CDR Theorems 1 and 3 at the memory scale. It is the operational realization of the theoretical requirement that compression schemes degrade and must be renewed.

decay → impact → renew → condense → archive → expire

Stage 1: Decay. Confidence scores are reduced according to region-specific decay rates.

• Decay MUST be applied to all entries in regions with active decay (operational, structural)
• The decay function, rate, and schedule are policy (Section 5). The requirement that decay occurs is protocol.
• Decay MUST NOT be applied to identity entries (identity is human-gated) or glacier entries (archived entries are inert)
• ephemeral entries do not decay — they hard-expire at TTL
• Output: updated confidence values across affected entries

Stage 1b: Impact Score Update. Entry impact scores are recomputed from accumulated outcome signals.

• For each entry referenced in outcome signals since the last maintenance pass, recompute impact_score by aggregating the outcome_quality values from all outcome signals that reference the entry, weighted by the ground truth hierarchy (Section 3.7) based on each signal’s outcome_source.
• The aggregation method is policy (exponential moving average, trailing window mean, etc.). The requirement that impact scores are updated from outcome signals is protocol.
• Impact score feeds the renewal decision (Stage 2): entries with high impact scores receive a renewal bonus; entries with consistently low impact scores despite frequent access are candidates for reclassification or archival.
• Entries with zero outcome signals retain impact_score: 0.0 — absence of evidence is not negative evidence, but it does mean the entry has no demonstrated value.
• DS analogue: cache hit-rate quality metrics — measuring not just whether a cache line was accessed, but whether the access produced a useful result.
• Timescale: computed periodically (hours to days), updated whenever a new outcome signal references the entry.
• Output: updated impact_score values on affected entries

Stage 2: Renew. Entries that receive positive evidence have their confidence restored.

• Renewal triggers MUST include: re-encounter (the same information appears again in input), query hit (the entry was retrieved AND marked useful in a read log), explicit confirmation (human or protocol-level affirmation)
• On renewal: confidence MUST be increased (amount is policy), last_renewed MUST be updated to current timestamp, renewal_count MUST be incremented
• Output: updated confidence, timestamp, and count on renewed entries

Stage 3: Condense. Clusters of lower-tier entries are compressed into higher-tier entries.

• This is CDR Theorem 1 (Compress) applied within the memory hierarchy: multiple observations become a pattern, multiple patterns become a principle
• Condensation direction: operational observations → structural patterns. structural patterns → identity principles (rare, human-gated).
• The condensation trigger (how many observations, over what time window, at what confidence) is policy. The requirement that condensation occurs is protocol.
• The condensed entry MUST carry provenance referencing all source entries
• Source entries SHOULD be archived to glacier after condensation (they are not deleted — the provenance chain depends on them)
• Output: new higher-tier entry, source entries marked for archival

Stage 4: Archive. Entries whose confidence has fallen below the region’s archival threshold are moved to glacier.

• Archived entries MUST retain all fields, including provenance and links
• Archived entries MUST be indexed for retrieval (available to the page-fault cascade)
• Archival MUST be logged as a telemetry event (event class: lifecycle, subtype: archive)
• Output: entry moved to glacier, index updated

Stage 5: Expire. Ephemeral entries past their TTL are deleted.

• This is the ONLY true deletion in the system. All other lifecycle transitions preserve the entry in glacier.
• Expired entries MAY be logged before deletion (event class: lifecycle, subtype: expire) but the entry content is not preserved
• Rationale: ephemeral entries are session scratch — they have no long-term provenance value. Preserving them would violate the metabolic contract of the ephemeral region (hard-expire at TTL).
• Output: entry removed from ephemeral region

3.3.4 Evolution Path (CDR Applied to Protocol)

The evolution path implements CDR at the protocol scale. Where the maintenance path applies CDR to memory entries, the evolution path applies CDR to the conventions and rules that govern how the node operates. This is the mechanism by which the system improves its own decision-making over time.

trace → analyze → propose → evaluate → compile → demote

Stage 1: Trace. Every interaction produces a trace record appended to the eval log.

• Trace records MUST include: the operation performed, the decision made (and alternatives considered), the outcome (useful/not_useful/partial), the entries involved, the conventions applied
• The eval trace log is append-only. Trace entries MUST NOT be modified or deleted.
• Output: trace record appended to eval log

Stage 2: Analyze. Accumulated traces are mined for stable patterns.

• Pattern classes include: stable classification mappings (source X always goes to region Y), consistent query misses (queries about topic Z always return MISS), recurring contradictions (entries from source A consistently conflict with entries from source B), stable routing decisions (inputs matching pattern P always get ROUTE’d to node Q)
• Analysis frequency is policy. The requirement that analysis occurs is protocol.
• Output: candidate patterns with supporting trace evidence

Stage 3: Propose. A candidate pattern is formulated as a convention change — a diff against the current operating rules.

• The proposal MUST include: the proposed rule, the trace evidence supporting it (entry IDs and counts), the expected impact (which operations would change behavior), and a confidence score
• Output: convention change proposal

Stage 4: Evaluate. The proposal is tested counterfactually against historical traces.

• Counterfactual evaluation: if this rule had been in effect during the evidence window, would outcomes have improved?
• The evaluation MUST produce a quantified result (e.g., “would have correctly classified 47/50 entries that were classified by inference, with 3 mismatches”)
• Output: counterfactual evaluation result

Stage 5: Compile. A validated proposal is promoted from Level 0 (pure inference) to Level 2 (convention rule).

• The compiled rule MUST carry: provenance (which traces produced it), a creation timestamp, a review date (the rule’s own renewal schedule — its tau-star), and a confidence threshold below which it should be demoted
• Compiled rules are written to the node’s conventions document (e.g., protocol/conventions.md)
• Output: new compiled rule in conventions

Stage 6: Demote. A compiled rule whose eval trace accuracy has degraded below its confidence threshold is reverted to Level 0 (pure inference).

• Demotion triggers: the rule’s eval mismatch rate exceeds its threshold over a trailing window, OR the rule’s review date is reached and re-evaluation fails
• Demotion MUST be logged as a telemetry event (event class: eval, subtype: rule_demoted)
• The demoted rule is archived (not deleted) with its full performance history
• This is CDR Theorem 3 applied to the protocol’s own optimizations: every compiled rule has a finite optimal lifespan
• Output: rule removed from active conventions, archived with history

3.3.5 Simulation Path (Sandbox Execution)

The simulation path wraps the existing write, read, and maintenance paths in an isolation boundary, enabling “what if” scenarios and counterfactual evaluation with actual replay rather than hypothetical rule application. The sandbox is the protocol primitive that makes replay safe — without it, any replay would mutate real node state.

• DS analogue: staging environment / shadow traffic. Also: database transaction with ROLLBACK — execute operations, observe results, roll back without committing. Also: fork() in process management — create a copy of state, let it diverge, observe the divergence, discard the copy.
• Timescale: per-replay (minutes per replayed interaction). Sandbox lifecycle is ephemeral — created for a specific replay, discarded after.

sandbox:
  sandbox_id: SANDBOX-{UUID-SHORT}
  created: ISO-8601
  base_state: SNAP-{UUID-SHORT}     # Node state snapshot to replay against
  purpose: counterfactual | replay | consolidation
  isolation_guarantee:
    - Writes within the sandbox MUST NOT affect real node state
    - Reads within the sandbox MUST resolve against the sandbox's base_state,
      not the node's current state
    - Maintenance operations within the sandbox MUST NOT modify real
      maintenance queue or eval traces
  sandbox_log:                       # Captures all operations performed in the sandbox
    entries_created: list[entry]
    entries_modified: list[entry_diff]
    decisions_made: list[eval_trace]
    outcome: outcome_signal | null
  lifecycle: ephemeral               # Sandbox state is discarded after use
                                     # Only the sandbox_log is persisted (for comparison)

Structural requirements:

1. All operations within a sandbox MUST execute through the standard write, read, and maintenance paths. The sandbox does not define new operations — it defines an isolation context for existing operations.
2. The isolation_guarantee is protocol. A sandbox that leaks mutations to real state is a protocol violation.
3. The sandbox_log MUST be persisted after sandbox teardown. The log is the observable output of the simulation — it enables comparison between sandbox outcomes and real outcomes.
4. When to create sandboxes (triggers) is policy. The isolation guarantee and log persistence are protocol.

---

3.4 Action Cascade

When a node receives input that requires a decision about how to process it, the node MUST evaluate a cost-ordered action cascade. This is adapted from the AAP v0.4.3 action cascade and functions as a routing policy with cost-based dispatch.

Cascade Order

ROUTE → PUSH → HANDLE → SPAWN

Actions are evaluated in order from cheapest to most expensive. The first action whose preconditions are satisfied is selected.

Action	Description	Cost	Preconditions
ROUTE	Delegate to another node with higher affinity for this input	Cheapest — no local processing, no state change	Colony context exists. Another node has affinity(other, input) > affinity(self, input).
PUSH	Isolate in an ephemeral frame, process, discard frame state	Medium — local processing but no persistent state impact	Input is self-contained. Result does not require durable memory.
HANDLE	Process in current context with full memory operations	Standard — full write/read/maintenance paths apply	Default action when ROUTE and PUSH preconditions are not met.
SPAWN	Create a new specialized node	Most expensive — new node initialization, state transfer, colony coordination	Scope drift exceeds threshold AND minimum context available (see lifecycle gates).

Cost Model

handle_cost = exec_cost + drift_weight * scope_drift
spawn_cost  = spawn_overhead - route_credit

• scope_drift: accumulated measure of how far the current input diverges from the node’s established domain (its receptor). Higher drift means the node is being asked to work outside its specialization.
• drift_weight: policy parameter controlling how aggressively the node avoids scope drift (Section 5).
• spawn_overhead: fixed cost of creating and initializing a new node.
• route_credit: reduction in spawn cost when a suitable existing node is available (partial delegation).

Decision rules:

• ROUTE if affinity(other_node, input) > affinity(self, input) for any reachable node
• SPAWN if scope_drift > drift_threshold AND lifecycle gates are satisfied (Section 3.5)
• PUSH if the input is self-contained and ephemeral (no durable memory impact)
• HANDLE otherwise

Telemetry Requirement

Every action cascade evaluation MUST be logged as a telemetry event:

event_class: decision
subtype: action_cascade
fields:
  input_summary: string          # brief description of the input
  actions_evaluated: list[string] # which actions were considered
  action_selected: string        # the action taken
  rationale: string              # why this action was selected (cost comparison, affinity scores)
  scope_drift_current: float     # current accumulated scope drift

---

3.5 Lifecycle Gates

Lifecycle gates are admission control mechanisms that prevent pathological system behavior. They are hard constraints — a node MUST NOT proceed with the gated action when the gate condition is not met.

Newborn Grace Gate

A newly spawned node MUST NOT spawn children for the first N interactions.

• Purpose: prevents spawn cascades where a new node immediately spawns another node before accumulating enough context to make a meaningful specialization decision
• The grace period length N is policy (Section 5). The existence of the gate is protocol.
• DS analogue: backoff timer on reconnection — prevent thundering herd / cascade failures

Minimum Context Gate

A node MUST NOT spawn a child unless it has at least X tokens of free context capacity.

• Purpose: prevents resource exhaustion where spawning consumes the last available context, leaving both parent and child unable to operate
• The threshold X is policy (Section 5). The existence of the gate is protocol.
• DS analogue: resource reservation before allocation — never allocate from an empty pool

Renewal Gate

When a node’s context_tokens >= context_budget, the node MUST initiate a renewal spawn.

• The renewal spawn creates a successor node with compressed state from the parent. The parent’s accumulated context is condensed into a state digest (max size is policy, default 512 tokens), and the successor begins with fresh context and the digest.
• This is CDR Theorem 3 operationalized at the node level: the node itself is a compression scheme that degrades as context fills. The renewal gate triggers reconstruction.
• DS analogue: log compaction in append-only systems (Kafka, LSM-trees) — when the log exceeds capacity, compact and start a new segment

---

3.6 Telemetry Conformance

Every conforming node MUST emit structured telemetry events. Telemetry is the feedback loop that enables the maintenance path, the evolution path, the fault isolation subsystem, and colony coordination. Without telemetry, the system is blind — CDR renewal cannot be scheduled, patterns cannot be detected, faults cannot be isolated.

Required Event Classes

event_classes:

  decision:
    description: Records what was decided and why
    subtypes:
      - action_cascade       # ROUTE/PUSH/HANDLE/SPAWN decision with rationale
      - classification       # region assignment with reasoning
      - condensation         # observation-to-pattern promotion decision
      - routing              # query routing decision (which regions searched, why)
    required_fields:
      - node_id: string
      - timestamp: ISO-8601
      - subtype: string
      - input_summary: string
      - decision: string
      - rationale: string
      - alternatives_considered: list[string]

  lifecycle:
    description: Records node and entry state transitions
    subtypes:
      - spawn                # new node created (type: renewal, specialization, delegation)
      - archive              # entry moved to glacier
      - expire               # ephemeral entry deleted at TTL
      - renew                # entry confidence restored
      - terminate            # node permanently decommissioned
      - state_change         # node state transition (INITIALIZING, ACTIVE, DORMANT, FENCED, TERMINATED)
    required_fields:
      - node_id: string
      - timestamp: ISO-8601
      - subtype: string
      - target_id: string     # entry ID or node ID affected
      - details: string

  memory:
    description: Records memory operations
    subtypes:
      - write                # new entry committed
      - read                 # entry retrieved (with HIT/MISS/PARTIAL)
      - decay                # confidence reduced by decay pass
      - contradiction_detected  # conflict between new and existing entry
      - link_update          # cross-reference modified
    required_fields:
      - node_id: string
      - timestamp: ISO-8601
      - subtype: string
      - entry_id: string | null  # null for MISS events
      - region: string
      - details: string

  eval:
    description: Records evaluation outcomes for parameter learning and protocol evolution
    subtypes:
      - trace                # interaction trace appended
      - rule_compiled        # pattern promoted to convention rule
      - rule_demoted         # convention rule reverted to inference
      - counterfactual       # counterfactual evaluation result
      - pattern_detected     # stable pattern identified in traces
      - outcome              # task outcome linked back to retrievals and entries (Section 3.3.2 Stage 4)
    required_fields:
      - node_id: string
      - timestamp: ISO-8601
      - subtype: string
      - evidence: string      # trace IDs or summary of supporting data
      - details: string

  fault:
    description: Records fault detection and response events
    subtypes:
      - schema_violation     # entry rejected for schema non-conformance
      - provenance_violation # provenance chain invalid (circular, dangling, unsupported)
      - rate_limit           # operation throttled
      - anomaly_detected     # fault signature matched or anomaly score elevated
      - fence                # node fenced from shared state
      - rollback             # shared state entries reverted
      - excise               # specific entries removed
      - reset                # node state wiped and re-initialized
    required_fields:
      - node_id: string
      - timestamp: ISO-8601
      - subtype: string
      - severity: MONITOR | FENCE | ROLLBACK | EXCISE | RESET
      - target_id: string     # entry, rule, or node affected
      - details: string
      - justification: string  # evidence chain supporting the fault response

  execution:
    description: Records full interaction payload for replay. Distinct from eval —
                 eval records decisions for pattern detection; execution records the
                 complete input, retrieval context, processing, and output for
                 deterministic reproduction (modulo LLM non-determinism).
    subtypes:
      - interaction            # complete record of a single input→output processing cycle
    required_fields:
      - trace_id: EXEC-{UUID-SHORT}
      - node_id: string
      - session_id: string
      - timestamp: ISO-8601
      - snapshot_ref: string   # Node state snapshot in effect at trace time (if available)
      - input_raw: string      # The full input text
      - input_type: user_message | tool_output | colony_message | maintenance_trigger
      - queries_issued: list[query_log_entry]        # Full reads-as-writes entries
      - entries_retrieved: list[entry_snapshot]       # Content + metadata at access time
      - action_cascade_result: string                # ROUTE/PUSH/HANDLE/SPAWN
      - conventions_applied: list[string]            # Which rules were consulted
      - write_path_outputs: list[string] | null      # Entry IDs created
      - maintenance_actions: list[string] | null     # Lifecycle operations triggered
      - output_content: string                       # The full output produced
      - outcome_ref: string | null                   # Reference to outcome signal when available
    capture_rate: policy (default 100%)
    # DS analogue: request trace with full payload capture (OpenTelemetry).
    # Also: WAL entry with redo information — enough data to replay the transaction.
    # Timescale: per-interaction. Storage is append-only with same retention as eval traces.

Queryability Requirements

Telemetry MUST be queryable by:

• node_id — all events from a specific node
• event_class — all events of a given class (decision, lifecycle, memory, eval, fault, execution)
• timestamp_range — all events within a time window
• subtype — all events of a specific subtype within a class
• task_type — all events associated with a given task type classification

The storage format and query mechanism are implementation concerns (policy). The queryability contract is protocol — any telemetry system that cannot satisfy these queries is non-conforming.

Task-Type Performance Register

Telemetry MUST support aggregation by task type to enable per-domain performance assessment. The task-type performance register is a queryable aggregation over outcome signals (Section 3.3.2 Stage 4) and eval traces, computed periodically.

• Without task-type aggregation, the node cannot assess its own competencies, the colony cannot make informed routing decisions (the action cascade’s affinity() function in Section 3.4 has no empirical basis), and spawn/cull/merge decisions lack quantitative fitness signals per domain.
• DS analogue: service-level metrics (SLIs/SLOs per endpoint) — each task type is analogous to a service endpoint with its own latency, error rate, and throughput metrics.
• Timescale: updated per-interaction (append). Aggregated periodically (daily or per-session).

task_type_register:
  node_id: string
  task_type: string
  window: trailing N interactions
  metrics:
    outcome_mean: float         # Mean outcome_quality across tasks of this type
    outcome_trend: float        # Slope of outcome_quality over time (improving/degrading)
    volume: integer             # How many tasks of this type in the window
    retrieval_hit_rate: float   # Fraction of queries for this task type that returned useful results
    contribution_rate: float    # Fraction of retrieved entries that appeared in positive outcome signals

• The task type taxonomy is policy. The requirement that the register exists and is queryable is protocol.
• The register output feeds the action cascade (Section 3.4) as an empirical input to affinity() — a node’s affinity for an input type is grounded in its measured performance on that task type, not just its declared scope.

Retention

Telemetry events MUST be retained for a minimum of one full lifecycle review cycle of the slowest active region (i.e., if structural entries have a quarterly review, telemetry MUST be retained for at least one quarter). Implementations MAY retain telemetry longer. Telemetry SHOULD be archived (not deleted) after the retention period.

Purpose

Telemetry serves three consumers:

1. Maintenance path — decay scheduling, renewal triggering, condensation detection rely on memory event telemetry
2. Evolution path — pattern detection, counterfactual evaluation, rule compilation rely on decision and eval telemetry
3. Fault isolation — invariant checks, anomaly detection, fault response rely on fault telemetry and cross-correlation with memory/decision events

A node that does not emit conforming telemetry cannot participate in any of these feedback loops. The telemetry contract is what makes CDR renewal computable rather than aspirational.

---

3.7 Ground Truth Protocol

The spec references “ground truth” in rule monitoring (Section 7: “match rate against ground truth in the trailing window”) and evidence evaluation (Section 7: “fraction of decisions that match ground truth”) but does not define what ground truth IS or where it comes from. Without a ground truth protocol, every accuracy metric in the self-modification lifecycle is undefined. This section resolves that structural gap.

Justification

Ground truth is the reference standard against which the system measures its own accuracy. The protocol requires accuracy measurements for rule compilation (is this proposed rule correct?), rule monitoring (is this compiled rule still accurate?), entry impact scoring (was this memory valuable?), and task-type performance tracking (is the node competent at this task type?). All of these measurements depend on a defined hierarchy of truth sources.

Operating Timescale

• Per-interaction: human feedback when available
• Per-session: self-assessment at session end
• Periodic: ground truth quality audit (review the mix of truth sources being relied upon)

DS Analogue

Oracle model in distributed testing. Also: label acquisition strategy in active learning — the system must decide when to pay the cost of obtaining a high-quality label vs. relying on a cheap proxy.

Ground Truth Hierarchy

ground_truth_hierarchy:
  # Ordered from strongest to weakest
  - source: human_explicit
    description: Human directly confirms or rejects the outcome
    weight: 1.0
    availability: rare (requires human in loop)

  - source: downstream_verification
    description: A subsequent operation validates the prior result
                 (e.g., code compiles, test passes, claim verified by tool)
    weight: 0.85
    availability: conditional (requires verifiable task type)

  - source: consistency_check
    description: Outcome is consistent with other entries at equal or higher confidence
    weight: 0.6
    availability: common (requires existing high-confidence entries in same domain)

  - source: self_assessed
    description: The node assesses its own output quality
    weight: 0.3
    availability: always
    constraint: Self-assessment MUST NOT be the sole ground truth source
                for rule compilation (Section 7, Stage 4).
                Self-assessment MAY be used for entry impact scoring.

Protocol Requirements

1. Every outcome signal (Section 3.3.2 Stage 4) MUST include an outcome_source field that maps to one of the four hierarchy levels.
2. When computing accuracy metrics for rule compilation or rule monitoring, the system MUST weight each data point by the ground truth weight of its source. A metric computed entirely from self_assessed sources (weight 0.3) is weaker than one computed from downstream_verification sources (weight 0.85).
3. Self-assessment MUST NOT be the sole ground truth source for promoting a pattern to a compiled rule (evolution path Stage 5). At least one data point from a higher-weight source (consistency_check or above) MUST be present in the evidence set.
4. The specific weights (1.0, 0.85, 0.6, 0.3) are protocol defaults. Implementations MAY adjust weights via policy (Section 5) but MUST preserve the strict ordering: human_explicit > downstream_verification > consistency_check > self_assessed.
5. Implementations SHOULD log the ground truth source distribution periodically (event class: eval, subtype: ground_truth_audit) to detect over-reliance on weak sources.