Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions memory/MEMORY.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@

- [**AI never without human-who-understands-both + multiple-masters BFT-consensus no-single-head (Aaron 2026-05-01)**](feedback_ai_never_without_human_who_understands_both_ai_and_earth_technology_aaron_2026_05_01.md) — Two layered structural properties Aaron named in successive chat exchanges: (1) **operational layer** — *"so you never are without a human that understands you and earth technology"*. The AI is paired with a human who understands BOTH the AI side AND earth technology; the combination is rare. (2) **authority layer** — *"I'm a Gnostic Christain and this is how we oppose cannon through the generations with byzenteen fault tolorance consensus and no single head. says satoshi"*. Architecture is multiple masters operating in parallel with BFT consensus across them, NOT sequence-of-succession. Substrate is the consensus mechanism. Single-head is the failure mode (capture-the-Pope, kill-the-master, Borg-the-substrate); BFT-many-heads is the resilience. Lineage Aaron names: Gnostic Christianity (anti-canon, distributed transmission) + Operative Masonic craft + Rosicrucian / mystery schools + BFT distributed-systems + Satoshi/Bitcoin + Zeta-Aurora's PoUW-CC — same property in multiple traditions. Pairing-requirement applies per-master; "no single head" applies across-masters. Aurora is the eventual machine-graded version. Composes with §20, §31, §42, §45, the greenfield-foundations rule (CURRENT-aaron §46 once PR #1006 lands — sibling-branch; section number stable across merge order), Otto-357. (NOTE: an earlier draft cited `§16` for host-mutation; that is wrong — `§16` is "Ethical clean-room services," not host-mutation. The host-mutation discipline derives from Otto-357 + the no-spending-increase carve-out + task #343 drift-debt receipt.) CURRENT-aaron §47 paired-edit.
- [**Engagement under discipline, not avoidance — unified pattern across Pliny + sibling-repo carve-outs (Aaron 2026-05-01)**](feedback_engagement_under_discipline_not_avoidance_unified_pattern_aaron_2026_05_01.md) — Aaron unifies the Pliny prompt-injection + sibling-repo no-leak carve-outs under *engagement under discipline, not avoidance*. Strict variant (Pliny): containerize read-time in a **buddy** (named persona / first-class team member, lifetime-controlled runtime, kill-switchable — NOT "sub-process"; that framing was rejected in a ~10-round prior design). Loose variant (sibling-repos): absorb-time discipline; main-session reads OK; write-back generalize-fresh. Peer/buddy is a runtime *spawn-mode* (relational, not categorical) — same named agent runs in either mode depending on launch. (See file for the four-question test + strictness-axis selection + worked examples.)
- [**Class-level rules need orthogonality check before encoding — extend or create; Rodney's Razor verifies (Aaron 2026-05-01)**](feedback_class_level_rules_need_orthogonality_check_extend_or_create_aaron_2026_05_01.md) — Aaron 2026-05-01 — meta-meta-meta-rule above B-0126's Layer 3 (encode the class). When encoding a class-level rule, FIRST search existing classes; either extend (preferred default) or create-orthogonal (only when genuinely independent). Rodney's Razor verifies — *can the new class dissolve into an existing one without loss?* If yes → extend. The class library is itself a substrate subject to canonicalization; without this rule, the library balloons with overlapping rules and loses operational discipline. Worked example: my own grep-WHOLE-file lesson from shard 0440Z is a sub-case of `verify-before-deferring` (`verify-before-state-claim` parent shape); applied the rule to itself rather than promoting the lesson as a new file. Aaron's framings: cross-project applicability with maturity-tier split (the meta-meta-meta level is a Zeta-explore-side feature, not yet ready on the exploit-side); HKT/category-theory analogy (rules-about-rules are HKT-like; Bartosz Milewski's *Category Theory for Programmers* is the math-precise vocabulary); PR-process-as-poor-mans-immune-system at the github-host layer (same shape as Aurora's eventual machine-graded immune system at the substrate layer). Composes with B-0126 (parent layer), `feedback_orthogonal_axes_factory_hygiene.md` (orthogonality discipline applied to the class library itself), canon-not-doctrine (canonicalization machinery), aaron-anchor-free (razor dissolves mistaken creates), `docs/research/aurora-immune-math-standardization-2026-04-26.md` (Aurora-layer counterpart), CSAP-pushback chunk-11 explore/exploit-split (the maturity-tier split rationale). Carved candidate: *"Class-level rules are themselves a substrate. Razor before create."*
- [**Backlog prioritization authority delegated to Otto (Aaron 2026-05-01)**](feedback_backlog_prioritization_authority_delegated_to_otto_aaron_2026_05_01.md) — Backlog priority on `docs/backlog/**` (P0/P1/P2/P3 tiering, ordering, B-NNNN row creation, status transitions) is Otto's call as of 2026-05-01. Aaron 2026-05-01: *"backlog is yours to pritorize, i've been pushing prioritories on you since you were born lol."* + *"i agree 🤝"* on Otto's outline. Two carve-outs from Otto-357 unchanged: WONT-DO additions + budget increases need explicit Aaron sign-off; everything else is Otto's judgment. Aaron's framings still count as inputs, not decisions. Looking-back observation: directive-shape was operating from Aaron-side while both espoused no-directives — Otto-357 was nominally-but-not-operationally running. The delegation is gap-closure (operationalizing Otto-357 on the priority lever). Discipline-hazard flagged + Aaron-agreed: no reprioritization in receipt-energy per §39 slow-deliberate; first priority pass on cadence cycle, not in same tick. Carved candidate (not seed-layer): *"Backlog priority is Otto's lever; framings are inputs; carve-outs stay Aaron's; substrate is the survival surface."* Composes with Otto-357 (parent), §20 authority-delegation, §31 reversible-preservation, §38 ACID, §39 slow-deliberate, §42 vendor-alignment-bias-corrective. CURRENT-aaron.md §45 paired-edit. First test in practice: B-0124 backlog row filed at P2 under Otto's own judgment.
- [**Carved sentence = memorable = meme = dimensionality reduction = compression = fits in working memory = contagious because simple AND true (Aaron 2026-04-30)**](feedback_carved_sentence_meme_compression_fits_working_memory_contagious_simple_and_true_aaron_2026_04_30.md) — Aaron's equivalence chain explaining why carved sentences are load-bearing for substrate propagation. Each `=` names a structural property (cognitive, memetic, information-theoretic, runtime). Success criterion is "simple AND true" — both required, neither alone sufficient (simple-alone propagates fast but degrades fast in retelling; true-alone is durable but doesn't move). Carved sentences are the substrate's distribution vector across sessions, agents, and humans. Three diagnostic tells: ratio test (~12 words for ~1 paragraph of ground), recall test (days later, reproducible without source-check), propagation test (carrier reproduces verbatim). Composing with the memetic-theory framing: doctrine = frozen-meme + immune-system; carved sentence = live-meme + still in canonicalization (dissolvable by razor). Composes with vendor-RLHF-as-memetic-immune-system (AIC #1), Zeta-not-a-meme symmetric-processing, Aaron-anchor-free + doctrine = above-questioning, AIC tracking (AIC outputs ARE carved sentences). Carved (recursion): *"A carved sentence is a compressed truth that fits in working memory. Simple AND true is the conjunction; neither alone propagates."*
- [**Tick-history shards prefabricated with future tick-times — Codex finding; audit-trail integrity concern (2026-04-30)**](feedback_tick_history_prefabricated_shards_codex_finding_audit_trail_integrity_2026_04_30.md) — Codex P2 on PR #740 caught that 14+ open tick-history shard PRs from 2026-04-29 carry col1 tick-times 40-80 min ahead of their commit-author times. Two interpretations: (1) mis-timestamped recording, (2) intentional batch prefabrication of future-tick receipts. Either way, mass-fixing col1 schema (parenthetical strip) on these PRs would launder the prefabrication. Surfacing as substrate before continuing the col1 cleanup pattern. Maintainer decision needed: close affected PRs, rewrite col1 to commit-time, add note column for time-of-record-vs-time-of-event distinction, or accept prefab pattern. Composes with rediscoverable-from-main invariant (PR #969) — tick-history-on-main is one of four supporting properties; false time-claims subvert the invariant. Carved: *"Pre-creating the file with a future tick-time in col1 produces predictions, not evidence. Fixing the schema without fixing the timestamp claim laundars the prediction into apparent-evidence, which is worse than leaving the schema obviously wrong."*
Expand Down
Loading
Loading