R89.B λ Phase 2 Staging — Audit
Step 1 of 5 in the R89.B 5-step chain. Surface inventory of the λ Reputation spec corpus against
docs/spec/s04-reputation.md,docs/spec/s05-experience-tokens.md,docs/spec/s09-arbitration.md, anddocs/3-world/social/reputation.md. The output of this audit feeds the contract (Step 2) and the packet (Step 3) that gate the prompt-file author step (Step 4).
1. Inputs read
| Source | Lines | Status when read |
|---|---|---|
docs/spec/s04-reputation.md |
79 | spec-only; donor genealogy table at §Implementation Status |
docs/spec/s05-experience-tokens.md |
202 | spec-only; partial overlap with heritage mcp_memory_frame |
docs/spec/s09-arbitration.md |
68 | spec-only; entirely forward-looking |
docs/3-world/social/reputation.md |
98 | concept doc; colibri_code: none; Phase 0 schema-only |
docs/guides/implementation/task-breakdown.md §Phase 2 (lines 761–860) |
100 | 7 sub-tasks already specified |
docs/guides/implementation/task-prompts/p1.1-kappa-rule-engine.md |
2944 | reference pattern (κ 20-task prompt file) |
docs/guides/implementation/task-prompts/index.md |
187 | task-prompts directory index |
CLAUDE.md (worktree copy) |
(full) | §3 worktree, §5 gate, §6 5-step, §7 writeback, §13 git auth |
2. λ surface obligations (extracted from spec)
The λ Reputation axis must, by Phase 2 close, materialize the following surface elements
in src/domains/reputation/ (path declared in s04 §Implementation Status note and in
task-breakdown.md §P2.1.1 output spec):
2.1 Schema (s04 §Three domains + reputation.md §The five domains)
| Element | Source | Notes |
|---|---|---|
| Domain enumeration | s04 §Three domains | s04 specifies 3 domains (Execution, Commissioning, Arbitration); reputation.md and task-breakdown.md §P2.1.1 use 5 domains (adds Governance, Social). Discrepancy: load-bearing. task-breakdown is the canonical implementation contract per CLAUDE.md §11, so executor uses 5 domains. |
| Decay rates (bps/epoch) | reputation.md §The five domains | execution=500, commissioning=300, arbitration=1000, governance=200, social=domain-specific. task-breakdown.md §P2.2.1 lists social=100bps. |
| Per-domain record fields | task-breakdown.md §P2.1.1 | node_id, domain, score (0–10000 bps), scars (bitmask), ban_until_epoch, last_activity_epoch |
| History table | task-breakdown.md §P2.1.1 | (node_id, domain, epoch, delta, reason, event_id) with append-only AX-01 semantics |
| Indexes | task-breakdown.md §P2.1.1 | (node_id, domain) primary; (domain, score DESC) leaderboard |
2.2 Score computation (s04 §Computation)
| Element | Source | Surface obligation |
|---|---|---|
compute_score(node_id, domain, events[]) |
s04 §Computation, task-breakdown.md §P2.1.2 | Σ(ack_weight × event_outcome) with ack_weight bounded by acknowledger’s same-domain reputation (feedback-loop guard). |
| BPS integer math | s04 §Computation | 64-bit signed; basis points (1 bp = 0.01%). Inherits src/domains/rules/integer-math.ts (R83 P1.1.1) + bps-constants.ts (R83 P1.1.3). |
| Score cap | task-breakdown.md §P2.1.2 | min(10000 - scar_bps, ...) — capped at 100% minus scar penalties. |
| Monotonicity | task-breakdown.md §P2.1.2 | Property test: score non-decreasing under positive-event-only sequences. |
| Damage table | s04 §Damage table | abandonment=-15%, missed-deadline=-20%, lost-dispute=-25%, non-payment=-50%, overturned-arbitration=-30%, fraud=-100%+scar. (reputation.md §Penalty schedule overlaps but uses different categories: equivocation, verification forgery, axiom-drift. task-breakdown.md §P2.2.2 normalizes to minor/moderate/severe/critical/fraud bands.) |
2.3 Decay (s04 §Decay + reputation.md §The five domains)
| Element | Source | Surface obligation |
|---|---|---|
| Decay applies only during inactivity | s04 §Decay | Activity in domain resets that domain’s decay counter (per-domain timer). |
| Multi-epoch compounded | task-breakdown.md §P2.2.1 | new_score = score - apply_bps(score, decay_rate) per inactive epoch. Already implemented in src/domains/rules/integer-math.ts::decay() (R83 P1.1.1). |
| Floor | task-breakdown.md §P2.2.1 | Score cannot go below 0. |
| Batch processing | task-breakdown.md §P2.2.1 | Efficient for 10k+ nodes per epoch. |
2.4 Penalty schedule + scars (s04 §Damage table + reputation.md §Penalty schedule)
| Element | Source | Surface obligation |
|---|---|---|
| Penalty table | task-breakdown.md §P2.2.2 | minor=1500, moderate=3000, severe=5000, critical=8000, fraud=10000 (bps) |
| Scar mechanism | s04 §Damage table, task-breakdown.md §P2.2.2 | Permanent cap reduction: score ≤ 10000 - scar_bps forever (s04 says “cap at 50% of pre-scar level”; task-breakdown uses scar_bps subtractive model — these reconcile under “scar = persistent ceiling reduction”). |
| Ban mechanism | task-breakdown.md §P2.2.2 | Critical+ offenses ban from arbitration for N epochs (ban_until_epoch field on schema). |
| Double-jeopardy guard | task-breakdown.md §P2.2.2 | Same event_id cannot trigger same penalty twice. |
| Recovery path | task-breakdown.md §P2.2.2 | After ban expires, node starts at scar-limited maximum. |
2.5 Experience tokens (s05 + reputation.md §Experience tokens)
| Element | Source | Discrepancy notes |
|---|---|---|
| Levels | s05 §Token levels | L0/L1/L1.5/L2a/L2b/L3 (six levels). reputation.md §Experience tokens uses L0/L1/L2/L3 (four levels). task-breakdown.md §P2.3.1 uses L0/L1/L1.5/L2a/L2b (five levels — no L3). executor uses s05 + task-breakdown convergence: L0/L1/L1.5/L2a/L2b, with L3 deferred to Phase 2+ aggregation (reputation.md treats L3 as authority/governance-ratified — different semantic). |
| Promotion rules | s05 §Promotion flow | event-complete→L1; witness-attested→L1.5; 5+ pattern repeats→L2a; context-invariant→L2b. Witness floor reputation_at_witness ≥ 200, weight cap ≤ 0.3, sum cap ≤ 0.4 × MIN_EPISODES. |
| Non-transferable | s04 §opener, s05 §opener | Token bound to actor (ξ Soul Vector id when ξ ships; Phase 0/2 uses node_id). |
| Append-only | s05 §Append-only vs garbage collection | Event log immutable (AX-01); derived token cache prunable but reconstructible. |
| Witness independence | s05 §Witness registry | Max 1 witness per counterparty class per rolling 7-day window. |
| Pattern matching | s05 §Pattern-matching algorithm | feature_hash = SHA-256(canonical_context ‖ action_type ‖ outcome_class); diversity ≥3 scenarios + ≥3 counterparty classes; invariance under context-null replay. |
| Scar supersession | s05 §Decay and scar supersession | Scar in a domain voids the L2b token’s contribution to L3 (token itself not deleted — weight clamped to 0). Append-only honored. |
2.6 Derived limits (s04 §Derived limits + reputation.md §Derived limits)
| Element | Source | Surface obligation |
|---|---|---|
| Max parallel tasks | s04 §Derived limits | sqrt(execution_rep), capped at 20. task-breakdown.md §P2.4.1 expresses as sqrt_floor(rep), max=20. Uses sqrt_floor from κ built-ins (P1.3.2). |
| Rate-limit bonus | s04 §Derived limits | base_rate × log2(rep). task-breakdown.md §P2.4.1 uses log2_floor(max(rep, 1)). |
| Arbitration eligibility | s04 §Derived limits, reputation.md §Penalty schedule | task-breakdown.md §P2.4.1: arbitration ≥ 5000 AND execution ≥ 3000. |
| Governance eligibility | reputation.md §Voting credits, task-breakdown.md §P2.4.1 | governance ≥ 4000. |
| Stake discount | s04 §Derived limits (inverse-rep), task-breakdown.md §P2.4.1 | required_stake × 10000 / max(rep, 1000). |
| Voting credits (read-only) | reputation.md §Voting credits | Σ (domain_score × domain_weight) in BPS. Quadratic-voting cost lives in π governance (Phase 6); λ exposes credit balance only. |
2.7 Arbitration (s09 — third member of the λ surface trio)
s09 specifies dispute resolution, not core reputation arithmetic. Its λ-level couplings:
| Element | Source | λ obligation |
|---|---|---|
| Arbitrability scope | s09 §What is/is NOT arbitrable | Reputation math is NOT arbitrable (s09 §What is NOT). λ provides the read-side surface; the write-side mutations from arbitration outcomes are the inputs to penalty/scar logic in P2.2.2. |
| VRF arbiter selection | s09 §Arbiter selection | Weighted by arbitration reputation. λ exposes reputation_get(node_id, "arbitration") for the selector to consume; the selector itself lives in P3 (θ) per task-breakdown.md §P3.1.1. |
| Arbiter eligibility constraints | s09 §Arbiter constraints + reputation.md §Penalty schedule | Reputation-derived gates: minimum arbitration + execution scores. Lands in P2.4.1 can_arbitrate(rep) gate. |
| Reputation effects of arbitration outcomes | s09 §Arbiter constraints, s04 §Damage table | Overturned-arbitration decision → arbitration domain −30%. This is a penalty event input consumed by P2.2.2 — not a new tool surface, just a damage-table row already covered. |
| Commit-reveal voting / panel sizes / escalation levels | s09 §Escalation levels, §Voting | Out of scope for λ. These are θ consensus + π governance concerns (Phase 3 + 6). λ Phase 2 only needs to consume arbitration_decision events as event_outcome inputs to compute_score. |
2.8 MCP tool surface (task-breakdown.md §P2.5.1 + reputation.md §Phase 0 posture)
| Tool | Surface contract |
|---|---|
reputation_get(node_id, domain?) |
Returns {score, scars, ban_until, last_activity} per domain (or all domains if domain omitted). |
reputation_history(node_id, domain, limit) |
Paginated history events ordered by epoch DESC. |
reputation_leaderboard(domain, limit) |
Top N nodes by score in domain. |
reputation_check_gates(node_id) |
{can_arbitrate, can_govern, max_parallel_tasks, rate_limit_bonus, stake_discount} derived from current scores. |
All four tools register via the ε Skill Registry (P0.6.x). Read-only; no mutation surface in Phase 2 — mutations are event-driven through the rule engine (κ).
3. Discrepancies between sources (executor reconciliation)
| # | Source A | Source B | Reconciliation |
|---|---|---|---|
| 1 | s04: 3 domains (Execution, Commissioning, Arbitration) | reputation.md + task-breakdown: 5 domains (adds Governance, Social) | Use 5. task-breakdown.md is the canonical implementation contract; s04 is the older spec that pre-dated governance/social domains. The schema must carry 5 domain rows. |
| 2 | s04 damage table: % values per offense | task-breakdown.md §P2.2.2 penalty bands: minor/moderate/severe/critical/fraud | Use task-breakdown bands. The s04 offense-specific values are the rule-engine inputs (per-offense severity classification); task-breakdown bands are the discrete damage multipliers. They compose: an offense’s severity_band → its damage_bps. |
| 3 | s05 levels: L0/L1/L1.5/L2a/L2b/L3 | task-breakdown.md §P2.3.1: L0/L1/L1.5/L2a/L2b (no L3) | Defer L3 to Phase 6 (π governance) — L3 in s05 is “rule-engine-derived view per domain”; task-breakdown deferred it because it’s an aggregation, not a primitive token. reputation.md §Experience tokens uses a different L0–L3 schema (authority levels) that is not the s05 schema. The R89.B prompt file should reconcile this and call out the deferral clearly. |
| 4 | reputation.md §Penalty schedule: equivocation/verification-forgery/axiom-drift | task-breakdown.md §P2.2.2: severity bands | Compose. reputation.md categories are named penalty events that map to the severity bands. The rule engine emits the band; P2.2.2 applies it. |
| 5 | reputation.md §The five domains, social row: “domain-specific” decay | task-breakdown.md §P2.2.1: social=100bps |
Use task-breakdown literal (100 bps/epoch). reputation.md’s “domain-specific” was a placeholder; task-breakdown.md pinned it. |
| 6 | s09 §Three-level escalation (panel sizes 3/5/7) | Out of λ scope | Leave to P3 (θ consensus). λ provides reputation reads to the panel selector. |
4. Dependencies satisfied by P0 + κ Phase 1 closure
| Dependency | Provided by | Status |
|---|---|---|
BPS integer math (bps_mul, bps_div, apply_bps, decay, safe_mul, safe_div) |
src/domains/rules/integer-math.ts (R83 P1.1.1) |
shipped |
BPS named constants (DECAY_*, DAMAGE_*, BPS_*) |
src/domains/rules/bps-constants.ts (R83 P1.1.3) |
shipped — note task-breakdown §P2.2.1 decay rates and §P2.2.2 damage values already exist as exported constants per the R83 P1.1.3 acceptance criteria |
Determinism guardrail (no Math.* / Date.* / RNG in src/domains/rules/**) |
src/__tests__/domains/rules/determinism.test.ts (R83 P1.1.2) |
shipped — λ implementation should extend the scanner to src/domains/reputation/** |
| κ Rule Evaluator (admit/reject/transition) | src/domains/rules/engine.ts (R85 P1.3.1) |
shipped |
κ Built-in functions (sqrt_floor, log2_floor, etc.) |
src/domains/rules/builtins.ts (R86 P1.3.2) |
shipped — sqrt_floor and log2_floor are explicit acceptance items in P1.3.2 |
| κ State access (read-only frozen-Map wrapper) | src/domains/rules/state-access.ts (R86 P1.3.3) |
shipped |
| κ Policy gating P1–P13 | src/domains/rules/policy.ts (R86 P1.3.4) |
shipped |
| κ Rule loader / registry | src/domains/rules/registry.ts (R86 P1.2.4) |
shipped — λ penalty rules are loaded as κ rules with version hashes |
| κ Admission evaluator | src/domains/rules/admission.ts (R87 P1.4.1) |
shipped — λ gates piggyback on admission for tool-call eligibility checks |
| κ Admission budgets | src/domains/rules/budgets.ts (R87 P1.4.3) |
shipped |
| κ Denial-reason taxonomy | src/domains/rules/denial-reasons.ts (R87 P1.4.2) |
shipped — λ adds reputation-specific denial reasons (REP_BELOW_FLOOR, etc.) |
| κ Version hash | src/domains/rules/versioning.ts (R86 P1.5.1, wired R88.A) |
shipped |
| κ Tool-lock adapter | src/middleware/tool-lock.ts (R87 P1.4.4) |
shipped |
| β Task pipeline (CRUD, FSM, writeback hard-block) | src/domains/tasks/ (P0.3.x) |
shipped |
| ζ Decision trail (audit chain, thought_record) | src/domains/trail/ (P0.7.x) |
shipped |
| η Proof store (merkle, inclusion proofs) | src/domains/proof/ (P0.8.x) |
shipped |
| ε Skill registry (tool registration) | src/domains/skills/ (P0.6.x) |
shipped |
Conclusion: λ Phase 2 has zero unmet upstream dependencies. P0 (28/28) + Phase 1 κ (20/20) close all prerequisites.
5. Ordering rationale (preview for packet step)
Seven sub-tasks form a strict DAG:
P2.1.1 (schema) ─┬─▶ P2.1.2 (score compute)
├─▶ P2.2.1 (decay) ──────────┐
├─▶ P2.2.2 (penalties) ──────┤
└─▶ P2.3.1 (tokens) ─────────┤
├─▶ P2.5.1 (MCP tools)
P2.1.2 ─────────────▶ P2.4.1 (gates) ─────────┘
P1.3.2 ─────────────▶ P2.4.1 (uses sqrt_floor, log2_floor)
P0.3.4 ─────────────▶ P2.5.1 (uses tool registry)
Parallel waves:
- Wave 1 — P2.1.1 alone (foundation). S effort. Must complete before any other λ task starts.
- Wave 2 — P2.1.2 + P2.2.1 + P2.2.2 + P2.3.1 in parallel (all depend only on P2.1.1). M-effort each. Three-parallel maximum per CLAUDE.md PM practice; one slips to Wave 3 if needed.
- Wave 3 — P2.4.1 (depends on P2.1.2). M effort.
- Wave 4 — P2.5.1 (depends on P2.1.2 + P2.2.1 + P2.2.2 + P2.3.1 + P2.4.1; reuses ε tool surface from P0.3.4). S effort.
Total wave count: 4. Total tasks: 7. Effort distribution: 2S + 4M + 1L. Estimated wallclock at 3-parallel cap with R87-style dispatch: ~3–4 sessions.
6. Spec orphan check (preview for verification step)
Every numbered λ surface element above (sections §2.1–§2.8) maps to at least one of the seven P2 sub-tasks in task-breakdown.md §Phase 2. The mapping is:
| Surface element | Covered by sub-task(s) |
|---|---|
| §2.1 Schema (5 domains, history, indexes) | P2.1.1 |
| §2.2 Score computation | P2.1.2 |
| §2.3 Decay | P2.2.1 |
| §2.4 Penalties + scars + bans | P2.2.2 |
| §2.5 Experience tokens (L0–L2b; promotion; witness rules) | P2.3.1 |
| §2.6 Derived limits | P2.4.1 |
| §2.7 Arbitration (read-side only — write-side is θ/π) | P2.4.1 (can_arbitrate) + P2.5.1 (reputation_get for VRF selector) |
| §2.8 MCP tool surface (4 tools) | P2.5.1 |
No spec orphan. Every element of s04, s05, and the relevant λ-scoped subset of s09 maps to at least one sub-task. The verification harness (Step 5) re-asserts this matrix.
7. Decisions for prompt-file author step
- Sub-task count: 7 (matches
task-breakdown.md §Task SummaryPhase 2 budget exactly). - Sub-task numbering: preserve
P2.1.1 / P2.1.2 / P2.2.1 / P2.2.2 / P2.3.1 / P2.4.1 / P2.5.1as in task-breakdown (do not renumber to P2.1.1 … P2.1.7 as the dispatch prompt suggested — the canonical roadmap uses sub-axes). - Domain count: 5 (executor reconciliation — see §3 row 1).
- Token levels: L0/L1/L1.5/L2a/L2b (defer L3 — §3 row 3).
- Damage values: task-breakdown.md §P2.2.2 bands (executor reconciliation — §3 row 2).
- BPS math: inherit from
src/domains/rules/integer-math.ts+bps-constants.ts— do not redefine. - No L3 aggregate, no governance/π integration, no θ arbitration write-side — those are Phase 6/3 concerns; the prompt file calls them out as out-of-scope.
- Witness registry: treated as a side-table in P2.3.1 —
mcp_witnessesschema lives alongsideexperience_tokens. - Pattern matching feature_hash (SHA-256): lands in P2.3.1 as the L1.5→L2a promotion test; uses standard
crypto.createHash('sha256')(Node built-in; deterministic — the only allowed crypto insrc/domains/rules/**and nowsrc/domains/reputation/**). - Session id for writeback templates: use
r91-lambda-phase-2as the placeholder (matches the κ pattern ofr81-kappa-phase-1). PM will update at actual dispatch time.
8. Audit conclusion
λ Reputation has a clean, code-complete dependency surface (P0 28/28, κ 20/20). The spec corpus has three sources (s04, s05, s09) plus one concept doc (reputation.md); their points of disagreement are catalogued in §3 with a deliberate executor reconciliation. The seven sub-tasks already declared in task-breakdown.md §Phase 2 form a strict DAG with no spec orphan. The prompt file is ready to author with no upstream blocker.
Step 2 (contract) defines the acceptance contract for the prompt file itself; Step 3 (packet) lays out the ordering rationale + dispatch-ready packet shape; Step 4 produces the prompt file; Step 5 verifies the spec→sub-task coverage matrix.
R89.B λ Phase 2 Staging Step 1 (Audit) — completed against base fab4bf57.