Pluggable Policies

5.0 Preamble

Justification

Without the protocol/policy distinction, the Synixolis spec is either too rigid or too loose. Too rigid: if decay rates, classification heuristics, and condensation triggers are hardwired into the protocol, every deployment must use identical parameters regardless of domain, workload, or operating constraints — the spec becomes a straitjacket that prevents adaptation. Too loose: if everything is configurable, “Synixolis-conforming” degrades to “does whatever it wants” — the spec provides no guarantees.

Pluggable policies resolve this by separating what MUST be true (protocol) from what CAN vary (policy). The protocol defines structural invariants derived from CDR theory and the node contract (Section 3). Policies define the parameters within those invariants that implementations tune for their environment. Human priors set the starting configuration. Modification gates control what the system can change autonomously versus what requires human approval.

This maps directly to the distributed systems distinction between algorithm (fixed — the consensus protocol, the replication strategy, the consistency model) and configuration (tunable — timeout values, replication factor, batch sizes). Modification gates are access control on configuration — the same concept as IAM policies on infrastructure settings, or the distinction between sysctl parameters a process can tune and those that require root.

Operating Timescale

Operation	Timescale
Policy evaluation (reading current configuration)	Per-operation (ms) — policies are always loaded
Human prior initialization	Once, at node creation
System-proposed policy changes	Days to weeks — requires accumulated evidence from eval traces
Human-approved policy changes	Days to weeks — human review cycle
Protocol changes	Never within a deployment. Protocol evolves only through the spec evolution process (Section 7).

Policy changes operate on days-to-weeks timescales because the evidence required to justify a change (eval traces, pattern detection, counterfactual evaluation) accumulates over that period. The protocol itself is permanent within a given spec version — it does not change during operation.

Distributed Systems Framing

Concept	DS Analogue
Protocol requirements	Algorithm invariants (consensus safety properties, consistency guarantees)
Policy parameters	Configuration (timeouts, batch sizes, replication factors)
Human priors	Initial configuration / bootstrap parameters
Modification gates	Access control on configuration (IAM, RBAC on infrastructure settings)
system_auto gate	Process-tunable parameters (sysctl values a service can adjust)
system_propose_human_approve gate	Change management with approval workflow (Terraform plan/apply, GitOps PR review)
human_only gate	Root-only parameters (kernel parameters, security policy)
locked gate	Immutable infrastructure (read-only filesystem, signed configuration)

---

5.1 Protocol Requirements (Non-Negotiable)

These are structural invariants derived from CDR theory and the node contract. They are not configurable. A system that violates any of these is non-conforming regardless of its policy configuration.

P1: Temporal Partitioning

Memory MUST be divided into regions with different metabolic rates.

• Source: CDR Theorem 2 (Temporal Partitioning) — multi-timescale sources require timescale-matched partitions.
• What is fixed: The requirement that regions exist and that each region has a distinct lifecycle (timescale, decay behavior, renewal mechanism). The minimum region count is three (fast, slow, permanent).
• What is policy: The number of regions beyond the minimum, their names, and their specific timescale boundaries (Section 5.2.1).

P2: Provenance

Every memory entry MUST carry a provenance chain that terminates at a verifiable source.

• Source: Traceability is the foundation of the eval loop, the fault isolation subsystem, and colony trust. Without provenance, entries cannot be audited, contradictions cannot be traced to their origin, and fault isolation cannot determine blast radius.
• What is fixed: The requirement that provenance exists, that it is acyclic, and that it terminates at a verifiable source (user input or tool output).
• What is policy: Nothing. Provenance format is defined in the entry schema (Section 3.2). There are no tunable provenance parameters.

P3: Decay and Renewal

Regions with active lifecycle MUST implement decay (confidence degradation over time) and renewal (confidence restoration on positive evidence).

• Source: CDR Theorem 3 (Finite Optimal Lifespan) — every compression scheme degrades under distributional drift. Renewal at the optimal interval is computable.
• What is fixed: The requirement that decay occurs, that renewal occurs, and that the maintenance path implements both. Entries that are never renewed MUST eventually fall below archival threshold.
• What is policy: Decay rates, renewal amounts, archival thresholds, decay schedules (Section 5.2.2).

P4: Eval Traces

The node MUST emit structured telemetry conforming to the event classes defined in Section 3.6.

• Source: The eval trace is the measurement system. Without it, the evolution path has no data, the maintenance path has no scheduling signal, and fault isolation has no detection input. The feedback loop is structural — remove it and CDR renewal becomes guesswork.
• What is fixed: The requirement that traces are emitted, that they conform to defined event classes, that they are append-only, and that they are queryable by the dimensions specified in Section 3.6.
• What is policy: Trace retention period beyond the required minimum, sampling rate for high-volume event types, storage format.

P5: Optimization Ladder

The system MUST support the progression from Level 0 (pure inference) through Level 2 (convention compilation), with compiled rules carrying provenance and a finite lifespan.

• Source: Without the optimization ladder, the system has no path to reducing inference cost. Without lifespan on compiled rules, optimization is a one-way ratchet that accumulates stale rules (violating CDR Theorem 3 applied to the protocol itself).
• What is fixed: The requirement that the evolution path exists (trace, analyze, propose, evaluate, compile, demote), that compiled rules carry provenance and review dates, and that degraded rules are demoted.
• What is policy: Compilation thresholds (how much evidence is enough), review intervals for compiled rules, demotion thresholds (Section 5.2.6).

P6: Invariant Checks

The node MUST run per-operation invariant validation: provenance chain validation, schema enforcement, and rate limiting.

• Source: Section 3 (node contract) and Section 7b (fault isolation). Invariant checks are the fast-path fault detection layer. Without them, Byzantine faults propagate through shared state before any other detection mechanism can respond.
• What is fixed: The requirement that invariant checks run on every write, spawn, and convention proposal. The specific invariants (provenance acyclicity, schema conformance, rate limits).
• What is policy: Rate limit values, conflict detection sensitivity (Section 5.2.8).

---

5.2 Policy Parameters (Configurable)

Each policy parameter has a default value (the reference configuration), a valid range, and a modification gate controlling who can change it (Section 5.4).

5.2.1 Region Configuration

policy:
  regions:
    count: 5                        # Valid range: [3, 7]. Default: 5.
                                    # Minimum 3 required: fast (active decay),
                                    # slow (review cycle), permanent (human-gated).
                                    # Glacier is implicit (archive target).
    names:
      - ephemeral                   # Policy. Any name is valid.
      - operational                 # The protocol requires distinct lifecycle
      - structural                  # per region, not specific names.
      - identity
      - glacier
    timescale_boundaries:
      ephemeral_max: 24h            # Default: 24h. Entries older than this in
                                    # ephemeral are protocol violations.
      operational_max: 30d          # Default: 30d. Guidance, not hard boundary.
      structural_max: 365d          # Default: 365d. Guidance, not hard boundary.

Constraints: Each region MUST have a distinct lifecycle configuration (timescale, decay behavior). Two regions with identical lifecycle parameters are redundant — the implementation SHOULD merge them or differentiate their decay/renewal behavior.

5.2.2 Decay Rates

policy:
  decay:
    operational:
      rate: 0.05                    # Confidence loss per day. Default: 0.05.
      unit: day                     # Time unit for rate. Default: day.
      schedule: 24h                 # How often decay is applied. Default: 24h.
    structural:
      rate: 0.01                    # Confidence loss per day. Default: 0.01.
      unit: day
      schedule: 7d                  # Structural decay applied weekly. Default: 7d.
    archival_threshold:
      operational: 0.3              # Below this confidence → archive. Default: 0.3.
      structural: 0.2              # Default: 0.2.

Constraints: Decay rates MUST be non-negative. A rate of 0.0 is valid (no decay) but the implementation MUST still run the decay pass — the protocol requires the mechanism to exist even if the current configuration sets the rate to zero. This preserves the ability to increase the rate later without structural changes.

5.2.3 Classification Heuristics

policy:
  classification:
    method: timescale_heuristic     # One of: timescale_heuristic, triad_decomposition,
                                    # domain_rules, llm_inference.
                                    # Default: timescale_heuristic.
    rules:                          # Compiled classification rules (populated by evolution path).
      - pattern: "source:meeting-transcript"
        region: operational
        confidence: 0.95
        compiled_from: "traces 2026-01-15 to 2026-02-01"
        review_date: "2026-04-01"
      - pattern: "source:architecture-review"
        region: structural
        confidence: 0.90
        compiled_from: "traces 2026-02-01 to 2026-02-15"
        review_date: "2026-05-01"
    fallback: llm_inference         # When no rule matches. Default: llm_inference.

Constraints: The rules list is populated by the evolution path (Section 3.3.4). Rules MUST carry provenance (compiled_from) and a review date. Rules past their review date MUST be re-evaluated before continued use.

5.2.4 Condensation Triggers

policy:
  condensation:
    min_observations: 3             # Minimum observation count before pattern promotion.
                                    # Default: 3.
    min_time_span: 14d              # Observations must span at least this duration.
                                    # Default: 14 days.
    min_confidence: 0.5             # Minimum average confidence of source observations.
                                    # Default: 0.5.
    promotion_target: structural    # Default target region for condensed entries.
                                    # Default: structural.

Constraints: min_observations MUST be >= 2 (a single observation is not a pattern). min_time_span MUST be > 0 (observations at a single point in time do not demonstrate persistence).

5.2.5 Confidence Thresholds

policy:
  confidence:
    initial_values:
      ephemeral: 1.0               # Ephemeral entries start at full confidence.
      operational: 0.8              # Default: 0.8.
      structural: 0.9              # Structural entries require higher initial confidence.
      identity: 1.0                # Identity entries are fully confident by definition.
    renewal_amount:
      operational: 0.3             # Confidence boost on renewal. Default: 0.3.
      structural: 0.2             # Default: 0.2.
    contradiction_penalty: 0.2     # Confidence reduction on lower-confidence entry
                                   # when contradiction detected. Default: 0.2.

Constraints: All confidence values MUST be within [0.0, 1.0]. initial_values + renewal_amount MUST NOT exceed 1.0 (confidence is clamped at ceiling).

5.2.6 Evolution Path Parameters

policy:
  evolution:
    compilation_threshold:
      min_traces: 50                # Minimum trace count supporting a pattern. Default: 50.
      min_accuracy: 0.95            # Minimum accuracy across traces. Default: 0.95.
    rule_review_interval: 60d       # How often compiled rules are re-evaluated. Default: 60 days.
    demotion_threshold: 0.7         # Accuracy below this triggers demotion. Default: 0.7.
    demotion_window: 50             # Trailing number of classifications to evaluate. Default: 50.

5.2.7 Ingestion Patterns

policy:
  ingestion:
    method: passthrough             # One of: passthrough, triad, entity_extraction,
                                    # custom. Default: passthrough.
    triad_config:                   # Only relevant if method is triad.
      facets: [E, R, V, X]         # Epistemic, Relational, Values, eXceptions.
      parallel: true               # Process facets in parallel. Default: true.
    entity_extraction_config:       # Only relevant if method is entity_extraction.
      model: llm                    # Extraction model. Default: llm.

Constraints: The ingestion method determines how raw input is decomposed into candidate entries at the ingest stage of the write path (Section 3.3.1). The ingestion output MUST conform to the entry schema — regardless of decomposition strategy, each candidate entry MUST have content and source populated.

5.2.8 Query Routing

policy:
  query_routing:
    cascade_order:
      - ephemeral
      - operational
      - structural
      - identity
      - glacier
    early_termination: true         # Stop cascade on first sufficient result. Default: true.
    glacier_on_miss: true           # Always check glacier on complete miss. Default: true.
    max_results_per_region: 10      # Default: 10.

Constraints: The cascade MUST include all active regions. The cascade MUST terminate at glacier (if glacier_on_miss is true) or return empty (if false). Skipping regions in the cascade is a protocol violation — the page-fault model requires ordered traversal.

5.2.9 Fault Detection Thresholds

policy:
  fault_detection:
    rate_limits:
      writes_per_node_per_hour: 100       # Default: 100.
      spawns_per_node_per_day: 5          # Default: 5.
      convention_proposals_per_week: 3    # Default: 3.
    conflict_sensitivity:
      self_conflict_window: 20            # Trailing writes to check for self-contradiction.
                                          # Default: 20.
      self_conflict_threshold: 0.3        # Fraction of self-conflicting writes triggering
                                          # anomaly elevation. Default: 0.3.
      cross_node_conflict_threshold: 0.2  # Fraction of cross-node conflicts triggering
                                          # anomaly elevation. Default: 0.2.
    fence_duration: 24h                   # Default auto-lift duration for fences
                                          # without confirming evidence. Default: 24h.
    provenance_audit:
      interval: 14d                       # Default audit cycle. Default: 14 days.
      post_incident_interval: 3d          # Tightened cycle after fault incidents. Default: 3 days.
      budget_fraction: 0.1                # Fraction of inference budget for auditing.
                                          # Default: 0.1.

5.2.10 Fault Response Gates

policy:
  fault_response:
    monitor: system_auto                  # System can elevate monitoring autonomously.
    fence: system_auto                    # System can fence nodes autonomously.
    rollback: system_propose_human_approve # Shared state rollback requires human approval.
    excise: system_propose_human_approve   # Targeted removal requires human approval.
    reset: human_only                     # Node reset always requires human approval.

5.2.11 Lifecycle Gate Parameters

policy:
  lifecycle_gates:
    newborn_grace_period: 10              # Interactions before a new node can spawn.
                                          # Default: 10.
    minimum_context_tokens: 2048          # Free tokens required before spawn is permitted.
                                          # Default: 2048.
    drift_threshold: 0.7                  # Scope drift level triggering spawn consideration.
                                          # Default: 0.7.
    drift_weight: 1.0                     # Weight of scope drift in handle_cost calculation.
                                          # Default: 1.0.
    state_digest_max_tokens: 512          # Maximum size of compressed state passed to
                                          # successor on renewal spawn. Default: 512.

5.2.12 Maintenance Budget

policy:
  maintenance:
    budget_fraction: 0.15                 # Fraction of inference budget for maintenance.
                                          # Default: 0.15 (15%).
    priority_order:                       # When budget is insufficient, run in this order.
      - fault_response                    # Always first — containment before cleanup.
      - expire                            # Ephemeral TTL enforcement.
      - decay                             # Confidence reduction pass.
      - condensation                      # Observation-to-pattern promotion.
      - provenance_audit                  # Cross-reference integrity.
      - convention_review                 # Compiled rule re-evaluation.

---

5.3 Human Priors

Human priors are the starting configuration provided at node creation. They set the initial policy values before the system has any operational evidence to inform adaptation. The system operates on these priors until the evolution path accumulates enough trace evidence to propose changes.

Prior Format

priors:
  # Ingestion strategy
  ingestion: triad                        # Use E/R/V/X facet decomposition

  # Region tuning
  operational_decay_rate: 0.07            # Faster decay than default (7% per day vs 5%)
  structural_review_interval: 30d         # Monthly structural review (vs default quarterly)

  # Condensation tuning
  condensation_min_observations: 5        # Require more evidence before pattern promotion
  condensation_min_time_span: 21d         # Require longer observation window

  # Classification shortcuts
  classification_rules:
    - pattern: "source:meeting"
      region: operational
    - pattern: "source:architecture-review"
      region: structural
    - pattern: "source:user-correction"
      region: identity

  # Fault detection tuning
  fence_duration: 48h                     # Longer fence window for environments
                                          # with infrequent sessions

  # Maintenance budget
  maintenance_budget_fraction: 0.20       # Allocate more budget to maintenance
                                          # in high-volume environments

Prior Semantics

1. Priors MUST be valid policy values. A prior that violates policy constraints (e.g., condensation_min_observations: 1) MUST be rejected at node initialization with a logged error.
2. Any policy parameter not specified in priors takes its default value.
3. Priors are the Level 0 (pure inference) starting point. They are subject to the evolution path — if the system accumulates evidence that a prior is suboptimal, it MAY propose a change (subject to modification gates, Section 5.4).
4. Priors themselves carry implicit provenance: they originate from the human operator. Changes proposed by the evolution path carry trace-based provenance. This provenance distinction is visible in the compiled rules list.

Reference Priors

The reference implementation ships with a default prior set corresponding to the default values in Section 5.2. Implementations MAY provide domain-specific prior templates:

Template	Description	Key Differences from Default
default	General-purpose single node	All defaults as specified in 5.2
high-volume	Environments with frequent interactions	Higher rate limits, faster decay, shorter condensation windows
research	Knowledge-heavy, low-frequency interactions	Slower decay, higher condensation thresholds, larger audit budget
team-colony	Multi-node colony for team knowledge	Colony-aware defaults, longer fence durations, stricter promotion thresholds

---

5.4 Modification Gates

Modification gates define the access control policy on configuration changes. They answer: who can change this parameter, and through what process?

Gate Types

gate_types:

  locked:
    description: Immutable within a spec version. Cannot be changed by the system
                 or by human configuration. Changes require a new spec version.
    who_changes: spec authors only (protocol evolution)
    process: out-of-band spec revision
    applies_to: protocol requirements (Section 5.1)

  human_only:
    description: Only the human operator can change this value. The system MUST NOT
                 propose changes. The system MAY surface information relevant to the
                 parameter (e.g., "identity entries have not been reviewed in 6 months")
                 but MUST NOT frame it as a change proposal.
    who_changes: human operator
    process: direct configuration edit
    applies_to: identity region content, colony steering parameters (max colony size,
                budget, protected domains), node reset approval

  system_propose_human_approve:
    description: The system MAY propose a change based on accumulated evidence.
                 The proposal MUST include the evidence (trace IDs, accuracy metrics,
                 counterfactual evaluation results). The change takes effect only
                 after human approval.
    who_changes: system proposes, human approves
    process: proposal logged to protocol/changelog.md, human reviews and accepts/rejects
    applies_to: decay rates, confidence thresholds, fault detection thresholds,
                shared state rollback, fault excision

  system_auto:
    description: The system MAY make changes autonomously based on accumulated evidence,
                 subject to the evolution path requirements (Section 3.3.4). All changes
                 MUST be logged with full provenance and are subject to demotion if
                 they degrade.
    who_changes: system (autonomous)
    process: evolution path (trace → analyze → propose → evaluate → compile)
    applies_to: classification rules, query routing patterns, condensation templates,
                contradiction detection heuristics, fault fencing, monitoring escalation

Gate Assignment Table

The complete mapping of policy parameters to modification gates:

Policy Parameter	Gate	Rationale
Region count and names	human_only	Changing the region topology is a structural decision
Region timescale boundaries	system_propose_human_approve	System may learn better boundaries, but structural change needs oversight
Decay rates	system_propose_human_approve	Decay rate changes affect retention globally; human should validate
Archival thresholds	system_propose_human_approve	Determines what gets preserved; human oversight warranted
Classification rules	system_auto	High-frequency optimization target; evolution path handles lifecycle
Classification method	human_only	Switching ingestion strategy is a structural decision
Condensation triggers	system_propose_human_approve	Affects pattern quality; human should validate evidence
Confidence initial values	system_propose_human_approve	Affects entry lifecycle trajectory
Confidence renewal amounts	system_propose_human_approve	Affects how quickly entries recover from decay
Contradiction penalty	system_propose_human_approve	Affects how aggressively conflicts degrade existing knowledge
Evolution compilation thresholds	system_propose_human_approve	Meta-parameter: controls how aggressively the system self-modifies
Rule review intervals	system_auto	Routine lifecycle management
Demotion thresholds	system_propose_human_approve	Meta-parameter: controls when the system abandons learned rules
Ingestion method	human_only	Structural choice
Query routing cascade order	system_propose_human_approve	Affects retrieval behavior; human should validate
Early termination	system_auto	Performance optimization, low risk
Rate limits	system_propose_human_approve	Security-relevant; human oversight warranted
Conflict sensitivity thresholds	system_propose_human_approve	Affects fault detection sensitivity
Fence duration	system_propose_human_approve	Affects how long a suspected node is isolated
Provenance audit interval	system_auto	Routine scheduling; adaptive tightening after incidents is autonomous
Audit budget fraction	system_propose_human_approve	Budget allocation is a resource decision
Fault response gates (per-level)	human_only	Determines the autonomy boundary for fault response
Lifecycle gate parameters	system_propose_human_approve	Affects spawn behavior; human should validate
Maintenance budget fraction	system_propose_human_approve	Budget allocation is a resource decision
Maintenance priority order	human_only	Defines triage policy; structural decision
Identity region entries	human_only	Identity is human-defined by protocol requirement
Colony max size	human_only	Resource boundary
Colony budget	human_only	Resource boundary
Colony protected domains	human_only	Organizational decision
Colony spawn approval mode	human_only	Autonomy boundary
Protocol requirements (Section 5.1)	locked	CDR-derived invariants; not configurable

Modification Logging

Every policy change MUST be logged to protocol/changelog.md with:

policy_change:
  timestamp: ISO-8601
  parameter: string                # which parameter changed
  old_value: any                   # previous value
  new_value: any                   # new value
  gate: string                     # which gate authorized the change
  initiator: system | human        # who initiated the change
  evidence: string | null          # trace evidence (for system-initiated changes)
  approved_by: string | null       # human approver (for system_propose_human_approve gates)

This log is append-only. It provides the audit trail for all configuration changes and is a primary input for diagnosing policy-related issues in the fault isolation subsystem.

---

5.5 Protocol vs. Policy: The Decision Rule

When deciding whether a new mechanism belongs in protocol or policy, apply the following test:

1. Is it derivable from CDR theory? If removing this mechanism would violate one of the four CDR theorems, it is protocol. Example: decay exists because CDR Theorem 3 proves compression schemes degrade. The specific decay rate is not derivable from the theorem — it depends on the domain.

2. Do other subsystems depend on its existence (not its value)? If the eval loop, the fault isolation layer, or colony coordination structurally depend on this mechanism existing, it is protocol. Example: telemetry emission is protocol because the evolution path cannot function without traces. The trace retention period beyond the minimum is policy.

3. Can a reasonable implementation choose differently without breaking the system? If yes, it is policy. Example: a 14-day operational decay rate is reasonable. So is a 7-day rate. So is a 30-day rate. The system functions correctly with any of these values. Therefore the specific rate is policy.

4. Would removing this mechanism require a different protocol to compensate? If yes, it is protocol. Example: provenance is protocol — without it, you would need an entirely different trust and audit mechanism to compensate.

This test is not algorithmic — it requires judgment. When in doubt, make it protocol. It is easier to relax a protocol requirement into a policy parameter in a future spec version than to harden a policy parameter into a protocol requirement after implementations have diverged.