backlog: P3 KSK naming definition doc (Amara 16th-ferry actionable)#318
Merged
backlog: P3 KSK naming definition doc (Amara 16th-ferry actionable)#318
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Amara 16th-ferry GPT-5.5 Thinking observation: 'KSK' has multiple possible meanings across the factory (DNSSEC Key Signing Key; Kinetic Safeguard Kernel / trust-anchor; ceremony + root-of-trust + governance key). Needs a canonical docs/definitions/KSK.md that says 'In this project, KSK means X. Inspired by Y, not identical to Y.' Requires Max + Aaron coordination per Otto-77 (lucent-ksk repo attribution) + Otto-90 (cross-repo rule). Otto drafts; Max + Aaron approve. P3 convenience; S+S effort. Composes with Otto-108 single-team-until-interfaces-harden. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
AceHack
force-pushed
the
backlog/ksk-naming-definition-doc
branch
from
4e97820 to
8ace7a1
Compare
There was a problem hiding this comment.
Pull request overview
Adds a new BACKLOG entry to stabilize the meaning of “KSK” in the Zeta project by proposing a canonical definition document.
Changes:
- Add a P2 BACKLOG checkbox item proposing
docs/definitions/KSK.mdand outlining intended scope and coordination notes.
|
|
||
| ## P2 — research-grade | ||
|
|
||
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. |
There was a problem hiding this comment.
P1: This item is placed under the “## P2 — research-grade” section, but the text later says “Priority P3 convenience”. Either move it to the P3 section or align the stated priority so backlog categorization stays consistent.
Suggested change
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. | |
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P2 research-grade; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. |
|
|
||
| ## P2 — research-grade | ||
|
|
||
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. |
There was a problem hiding this comment.
P1: The “Coordination required… Max + Aaron approve before it lands” phrasing appears to conflict with the Otto-90 guidance that Aaron/Max are not coordination gates (explicit ask only if a specific input is needed). Consider rewording this to match Otto-90 (e.g., notify / optional review, explicit ask for specific questions) rather than requiring approval.
Suggested change
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. | |
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination:** notify Max for Otto-77 attribution context and notify Aaron for Otto-90 cross-repo alignment; request review only if a specific attribution or cross-repo question needs input. Otto drafts and lands once those questions, if any, are resolved. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. |
|
|
||
| ## P2 — research-grade | ||
|
|
||
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. |
There was a problem hiding this comment.
P1: Cross-reference integrity: this line claims KSK is referenced across “5th / 7th / 12th / 14th / 16th ferries” and proposes “cross-refs to 5 ferries”, but in-tree there’s a 7th-ferry doc, while 12th/14th are only mentioned as pending elsewhere and a 16th-ferry doc isn’t present. Suggest either linking concrete existing paths/PRs or marking which of these ferries/docs are pending/not yet landed to avoid misleading readers.
Suggested change
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory references KSK across 5th / 7th / 12th / 14th / 16th ferries + Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to 5 ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. | |
| - [ ] **KSK naming definition doc — `docs/definitions/KSK.md` to stabilize what "KSK" means in this project.** Amara 2026-04-24 (16th courier ferry, GPT-5.5 Thinking): *"'KSK' has multiple possible meanings in your ecosystem: DNSSEC-style Key Signing Key, your emerging Kinetic Safeguard Kernel / trust-anchor idea, maybe broader 'ceremony + root-of-trust + governance key' structure. That ambiguity is not fatal, but it needs a repo doc that says: 'In this project, KSK means X. It is inspired by Y, but not identical to Y.' Otherwise future readers will get confused."* Factory discussion of KSK spans 5th / 7th / 12th / 14th / 16th ferry materials, but some of those references are pending or not yet landed in-tree; also see Otto-77 Max `lucent-ksk` repo attribution. Proposed doc scope: (1) "In this project, KSK means..." definitional anchor; (2) "Inspired by..." (DNSSEC / DNSCrypt / threshold-sig ceremonies); (3) "NOT identical to..." (e.g., DNSSEC KSK signs zone-keys; Zeta KSK is about governance/consent quorum); (4) cross-refs to landed ferry docs plus explicit TODOs/placeholders for pending ferries elaborating the architecture; (5) relationship to Max's `lucent-ksk` — the term may already have canonical meaning there which Zeta respects. **Coordination required:** Max per Otto-77 attribution + Aaron per Otto-90 cross-repo rule. Otto drafts; Max + Aaron approve before it lands. Priority P3 convenience; effort S (doc) + S (cross-repo coordination). Composes with Otto-108 single-team-until-interfaces-harden guidance. |
AceHack
added a commit
that referenced
this pull request
Apr 24, 2026
…ns tracked; 3 already shipped) (#330) * ferry: Amara 17th absorb — Cartel-Lab Implementation Closure + 5.5 Verification (8 corrections tracked) Two-part ferry: Amara's deep-research Implementation Closure for Cartel-Lab + her own GPT-5.5 Thinking verification pass with 8 load-bearing corrections. Otto correction-pass status (all 8 tracked): 1. λ₁(K₃) = 2 — ALREADY CORRECT PR #321 Otto-127 (independent convergence before verification arrived) 2. Modularity relational-not-absolute — ALREADY CORRECT PR #324 Otto-128 (caught mid-tick via hand-calc) 3. Cohesion/Exclusivity/Conductance replace entropy-collapse — SHIPPED PR #329 Otto-135 (3 primitives + 6 tests) 4. Windowed stake covariance acceleration — FUTURE GRADUATION 5. Event-stream → phase pipeline for PLV — FUTURE GRADUATION 6. 'ZSet invertible' → 'deltas support retractions' — ADR ALREADY PHRASED CORRECTLY (PR #316 never claimed full invertibility) 7. KSK 'contract' → 'policy layer' — FILED BACKLOG PR #318 Otto-124 (Max coord pending) 8. SOTA humility — DOC PHRASING (applied in new absorb docs) Amara's proposed 3-PR split NOT adopted (Otto-105 small- graduation cadence; content delivered across 7 ticks instead: PRs #317, #321, #323, #324, #326, #328, #329). Amara's proposed /cartel-lab/ folder NOT adopted (Otto-108 Conway's-Law: single-module-tree until interfaces harden). Current Graph.fs + test-support split works. Aaron's SharderInfoTheoreticTests flake flag (trailing Otto-132 note) filed as BACKLOG PR #327 Otto-133 — unrelated hygiene item. Amara's Otto-136 follow-up note: '#323 conceptually accepted, do not canonicalize until sharder test is seed-locked/ recalibrated'. Acknowledged — #323 lives in tests/Simulation/ already (test-scoped); 'canonicalize' = future promotion to src/Core/NetworkIntegrity/ per Amara's PR #3 split suggestion; that's gated on #327 completion. §33 archive header compliance. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * lint: fix line-start PR-number header false-positive in 17th-ferry absorb --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
AceHack
added a commit
that referenced
this pull request
Apr 24, 2026
…correction) (#332) Completes the input pipeline for TemporalCoordinationDetection. phaseLockingValue (PR #298): PLV expects phases in radians but didn't prescribe how events become phases. This ship fills the gap. 17th graduation under Otto-105 cadence. Addresses Amara 17th-ferry Part 2 correction #5: 'Without phase construction, PLV is just a word.' Surface (2 pure functions): - PhaseExtraction.epochPhase : double -> double[] -> double[] Periodic-epoch phase. φ(t) = 2π · (t mod period) / period. Suited to consensus-protocol events with fixed cadence (slot duration, heartbeat, epoch boundary). - PhaseExtraction.interEventPhase : double[] -> double[] -> double[] Circular phase between consecutive events. For sample t in [t_k, t_{k+1}), phase = 2π · (t - t_k) / (t_{k+1} - t_k). Suited to irregular event-driven streams. Both return double[] of phase values in [0, 2π) radians. Empty output on degenerate inputs (no exception). eventTimes assumed sorted ascending; samples outside the event range get 0 phase (callers filter to interior if they care). Hilbert-transform analytic-signal approach (Amara's Option B) deferred — needs FFT support which Zeta doesn't currently ship. Future graduation when signal-processing substrate lands. Tests (12, all passing): epochPhase: - t=0 → phase 0 - t=period/2 → phase π - wraps cleanly at period boundary - handles negative sample times correctly - returns empty on invalid period (≤0) or empty samples interEventPhase: - empty on <2 events or empty samples - phase 0 at start of first interval - phase π at midpoint - adapts to varying interval lengths (O(log n) binary search for bracketing interval) - returns 0 before first and after last event (edge cases) Composition with phaseLockingValue: - Two nodes with identical epochPhase period → PLV = 1 (synchronized) - Two nodes with same period but constant offset → PLV = 1 (perfect phase locking at non-zero offset is still locking) This composes the full firefly-synchronization detection pipeline end-to-end for event-driven validator streams: validator event times → PhaseExtraction → phaseLockingValue → temporal-coordination-detection signal 5 of 8 Amara 17th-ferry corrections now shipped: #1 λ₁(K₃)=2 ✓ already correct (PR #321) #2 modularity relational ✓ already correct (PR #324) #3 cohesion/exclusivity/conductance ✓ shipped (PR #331) #4 windowed stake covariance ✓ shipped (PR #331) #5 event-stream → phase pipeline ✓ THIS SHIP Remaining: #4 robust-z-score composite variant (future); #6 ADR phrasing (already correct); #7 KSK naming (BACKLOG #318 awaiting Max coord); #8 SOTA humility (doc-phrasing discipline). Build: 0 Warning / 0 Error. Provenance: - Concept: Aaron firefly-synchronization design - Formalization: Amara 17th-ferry correction #5 with 3-option menu (epoch / Hilbert / circular) - Implementation: Otto (17th graduation; options A + C shipped, Hilbert deferred) Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
AceHack
added a commit
that referenced
this pull request
Apr 24, 2026
…18th graduation (Amara #4 robust) Two ships consolidated per the 'parallel PRs hit positional conflicts on tail-append' lesson: 1. RobustStats.robustZScore (baseline: double seq) -> (measurement: double) -> double option Returns (measurement - median) / (1.4826 · MAD). The 1.4826 constant scales MAD to be consistent with Gaussian stddev. MadFloor prevents blow-up when every baseline value equal. 2. Graph.coordinationRiskScoreRobust alpha beta eigenTol eigenIter lpIter (baselineLambdas: double seq) (baselineQs: double seq) (attacked: Graph<'N>) -> double option Upgrades coordinationRiskScore (PR #328) from raw linear differences to robust-standardized z-scores per Amara 17th-ferry correction #4. Caller provides baseline metric distributions; Z-scores calibrate thresholds from data. Why robust z-scores: adversarial data isn't normally distributed. An attacker can poison a ~normal distribution by adding a few outliers that inflate stddev, making subsequent real attacks look 'within one sigma'. Median+MAD survives ~50% adversarial outliers. Standard move in robust statistics literature; Amara's correction puts it on the Zeta composite. Tests (5 new; total 39 since main hasn't merged #331/#332 yet): - robustZScore None on empty baseline - robustZScore of measurement = median is 0 - robustZScore scales MAD by 1.4826 for Gaussian consistency (measurement 4 on baseline [1..5] ≈ 0.674) - coordinationRiskScoreRobust fires strongly on K4-injected graph given 5 baseline samples - coordinationRiskScoreRobust returns None on empty baselines BACKLOG rows added this tick per Aaron Otto-139 directives: 1. Signal-processing primitives (FFT + Hilbert) — unblocks Amara correction #5 Option B; Aaron standing-approval 2. F# DSL for entry points + graph-query-language standards compliance (Cypher / GQL / Gremlin / SPARQL / Datalog) 3. LINQ-compatible entry points for C# consumers — pair with F# DSL; two frontends, one algebraic backend 6 of 8 Amara 17th-ferry corrections now shipped or confirmed: Remaining: #6 ADR phrasing (already fine); #7 KSK naming (BACKLOG #318 Max coord pending); #8 SOTA humility (doc-phrasing discipline ongoing). Build: 0 Warning / 0 Error. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
AceHack
added a commit
that referenced
this pull request
Apr 24, 2026
…mara #4 robust) + 3 BACKLOG rows (#333) * core: RobustStats.robustZScore + Graph.coordinationRiskScoreRobust — 18th graduation (Amara #4 robust) Two ships consolidated per the 'parallel PRs hit positional conflicts on tail-append' lesson: 1. RobustStats.robustZScore (baseline: double seq) -> (measurement: double) -> double option Returns (measurement - median) / (1.4826 · MAD). The 1.4826 constant scales MAD to be consistent with Gaussian stddev. MadFloor prevents blow-up when every baseline value equal. 2. Graph.coordinationRiskScoreRobust alpha beta eigenTol eigenIter lpIter (baselineLambdas: double seq) (baselineQs: double seq) (attacked: Graph<'N>) -> double option Upgrades coordinationRiskScore (PR #328) from raw linear differences to robust-standardized z-scores per Amara 17th-ferry correction #4. Caller provides baseline metric distributions; Z-scores calibrate thresholds from data. Why robust z-scores: adversarial data isn't normally distributed. An attacker can poison a ~normal distribution by adding a few outliers that inflate stddev, making subsequent real attacks look 'within one sigma'. Median+MAD survives ~50% adversarial outliers. Standard move in robust statistics literature; Amara's correction puts it on the Zeta composite. Tests (5 new; total 39 since main hasn't merged #331/#332 yet): - robustZScore None on empty baseline - robustZScore of measurement = median is 0 - robustZScore scales MAD by 1.4826 for Gaussian consistency (measurement 4 on baseline [1..5] ≈ 0.674) - coordinationRiskScoreRobust fires strongly on K4-injected graph given 5 baseline samples - coordinationRiskScoreRobust returns None on empty baselines BACKLOG rows added this tick per Aaron Otto-139 directives: 1. Signal-processing primitives (FFT + Hilbert) — unblocks Amara correction #5 Option B; Aaron standing-approval 2. F# DSL for entry points + graph-query-language standards compliance (Cypher / GQL / Gremlin / SPARQL / Datalog) 3. LINQ-compatible entry points for C# consumers — pair with F# DSL; two frontends, one algebraic backend 6 of 8 Amara 17th-ferry corrections now shipped or confirmed: Remaining: #6 ADR phrasing (already fine); #7 KSK naming (BACKLOG #318 Max coord pending); #8 SOTA humility (doc-phrasing discipline ongoing). Build: 0 Warning / 0 Error. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(#333): 4 review-thread P1/P2s on robustZScore + coordinationRiskScoreRobust Active PR-resolve-loop on #333. 1. Doc/impl contradiction on MAD=0 (thread 59VhYb, P1): RobustStats.robustZScore doc said "returns None when MAD(baseline)=0" but impl uses MadFloor and returns Some finite value. Rewrote doc to match impl: explicit "MadFloor substituted when MAD collapses to zero" — floor reflects "scale is below epsilon" not "undefined." Implementation is the contract. 2. Multi-enumeration of baseline seq (thread 59VhYq, P1): robustZScore previously passed `baseline` to both `median` + `mad` which each call `Seq.toArray`. Expensive AND inconsistent for lazy/non-repeatable sequences (different values between enumerations = undefined behavior). Fixed: `Seq.toArray` once at entry, pass the materialized array to both. O(n) instead of O(2n); stable across lazy sources. 3. Name attribution in Graph.fs doc comment (thread 59VhY5, P1): "Amara 17th-ferry... Otto 18th graduation" → "external AI collaborator's 17th courier ferry... Eighteenth graduation under the Otto-105 cadence." Role-reference convention per AGENT-BEST-PRACTICES code/doc rule. 4. Array-vs-seq terminology (thread 59VhZG, P2): Graph.fs doc said callers "provide arrays" but the API is `double seq`. Rewrote: sequences + noted the materialize-once optimization in robustZScore so callers can pass any seq form without re-enumeration cost. Thread 59VhX9 (P3-label-in-P2-section mismatch) — already resolved on main via PR #341 which landed the signal- processing row correctly labeled "P2 research-grade." No fix needed on this branch. Build: 0 Warning(s) / 0 Error(s). 53 RobustStats + Graph tests pass. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Amara 16th-ferry (GPT-5.5 Thinking) actionable: stabilize 'KSK' naming with canonical definition doc. Max + Aaron coordination required before doc drafting proceeds.
🤖 Generated with Claude Code