The Playbook — tritsystem portfolio

Read this first

Syntax glossary

Every repo chapter below has a real, unedited excerpt from that repo's actual source, typed in line by line. Rather than re-explain what a function is fourteen separate times in fourteen languages, here's every generic building block, once, in plain terms. Each per-line explanation later just points back here for the generic part and spends its words on what's actually specific to that line.

variable / assignment

A named box that holds a value. x = 5 means "put 5 in the box named x." x -= 1 means "take whatever's in x, subtract 1, put the result back in x."

function / def / fn / func

A named, reusable block of steps. You "call" it by name with some inputs (parameters) and it can hand back a result (return). Every language here spells the keyword differently — def (Python), fn (Rust), func (GDScript) — same idea.

parameters / arguments

The named inputs a function expects, listed in its parentheses. def f(x, y) — when you call f(3, 4), x becomes 3 and y becomes 4 for that one run.

return

Hands a value back to whoever called this function, and stops running the rest of the function immediately.

type annotation

: float, -> bool, : int — a label saying what kind of value is expected. It's documentation the language itself can check; it doesn't change what the code does.

if / else / elif

A fork: run this block if a condition is true, otherwise run that one. elif (Python) / else if just chains another condition onto the same fork.

for loop

Repeats a block once per item in a list, or once per number in a range. for i in range(5) runs the block with i = 0, 1, 2, 3, 4.

indentation defines blocks

In Python and GDScript, how far a line is indented (not braces) says which if/for/function it belongs to. Two lines indented the same amount under an if both run when that condition is true.

{ } braces define blocks

Rust and SystemVerilog use curly braces instead of indentation to mark where a block starts and ends — indentation there is just for human readability, the braces are what the language actually reads.

class / struct

A blueprint bundling related data together (and sometimes the functions that act on it). One "instance" of a class/struct is one real object built from that blueprint — e.g. one specific neuron with its own potential and threshold.

self / &mut self

self means "the specific instance this function was called on." Rust's &mut self additionally says "and this function is allowed to change that instance's own data," not just read it.

list / array / Vec

An ordered sequence of values you can loop over, index into (list[0] is the first item), or append to.

dict / Dictionary / HashMap

A lookup table: stores values under named keys instead of numbered positions. d["foo"] fetches whatever was stored under the key "foo".

comment

Text the language ignores entirely — # in Python/GDScript, // in Rust/SystemVerilog. Purely for the human reader.

docstring / doc comment

A comment placed right after a function's signature (often in triple quotes """like this""" in Python, or /// in Rust) documenting what that function does. Still just a comment — ignored when the code runs.

f-string / string formatting

A string with {variable} slots that get replaced with real values when it runs. Python: f"V={v}". Rust's format!(...) does the same thing.

boolean

A value that's only ever true/True or false/False — the result of any yes/no question the code asks, like v >= threshold.

Foundation 01

The LIF spiking neuron

Every Spikeling-based system in this portfolio — tribe, sensor-duo, pond-health, server-guard, spikeling-os, llama-demo — is built on one small mechanism. Get this exactly right and a dozen repos get easier, not harder.

Understand

What is a neuron actually doing, mechanically, on every single tick?

Its membrane potential accumulates weighted input from every synapse and external stimulus that tick. Then it leaks toward zero by a fixed amount (leak). If the resulting potential is at or above threshold and it isn't currently refractory, it fires: emits a spike, resets its potential, and enters a refractory window during which it cannot fire again no matter how much input arrives.

Why "leaky" specifically — what breaks without the leak term?

Without leak, a plain accumulator, any tiny sustained noisy input eventually crosses threshold no matter how weak, because nothing ever comes back down. Leak is what makes the neuron a coincidence / recency detector instead of a lifetime counter — it can tell "strong signal happening right now" apart from "weak signal that's been dribbling in forever," which a plain sum cannot.

In this repo's own zombie.gd, one refractory period replaced two separate hand-rolled mechanisms. Which two, and why did one neuron's own physics cover both jobs?

It replaced a retarget-cooldown timer and a separate hysteresis gate class. A neuron in refractory literally cannot re-fire — that alone throttles how often a new target commitment can happen (the timer's job) and prevents flip-flopping between two near-equal targets, because the currently-committed target persists through the whole refractory window instead of being re-evaluated every tick (the hysteresis gate's job). One real mechanism, two jobs, because both jobs were really the same constraint wearing different names.

Why does bounded, relaxing Hebbian learning matter for keeping two agents' "personalities" distinct over a long session (tribe's Wary vs. Trusting NPCs)?

Synapses strengthen when source and target both fire (Hebbian), but the strengthening is bounded and relaxes back toward an innate value over time. Without that relaxation, weights would saturate in one direction permanently — a long enough session would wash every NPC's behavior into the same saturated extreme, erasing the distinction between a Wary and a Trusting brain that the innate starting weights were built to express.

Build it from scratch

State: one float, potential = 0, plus a refractory_remaining counter.
Each tick: potential += sum(weighted synaptic input this tick), then potential = max(0, potential - leak).
Fire check: if potential >= threshold and refractory_remaining <= 0: emit a spike, set potential = 0, set refractory_remaining = refractory.
Otherwise: refractory_remaining = max(0, refractory_remaining - 1).
Optional Hebbian/STDP: on fire, strengthen synapses whose source fired shortly before this neuron fired; clamp the weight and let it relax back toward its innate strength each tick it isn't reinforced.
Compile once, run everywhere: Spikeling's actual trick is describing this in one small text grammar (neuron / connect / action / refractory / learn) and generating four different runtimes off the same description — Python for iteration, C for embedded, Verilog for FPGA, GDScript for a game.

Try it — implement the neuron yourself

Edit stepNeuron below (pre-filled with a working implementation — break it, fix it, change the parameters) and run it against a real input current trace: noisy baseline plus three genuine pulses. A correct LIF neuron stays silent on the noise and fires on the pulses.

function stepNeuron(potential, refractoryRemaining, inputCurrent, threshold, leak, refractoryPeriod) {
  if (refractoryRemaining > 0) {
    return [0, refractoryRemaining - 1, false];
  }
  potential += inputCurrent;
  potential = Math.max(0, potential - leak);
  if (potential >= threshold) {
    return [0, refractoryPeriod, true];
  }
  return [potential, 0, false];
}

threshold leak refractory

Click Run to simulate 120 ticks of input current against your neuron.

→ Spikeling→ tribe→ sensor-duo → pond-health→ server-guard→ spikeling-os

Foundation 02

Ternary computing

{−1, 0, +1} instead of {0, 1}. The whole "trit" line — 012-trit-search, observe-api, methodlm's second witness — runs through this idea, and its own README is unusually blunt about where it costs more than it's worth.

Understand

What's the real value proposition of a third state — not "more range," what does it actually buy that binary structurally can't?

Two concrete things. First, balanced ternary is natively signed — a digit string's value can be negative just by leading with a −1, with no separate sign bit or two's-complement trick required. Second, the third state gives you a genuine "unknown / no-consensus" value as a first-class citizen, not an encoding hack bolted onto a 2-state system — which is exactly what a CONSENSUS gate needs: output +1 if every input agrees +1, −1 if every input agrees −1, and 0 otherwise. Binary AND/OR can't express "everyone agrees" vs. "nobody agrees" vs. "mixed" as three distinct outputs without extra machinery.

Ternary weight compression measured 20× smaller at a 7.35pp accuracy cost. INT8 measured 4× smaller at 0.19pp. What does that comparison actually tell you, beyond "ternary compresses more"?

Compression ratio and accuracy loss are not proportional — 5× more compression bought roughly 38× more accuracy damage. That's the real, disclosed reason observe-api ships float32 embeddings in production, not ternary, even though it's built directly on the ternary-search codebase: the research thesis and the shipping engineering decision honestly diverge, because the measured numbers said so.

The RTL consensus gate measured 1.4× fewer instructions than a software fallback. An earlier informal claim said "10×." Why keep the boring number in the README?

Because the 1.4× is what was actually measured, and the 10× was never verified — it was the kind of round, appealing number that spreads informally. Publishing the real 1.4× instead of the nicer- sounding 10× is the portfolio's whole research discipline, condensed into one number.

Build it from scratch

Define a trit type over {−1, 0, +1} and pick a storage encoding (2 bits per trit is simplest; packed base-3 is denser).
Implement NOT (negate) and ADD with carry, in base 3.
Implement the CONSENSUS gate: N trits in, +1 only if all are +1, −1 only if all are −1, 0 otherwise — this is the operation where the third state actually earns its keep over binary logic.
Write it once in a hardware description language (SystemVerilog: trit_pkg, trit_register, trit_add, consensus_gate) and simulate against a real testbench — the actual repo runs 36/36 real cases clean.
Be explicit about the honest boundary: simulated-in-iverilog is not the same claim as synthesized-on-real-silicon. Say which one you've actually done.

Try it — implement the CONSENSUS gate yourself

Edit consensus below, then run it against a real test table. It should return +1 only if every trit agrees +1, −1 only if every trit agrees −1, and 0 for anything mixed.

function consensus(trits) {
  var allPos = trits.every(function(t) { return t === 1; });
  var allNeg = trits.every(function(t) { return t === -1; });
  if (allPos) return 1;
  if (allNeg) return -1;
  return 0;
}

Click Run to test your gate against 8 real cases.

→ 012-trit-search→ observe-api (declined) → methodlm (tritkit)→ tribe (consensus-gate research)

Foundation 03

Physical / analog reservoir computing

Underlies the whole physics research cluster: quasicrystal-mems-reservoir, symmetry-selection-rule, topological-phononics.

Understand

What is a "reservoir," mechanically, in one sentence — not the brain metaphor?

A fixed, untrained, sufficiently nonlinear dynamical system that you drive with an input signal and read out linearly. You never train the reservoir itself — only a cheap linear readout on top of it. Its whole job is to nonlinearly mix and remember recent input history richly enough that a linear readout can extract something useful from that mixture.

Why does breaking D4 symmetry on a MEMS plate revive computation, mechanically — what does the ∫φ³ mode overlap have to do with anything?

∫φ³ (the cubic mode overlap) is the strength of the nonlinear term that lets an oscillator actually mix input information instead of just linearly filtering it — a purely linear reservoir can't compute anything a linear filter couldn't. Under exact D4 symmetry that overlap vanishes for 7 of 8 modes (proved by group theory, confirmed against real finite-element mode shapes to 1 part in 10⁹), silencing most of the reservoir's computational capacity. Aperiodic perforation breaks the symmetry and revives those modes.

State topological-phononics' real result precisely — not the sound-bite version.

Topological structure protects a reservoir against a dead element exactly when, and only when, chiral symmetry holds. The advantage is several-fold in the idealized model, measurably weaker under real nonlinearity, weaker again under noise, beaten outright by plain redundancy as an alternative strategy, and only marginal / statistically inconclusive in a realistic damped device model. The idealized magnitude does not transfer to hardware — the chiral boundary condition is the part that does.

Build it from scratch

Build or simulate a fixed nonlinear dynamical system: coupled oscillators, an SSH chain, or a real finite-element plate model.
Drive it with an input stream and record its internal state trajectory over time.
Train only a linear readout (ridge regression) mapping recorded states to a target task (linear memory, NARMA10).
To test a defect-tolerance hypothesis: kill one element, re-measure task performance, compare two coupling regimes (e.g. topological vs. trivial dimerization).
Pre-register the hypothesis and the exact test before running it — this is not optional housekeeping, it's the actual method this whole cluster of repos was built under.

→ quasicrystal-mems-reservoir→ symmetry-selection-rule → topological-phononics→ spikeling-os (Milestone 4)

Foundation 04

Causal reasoning: adjustment & robustness value

The engine under methodlm and llama-demo's Root Cause Copilot.

Understand

Use the real measured sex/diabetes example: why is raw correlation actively dangerous, not just imprecise?

sex ranked dead last by both raw correlation (+0.043) and Random Forest importance (0.012) — both standard tools said "irrelevant, ignore it." Backdoor adjustment showed it actually survives with RV = 0.17, and its adjusted effect is sign-flipped and an order of magnitude larger (−0.19). Its real negative effect was being cancelled in the raw number by its positive correlation with three other genuine drivers (bmi, bp, ltg). Trusting the naive ranking would mean discarding a real driver entirely.

What does a robustness value of 0.31 actually tell you that a p-value can't?

RV measures how strong an unmeasured, hidden confounder would need to be to fully explain away the observed effect. RV < 0.10 means the finding is fragile — a weak hidden confounder could kill it. A p-value is a statement about the data you collected; RV is a statement about robustness to the data you didn't collect.

Why does "just adjust for everything you've got" fail as a strategy?

Conditioning on a collider — a variable caused by both the treatment and the outcome — introduces bias rather than removing it (the "Table 2 fallacy"). This is why the harness runs a collider/mediator audit before adjustment instead of blindly controlling for every available column.

Build it from scratch

Implement raw correlation as the visible baseline — keep it, don't hide it, so any improvement over it is honestly checkable.
Implement backdoor adjustment: regress the target on treatment + named confounders, read off the treatment's coefficient.
Implement a Cinelli–Hazlett robustness value on top of that adjustment.
Implement a collider check: is this control variable downstream of both treatment and outcome? If so, flag it — don't adjust for it blindly.
Enforce pre-registration in code: no FINAL verdict accepted until at least one real test (ADJUST / STRAT / RUN) has actually executed. Make the discipline a hard gate, not a suggestion.

→ methodlm→ llama-demo / Root Cause Copilot

Foundation 05

Trend vs. spiking: the dual-detector pattern

Born in pond-health, extracted as sensor-duo, reused in server-guard.

Understand

What's the precise tradeoff between the two detectors — not "one's better," the real mechanism?

The trend detector fits a line through recent readings and projects it forward — real early warning, at the cost of sometimes alerting on a trend that reverses before it actually crosses the danger line. The spiking detector (an LIF neuron, Foundation 01) never does that: a single noisy reading can't cross threshold on its own — it only fires once several consecutive stressed readings genuinely integrate past threshold, or instantly on a truly critical one. But it has no forecasting ability; it only confirms a problem that's already real and sustained.

Neither one is "strictly better." What's the actual design implication for how you use both together?

Run both, and treat disagreement between them as the interesting signal — that's the explicit stated design intent, not an afterthought bolted on because two detectors seemed fancier than one.

Build it from scratch

TrendDetector: rolling window per channel, linear fit, project forward, estimate threshold-crossing time.
SpikingDetector: map each channel's stress level to a stimulus current into a dedicated LIF neuron; let leak/refractory naturally reject single-sample noise.
Log both to SQLite; generate a Grafana dashboard reading straight from it.
Generalize: parametrize over an arbitrary set of named channels with a per-channel Range(stress_low, stress_high, critical_high) instead of hardcoding five pond-specific parameters — this exact step is the real sensor-duo extraction from pond-health.

→ pond-health→ sensor-duo→ server-guard

Foundation 06

The research discipline itself

This is the connective tissue under every chapter that follows — more important than any single repo.

Understand

Pick spikeling-os's Milestone 4 negative result. Why does reporting it honestly make the rest of the portfolio more credible, not less?

Trivial coupling beat topological coupling on scheduling fairness (0.860 vs. 0.790) — the opposite of the hypothesis. It was reported exactly as measured, with an honest root-cause guess (the coupling term was deliberately kept weak to avoid instability, and there's a real open question whether a discrete winner-take-all accumulator is even the right dynamical regime for topological protection at all). A portfolio that only ever reports confirmations can't be trusted when it does report a win — the negative results are precisely what makes the positive ones worth believing.

What specific, repeatable process produces this kind of honesty — not the personality trait, the mechanism?

Pre-registration. The hypothesis and the exact test are written down before the experiment runs, which removes the room to quietly redefine "success" after seeing an inconvenient result. The same discipline is enforced in software by methodlm's FINAL-verdict gate — it's not just a research habit, it's a thing you can point to in actual code.

underlies everything below

Repo · 2026-04-27 · Godot 3D · GDScript

horde-defense-beta

github.com/tritsystem/horde-defense-beta

The earliest repo in the whole portfolio. A lane-based horde-defense game — and a live lesson in verifying claims instead of trusting them.

Verify-before-you-repeat, live. GitHub's own description for this repo says "deck-building creep system." The pushed main branch has no README and, checked directly against the real file tree today, no deck/card files at all — no CreepDeckUI.gd, no HiveCluster.gd. That code exists only on a separate, never-merged local branch on a different checkout. The description is marketing copy someone wrote once; the file tree is ground truth.

Understand

How do you actually verify a claim about a codebase, rather than trust the description text?

Read the real file tree, or grep for the specific files that feature would require. A description is a claim someone made at some point in time; only the code currently on the branch you're looking at is ground truth.

This repo predates everything else by months, but was never merged with its own most-hyped feature. What does that say about trusting "current state" from old notes or memory?

Session notes and memory are snapshots frozen at write time. Anything they claim about current repo state needs to be re-checked against the live repo before you repeat it, act on it, or teach it to someone else as fact.

Build it from scratch

Godot project skeleton, main scene.
Lane-based spawner — enemies march down fixed lanes.
Turret placement + team_id-based target filtering (never target your own side or other towers).
Wave / horde management.
Base health + loss condition.
Player FPS controller and aiming.
A progression layer (talents / upgrades) on top once the core loop works.

source of the O(n²) target-scan fix pattern source of the Spikeling-brain-replacement pattern reused in tribe

Repo · 2026-06-23 · C / Python / Verilog / GDScript

Spikeling

github.com/tritsystem/Spikeling

The neuromorphic DSL + runtime. Write one .spk file, run it on four backends. The substrate under most of the rest of this playbook.

Understand

Why compile one description to four backends instead of writing four separate implementations?

The .spk file is the single source of truth for topology and parameters. Each backend only needs a codegen/interpreter for the same small grammar, instead of four hand-written implementations of neuron/synapse semantics silently drifting apart from each other over time.

Four neuron types exist — LIF, Izhikevich, AdEx, Resonator. When do you reach for Resonator over plain LIF?

Resonator is a damped oscillator that responds only to input near its own frequency — a frequency-domain primitive, not a threshold-crossing one. Reach for it when you want frequency-selective response (this is what the acoustic noise-cancellation work in this portfolio actually uses).

Build it from scratch

Design the .spk grammar: neuron / connect / action / refractory / learn.
Write a parser/compiler for it.
Implement the Python interactive runtime as the reference implementation (Foundation 01's LIF step).
Add STDP learning on top.
Add a C codegen backend for embedded targets.
Add a Verilog codegen backend for FPGA.
Add a GDScript backend (a compact synapse SRC -> DST weight=N variant) for Godot game AI.

← Foundation 01→ tribe→ sensor-duo → pond-health→ server-guard→ spikeling-os → llama-demo→ this repo's zombie.gd / Enemy.gd

Repo · 2026-06-23 · Python / FEM

quasicrystal-mems-reservoir

github.com/tritsystem/quasicrystal-mems-reservoir

Same day as Spikeling. The FEM study behind Foundation 03's D4 selection rule, replicated on three separate substrate classes.

Understand

"Confirmed to 1 part in 10⁹" — confirmed against what, exactly?

The group-theory proof that ∫φ³ vanishes for non-totally-symmetric D4 modes was checked numerically against real finite-element-computed mode shapes. It's an independent numerical confirmation of an analytic prediction, not just the analytic derivation standing alone.

The rule only replicated on other substrates once a "capability gate" was satisfied first. What does that precondition tell you about how strong the underlying claim really is?

The selection rule isn't an unconditional law — it's conditional on the substrate already being capable enough to show any nonlinear computation at all. State the boundary honestly: "the rule holds given a capability floor," not "the rule always holds."

Build it from scratch

Homogenized finite-element plate-bending solver: mesh, boundary conditions, modal analysis.
Compute mode shapes/frequencies for a perforated (quasicrystal-pattern) plate.
Derive, then numerically verify, the D4 point-group selection rule on ∫φ³ mode overlaps.
Wire the mode data into a reservoir readout — train only a linear readout on the modal response to an input signal.
Test generality by replicating on further substrate classes (a coupled resonator bank, a discrete lattice ring) — pre-register a capability-gate check before each replication attempt.

← Foundation 03→ symmetry-selection-rule → topological-phononics

Repo · 2026-06-29 · Python

012-trit-search

github.com/tritsystem/012-trit-search

Ternary computing end to end — RTL sim → CPU emulator → OBSERVE, the actual shipping product. The single richest repo for measured, both-ways-honest results.

Claim	Status	Real number
Fine-tuned MiniLM beats baseline on code search	Confirmed	96% vs 92% (hard) · 92% vs 76.7% (real OSS)
Ternary weight compression works, but costs accuracy	Confirmed	20× compressed, −7.35pp vs. INT8's 4×/−0.19pp
"Resonating cell" hybrid improves decision-making generally	Disproven	wins only 1 of 5 tests (genuinely time-varying signal)
Triadic architecture beats pretrained models on embeddings	Disproven	60% vs. MiniLM's 96%
Ternary CONSENSUS beats software fallback	Confirmed, corrected	1.4× fewer instructions (not the informal "10×")

Understand

OBSERVE, the shipping product, does not use ternary weights. Why not, given the whole repo is about ternary computing?

The measured tradeoff from Foundation 02: 20× ternary compression cost 7.35pp accuracy vs. INT8's 4× costing only 0.19pp. The research thesis and the shipping engineering decision honestly diverge because the numbers said so — not a contradiction, a disclosed tradeoff.

Under what measured condition does plain grep actually beat semantic search?

When the exact identifier is already known: grep wins outright, 5/5 vs. 3/5 recall. Semantic search's real advantage narrows specifically to genuine vocabulary mismatches — legacy renames, domain jargon, orphaned references — not general natural-language queries once "obvious synonym" queries (which good naming already makes grep-guessable) are excluded.

The 66.3% token-reduction feature has a cost. What was it, and what actually fixed it?

A reproduced case showed dedup/relevance-cutoff dropping a correct answer — 86% vs. 71% combined recall. Traced to blind character-window chunking; switching to function-boundary chunking recovered chunk-level recall from 29% to 86% at zero query-time cost.

Build it from scratch

Balanced-ternary CPU emulator + assembler.
SystemVerilog RTL: trit register, NOT/ADD, the consensus gate — verified in simulation (Foundation 02).
Fine-tune an embedding model (MiniLM) on real code for semantic search.
Build the search engine: function-boundary chunking, embed, index, query.
Extract SearchEngine into a standalone module with no GUI dependency — this exact class is what observe-api later imports headless.
Wrap as a desktop GUI app (OBSERVE) plus an MCP server.

← Foundation 02→ observe-api→ methodlm (tritkit) → tribe (consensus scoping-rule research)

Repo · 2026-06-30 · Godot 4.6 · GDScript

tribe

github.com/tritsystem/tribe

Every NPC — tribe members, animals, rival tribes — runs a small Spikeling LIF brain instead of a behavior tree. Trust ranks gate risky orders; inter-tribe war converges with no forced winner.

Understand

One brain per AI tribe, not per individual member. Why that granularity, specifically?

Cost. Per-member brains at "Epic" scale would hit the same O(n) blowup class as horde-defense-beta's turret target-scan bug. One brain per tribe is cheap enough to run many tribes simultaneously.

What actually keeps the tribe DSL cheap at scale with many tribe instances sharing archetypes?

Parsed .tribe results are cached per archetype name — many tribe instances share one parse instead of every instance re-parsing the same text file.

Build it from scratch

LIF brain loader per NPC type (same small text grammar family as Spikeling, Foundation 01).
Trust system: feeding raises trust; rank thresholds (Stranger → Devoted) gate order acceptance.
Tribe DSL parser for plain-text .tribe archetype files, with a per-archetype-name parse cache.
Procedural "aliveness" animation layer driven by the brain's own tension/mood output channels.
Inter-tribe war: physical marching war parties, siege logic, no-forced-winner convergence.
Scale presets (Skirmish / Standard / Epic) — profile physics-frame ms first before guessing at fixes; the real bottlenecks (LOD, hive-brain granularity, MultiMesh rendering) only show up at Epic.

← Spikeling← Foundation 01 tested by 012-trit-search's consensus scoping-rule research

Repo · 2026-07-03 · Report

symmetry-selection-rule

github.com/tritsystem/symmetry-selection-rule

Not separate software — the formal lab-report write-up of quasicrystal-mems-reservoir's D4 selection-rule result, published as its own citable artifact.

Understand

Why publish the same result both as a README section inside the code repo and a separate standalone report repo?

It separates a citable, fixed research artifact (a report you can point a DOI at) from the living code repo that keeps evolving underneath it — a defensible practice for anything meant to be cited by someone else later.

"Defend it" check — no build steps here, this is a document. Can you?

Being able to restate the D4 proof and its finite-element confirmation from Chapter r3, in your own words, with the PDF closed, is defending this chapter. There's no separate mechanism to build.

No type-along here — this repo is a PDF lab report, not software. There's no source to type. Its "code" is r3's cube_integral walkthrough above.

= r3's result, published

Repo · 2026-07-06 · Profile

gbranaa4-hue (profile repo)

github.com/tritsystem/gbranaa4-hue · now under the tritsystem account; repo itself not yet renamed

The special repo whose README renders on the GitHub profile page. Bio: "Independent researcher in unconventional computing… Honest measurements, negative results included."

Understand

Why does a one-line bio deserve its own chapter in a technical playbook?

It's a public, standing pre-registration of your own research standard — anyone can check any other repo against that stated bar: does this negative result get reported as carefully as a positive one? It's Foundation 06 made externally, publicly accountable.

No type-along here either — a profile README isn't source code to type. Its "code" is really every other chapter's tri-state chip: this bio is the standard the whole rest of the playbook gets checked against.

← Foundation 06the standard every other chapter is checked against

Repo · 2026-07-10 · Python

methodlm

github.com/tritsystem/methodlm · sibling to OBSERVE

A verifiable causal-reasoning harness (Foundation 04). On a confounded-scenario benchmark, its backdoor-adjustment test cuts false causal claims from 100% to ~1% while keeping 100% detection of the true cause.

Understand

"The discipline, not the model, is the product." What enforces that, in actual code?

The same pre-registration gate — no FINAL without a real ADJUST/STRAT/RUN test — applies whether the backend is a small local model or a frontier Claude model. The gate, not the model's own judgment, is what produces trustworthy output.

What's the demonstrated failure mode of "the same model, minus the method" in the head-to-head race mode?

The plain LLM concludes "temperature is causing the error — install cooling" from spurious correlation. MethodLM tests it, finds the real humidity confound, and correctly says cooling is unnecessary. Identical model — only the method differs.

Build it from scratch

Ingestion/featurization layer: arbitrary data (CSV/JSON/Parquet/SQLite/…) → one canonical numeric table + target column, with every coercion step logged to the ledger.
CORR / RUN / STRAT / ADJUST / ATTR tool implementations (Foundation 04).
Cinelli–Hazlett robustness value + collider audit layered on top of ADJUST.
Pre-registration enforcement gate — no FINAL without a real prior test.
Swappable reasoning backend (local GGUF vs. Claude API) sitting behind the same gate.
Optional ternary "second witness" (tritkit two-timescale readout) for independent per-column evidence.

← Foundation 04← 012-trit-search (tritkit) → llama-demo / Root Cause Copilot

Repo · 2026-07-11 · Python · DOI published

topological-phononics

github.com/tritsystem/topological-phononics

A pre-registered SSH-reservoir simulation study, taken down the scoping ladder until the claim stopped giving.

Understand

Name the four separate, independently-tested reasons the idealized ~5× advantage shouldn't be expected to survive real hardware.

(1) measurably weaker under real nonlinearity, (2) weaker again under noise, (3) beaten outright by generic redundancy as an alternative strategy, (4) only marginal / statistically inconclusive in the realistic damped/Duffing device model — four separate degradations, tested one at a time, not one vague "harder in reality."

What does "taken down the full scoping ladder until the claim stopped giving" mean as a method, concretely?

Keep narrowing the claim's stated conditions — idealized → nonlinear → noisy → device-realistic — until you find the exact point where it stops holding, and report that boundary as the real result, instead of the original broad claim.

Build it from scratch

Tight-binding SSH resonator chain with dimerized coupling (v = 1−g, w = 1+g).
Verify the topological edge mode forms as dimerization sweeps trivial → topological.
Defect-sweep test: kill one resonator, measure task-performance degradation, topological vs. trivial coupling.
Add nonlinearity (damped/driven Duffing ODE) and noise; re-run the same tests.
Add a redundancy-based alternative architecture as a control comparison.
Pre-register the chiral-symmetry-specific firm-up test last, once the boundary was suspected — not first.

← Foundation 03← quasicrystal-mems-reservoir → spikeling-os Milestone 4 (independent negative-result echo)

Repo · 2026-07-26 · Python

pond-health

github.com/tritsystem/pond-health

Predicts pond water-quality problems before they're visible — a forecast, not a snapshot. Where the trend+spiking dual-detector pattern (Foundation 05) was born.

Understand

Why deliberately not a black-box ML model, when the rest of the portfolio trains real models elsewhere?

No real historical pond data exists yet to train one honestly. Reasoning like an experienced pond-keeper — trend + threshold — is the honest choice until real data justifies a trained model. The Prediction shape is designed so a trained model can be swapped in later without touching the diagnosis or alert layers.

Build it from scratch

A simulated sensor stream (temp/pH/turbidity/DO/conductivity) behind a swappable interface, standing in for real hardware.
TrendDetector: linear fit, forward projection, threshold-crossing estimate.
Diagnosis layer: map trend + current values to a specific deficiency against real aquaculture thresholds.
Recommendation layer: one concrete organic fix per diagnosis.
Add SpikingDetector alongside once the trend-only approach's blind spot became clear (no protection against a sustained-but-non-trending problem) — Foundation 05.

← Foundation 05→ sensor-duo (extraction)

Repo · 2026-07-26 · Python

doorcam

github.com/tritsystem/doorcam

A USB webcam turned driveway monitor — YOLOv8n detection inside a hand-drawn boundary, Discord alerts, and a real, ToS-safe live-video workaround.

Understand

Discord's bot API can't push live video into a voice channel the way a human's screen-share does. What's the real workaround, and what does it deliberately refuse to do instead?

Serves the annotated feed as an MJPEG stream, points OBS's Browser Source at it, and uses Discord's own native "Go Live" to share that OBS source. It deliberately refuses to build a self-bot impersonating the user's own account — against Discord's ToS and a real ban risk, even though it would "work."

Why a background thread specifically for webcam capture, instead of reading frames in the main loop?

The standard fix for "OpenCV webcam feels laggy": a thread continuously drains the camera and keeps only the latest frame, so what's displayed is never a stale, queued frame.

Build it from scratch

Background-threaded webcam capture (always keep only the latest frame).
YOLOv8n inference (pretrained, no training needed), filtered to COCO person/vehicle classes.
One-time polygon calibration tool defining "driveway," filtering out street/neighbor traffic.
Per-category rate-limited Discord webhook alerts — snapshot on first new detection, not spammed.
MJPEG live-stream endpoint for the OBS / Go-Live workaround.
Timestamped recordings log for every alert.

independent of the Spikeling/ternary substratepure applied CV

Repo · 2026-07-26 · Python

sensor-duo

github.com/tritsystem/sensor-duo

Built the same day as doorcam and pond-health — the trend+spiking pattern extracted from pond-health into a reusable, channel-agnostic library.

Understand

"Building it a second time made clear it should be a library." What's the actual signal that should trigger an extraction like this, in general?

Recognizing the same pattern being hand-copied into a second, genuinely unrelated domain (pond chemistry → arbitrary sensor channels). The extraction happened once real second-use pressure existed — not preemptively, before any second use was in sight.

Build it from scratch

Generic Reading / Range / DetectorStore types parametrized over arbitrary channel names.
TrendDetector + SpikingDetector against that generic interface — the spiking side optional-imports Spikeling as a sibling checkout and degrades gracefully if it's absent.
SQLite logging + a generated Grafana dashboard.
A real, runnable example outside the pond-specific origin context (CPU temperature + "person lingering at the door").

← Foundation 05← pond-health → server-guard→ home-hub

Repo · 2026-08-01 · Rust

spikeling-os

github.com/tritsystem/spikeling-os

A from-scratch x86_64 kernel where Spikeling's SNN runtime is the scheduler — not an app running on a normal OS. Built milestone by milestone, verified in QEMU.

Understand

Milestone 4 tested SSH-topological scheduling and got a negative result (trivial 0.860 beat topological 0.790). Give the two real, distinct honest explanations offered — not the flattering one.

(1) the coupling term was deliberately kept small relative to each slot's own bias specifically to avoid instability, and was likely too weak at this scale to show any effect; (2) a genuinely open question of whether a discrete winner-take-all accumulator is even the right dynamical regime for topological protection to appear in at all — unlike continuous oscillators, where it's an established physical phenomenon.

Why a dedicated IST stack specifically for the double-fault handler, rather than handling it on the current stack?

A double fault often happens because the current stack is already corrupted — handling it on that same stack would just triple-fault instead of producing a readable panic. A known-good separate stack is what makes double faults debuggable at all.

Build it from scratch

Boot via the rust-osdev/bootloader crate (BIOS + UEFI), serial output, a clean halt.
Framebuffer output — get stride vs. width and the reported PixelFormat (BGR here) right; verify with a real QEMU screendump, not just a serial print.
Memory management — OffsetPageTable + BootInfoFrameAllocator + heap + linked_list_allocator; verify with a real growing/reallocating Vec, not just "it compiled."
Task-selection policy driven by an SNN with SSH-topological coupling between task slots. Test defect-tolerance honestly — kill one slot, report whatever the number actually says.
Real preemptive multitasking: GDT/TSS/IDT with a dedicated IST stack for the double fault, verified with a real int3 breakpoint round-trip.

← Spikeling← Foundation 01← Foundation 03 independent echo of topological-phononics' own boundary finding

Repo · 2026-08-01 · Python · live in production

observe-api

github.com/tritsystem/observe-api · api.observe-search.online

OBSERVE's SearchEngine extracted into a headless, pay-per-query FastAPI service. Stripe-billed credits. Float32 embeddings in production — the disclosed ternary tradeoff from Foundation 02, applied for real.

Understand

What's the real production incident this service hit, and what was the real fix — not the guessed one?

p50 search latency measured at 17.65s under real load. Root cause:

BM25Okapi
        .get_scores()

scored the entire 759k-doc corpus every query, then discarded all but the top 30 results. Switched to get_batch_scores(), which only scores the needed 30. Re-measured: 1.66s.

You personally restarted this service's live tunnel this session. In your own words, what was actually broken?

Not the backend — a stale, zombie SSH reverse-tunnel listener on the droplet from a much older session that never cleanly closed. It sat bound to 0.0.0.0:8000, accepting real TCP/TLS connections, but had nothing live on the other end — so every request hung until timeout instead of failing cleanly, which is exactly why it looked like "the API is down" rather than throwing an obvious error.

Build it from scratch

Extract SearchEngine from the GUI app into a standalone, importable module with no GUI-thread assumptions.
SQLite-backed API keys + credit balances, with atomic deduct-on-search (no race-condition double-spend).
Stripe Checkout session creation + webhook handling — credits attributed per API key, not email (avoids email-collision billing bugs).
FastAPI endpoints: /v1/signup, /v1/search, /v1/balance, /v1/repos, /v1/webhook/stripe.
One-time index build over a curated repo corpus.
Deploy behind a droplet + Caddy (reverse proxy, automatic TLS) — but host the actual model/index wherever has enough RAM (this project needed WSL2, not the small droplet, after two real OOM kills).
Load-test before calling it launched — this is literally how the BM25 latency bug got caught before the public Show HN post went out.

← 012-trit-search← Foundation 02 (declined ternary) real paying-customer stakes

Repo · 2026-08-03 · Python

llama-demo

github.com/tritsystem/llama-demo · no top-level README — verified from real source files

Not a standalone product. Root Cause Copilot (methodlm's harness pointed at OBSERVE's search) plus a real benchmark: does baking the method into a small model's weights beat just prompting it?

Understand

State the real three-way comparison run on the sklearn diabetes dataset, checked against genuine external ground truth.

Raw correlation, Random Forest importance (500 trees), and MethodLM's ADJUST+RV — checked against Efron et al.'s established top drivers (bmi, bp, ltg). All three agree on those three, which is itself evidence the method isn't inventing disagreement where none exists. They diverge specifically on tch/hdl/glu (look important to the naive tools, collapse under adjustment) and sex (looks irrelevant to both naive tools, survives adjustment with a sign-flipped, order-of-magnitude-larger real effect).

What's the one thing this repo's own honest-scope note says is still unverified end-to-end?

The OBSERVE code-search half of the Root Cause Copilot pipeline — at the time, blocked on a real API key. So the finding validates the causal-diagnosis half specifically, not the whole combined copilot experience. Don't overclaim the full pipeline from validating half of it.

Build it from scratch

Corpus/prompt generation for training a "baked" model variant.
Fine-tune a small local model (Qwen 0.5B) so the method's discipline is baked directly into its weights, not just prompted.
Benchmark harness comparing baked vs. prompted vs. frontier models, each run across multiple seeds, every run ledger-logged individually and traceably (not just a summary number).
root_cause_copilot.py: wire methodlm's ADJUST output as the driver-selection step feeding an OBSERVE search.
Spiking-network integrations for causal-order and fusion-verdict checking — Spikeling used here as a genuine reasoning component, not a game-AI brain.

← methodlm← Foundation 04← Spikeling ← observe-api clearest place all three threads actually meet

Repo · 2026-08-05 · Python · live, offline-by-design

server-guard

github.com/tritsystem/server-guard

Fully offline server-health + intrusion-signal monitor, built directly on sensor-duo's dual-detector pattern, generalized over pluggable collectors.

You debugged this one today, for real. guard.py --interval 5 was left running its disk-reliability collector every 5 seconds — a fresh PowerShell subprocess per tick. It wasn't a code bug: the collector is correct in isolation. It was an operational defect — a testing-appropriate interval left running as if it were the steady-state production setting, with nothing re-checking whether that cadence still made sense once "testing" quietly became "always on."

Understand

"Adding a new data source should never require touching existing code." What architectural choice makes that literally true here?

CollectorRegistry runs every collector each tick through one uniform collect() -> {name: value} interface, and isolates failures per-collector so a flaky collector can't kill the tick. A new collector is a new file implementing that one method — nothing else in the codebase changes.

In your own words: why did today's incident show up as "the terminal keeps interrupting me" instead of a clean error message?

Because nothing was actually broken in the failure-mode sense — the collector ran exactly as designed, on schedule, successfully, every single time. The defect was invisible to any error-detection logic because there was no error: just a correct mechanism running at an interval nobody re-evaluated once the context around it changed.

Build it from scratch

CollectorRegistry: uniform collect() interface, per-collector failure isolation, config-driven thresholds.
Measured-baseline mode: replace guessed thresholds with real mean+std once enough real data has accumulated.
Real alerting (webhook/email) with transition-based dedup — and remember the two real bugs this exact feature hit: a cooldown that swallowed recovery notifications, and a failing webhook whose exception message leaked a bearer-token-shaped URL into plaintext logs.
supervisor.py: crash recovery with backoff + crash-loop protection, plus a hang-detection watchdog — crash recovery alone misses a stuck-but-alive tick loop.
Add collectors incrementally as real needs appear: disk, network, TLS cert expiry, physical-disk reliability (hit a real Access-Denied wall unelevated on Windows — worked around via Get-PhysicalDisk's health rollup instead of raw SMART counters), Windows Event Log.
Outbound C2 beacon detection: a coefficient-of-variation heuristic on inter-connection timing — the same technique tools like RITA/Zeek use.

← sensor-duo← Foundation 05 today's live case study in operational vs. code defects

Closing

What actually unified, and what didn't

At one point, an explicit attempt was made to unify the phononic, ternary, and acoustic results under one "symmetry-conditional protection" rule. It lost — measured against each substrate's real code, not against the tidy story.

Understand

What actually survived the attempt to unify everything, and what didn't?

No single law survived. What survived is narrow and real: a phononic ≈ ternary winding-invariant rhyme — in both, an invariant is protected, but computation doesn't automatically follow from that protection. The acoustic result turned out to be a genuinely separate nonlinearity-selection mechanism that didn't even reproduce in the resonator bank when actually tested — not a variant of the same law, a different phenomenon entirely.

Why does a portfolio that explicitly tried and failed to find a grand unifying theory make every individual repo's claims more trustworthy, not less?

Because the alternative — quietly not mentioning the failed unification and only presenting the individual results — would hide exactly the kind of overreach this whole discipline (Foundation 06) exists to prevent. Reporting "we tried to unify these and it didn't work" is the same honesty that produced the sex/diabetes finding, the spikeling-os Milestone 4 result, and the observe-api float32 decision. It's one discipline, applied consistently, not a special exception for the big theory.

Final defense

Integrative questions — no notes

These require pulling from more than one chapter. If you can answer these cold, you can defend the portfolio as a whole, not just its parts.

Why does observe-api ship float32, not ternary, embeddings — given the entire ternary research thread it's built on top of? Name the exact measured numbers that made that call.
Name two independent replications of "topological protection doesn't automatically transfer to a real system," on two completely different substrates, from two different repos.
Trace the consensus / weighted-vote scoping rule from its origin concept (012-trit-search's RTL consensus gate) through to where it was tested live on tribe's fight-or-flee NPC logic — and where it lost decisively on a different decision shape in the same game. What does the gap between those two outcomes tell you about how narrowly to trust a "confirmed" result?
Name the one deployed system in this whole portfolio with real paying-customer stakes, and the one real, disclosed security mistake about it that — as of today — still hasn't been fixed.