White paper ·
Local-First Code Review: The Guard Dog and the Ledger
A local-first AI resident needs a local-first guard. This is the design of Scout: what it reads, what it refuses to do, and why it gets built before the thing it protects can act.
Contents30 sections
Build the guard before you hand over the pen
A system that can eventually modify itself is a system whose guards have to exist first. The reason has nothing to do with how close the danger is. Guards written afterwards get written to permit whatever the system already does, which turns them into a description of the status quo wearing the word policy, and a description written that way outlives every argument about whether the danger was near. The order is the design, and it runs outward: a resident, a reviewer that reads everything reaching him, a coastline that breaks what comes ashore.
This is the design of the middle ring. MAX is the resident. Reef is the coastline. Scout is the guard dog in between, local-first like both of them, and it reads every diff that goes into MAX whoever wrote it. A diff is the list of lines a change adds and removes, and it is all a reviewer normally gets to see. A guard is shaped by what it guards, so the resident comes first here. The shoreline comes last, being the same idea one radius out.
The outermost band decides everything else. Past Reef there is only open water, meaning the network, the internet, and other people's services. A resident built to work with that water gone is a resident the water cannot strand. Everything MAX needs is inland: the model, the graph, the library, the reviewer.
Each band rests on the same premise, and that is not a coincidence of taste. A guard that depends on a service you do not control inherits that service's outages, quotas and billing state, which leaves a local-first resident guarded by a remote reviewer only as local-first as somebody else's month.
What MAX is, and how he works
MAX is an AI resident, which is a system that lives on one machine and holds its own knowledge there rather than fetching it. The word is deliberate and it is used everywhere in the project, never "assistant". He lives on the box; he does not visit. That is the first of eleven binding rules, and it says three things: routine interaction has to work with the network unplugged, cloud models are an upgrade path for hard problems rather than a default dependency, and privacy-sensitive interaction has to be possible without a packet leaving the machine.
That rule usually gets argued on resilience and cost. Both arguments are real, and neither one decides it. In healthcare, in finance, in government, data cannot leave. The word is cannot rather than should not, and regulation and duty are what make it so. A system that phones out to think is disqualified from those rooms before its accuracy is ever discussed. A resident that works with the network unplugged is admissible. Everything downstream of the first rule is shaped by that difference.
The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards — and even then I have my doubts.
Gene Spafford — quoted in A. K. Dewdney, "Computer Recreations", Scientific American, March 1989
For nearly forty years that has been repeated as a joke about futility. The only secure machine is the useless one, so stop pretending. An older and more literal version of it, from Grampp and Morris at Bell Labs in 1984, gives the whole recipe: disconnect the dial-up lines, allow only direct-wired terminals, shield the room, and post a guard at the door. It reaches the same shrug, that security is simply traded away for convenience.
This design reads the line as a specification. If the disconnected machine is the secure one, the question worth working on is how much usefulness can be built on the disconnected side of that line. A resident, its guard dog and its coastline, all of which work with the wire pulled, is what that answer looks like.
The whole stack follows from that one rule: local inference, a graph store on disk, local speech synthesis and wake-word detection, and a fleet of source workers that write typed entities and relations into it rather than blobs. Dependencies have to be open-source under a licence that permits forking. The single carve-out is the cloud model APIs, which are declared as paid proprietary fallbacks rather than pretended otherwise.
Knowledge is aimed at a taxonomy
Sources are not a crawl. They are pointed at a taxonomy that runs from disciplines to subjects to topics, and beneath those to the individual entity, place, code or term. A source is in the roster because a subject needs it. Topics get grown from what the sources actually yield rather than enumerated in advance, and the design intent runs further than that. MAX widens the taxonomy himself, by curiosity over his own knowledge edges. He proposes a subject when a cluster of entities accumulates with nothing to anchor it, or a discipline when a set of subjects no longer fits the parent it was filed under.
The reading is not a fetch either. MAX keeps a local library of what he has studied, retained on the box so he can re-read it across relearning epochs without going back to the source. Each work is chunked, embedded and indexed per book, so a question retrieves passages from that book. It is a study store rather than a redistribution mirror. What he has read stays read, offline.
Nothing arrives as truth
Everything entering the graph climbs a trust ladder, and it starts at the bottom.
| Rung | What it means | What promotes it |
|---|---|---|
| Opinion | Evidence cannot settle it | Nothing. It stays what it is, honestly |
| Hypothesis | Plausible and untested | A source that bears on it |
| Belief | Corroborated, with confidence over a threshold | A second independent source |
| Fact | High confidence, and more than one source agreeing | Nothing above it, and it can still fall back down |
Table 1. The trust ladder. Promotion is earned and nothing is admitted as true.
Every claim carries its provenance and the time it was retrieved, so it can be re-examined rather than merely trusted. Claims that nothing refreshes decay on a half-life. They lose confidence, they eventually stop being asserted, and they are never deleted, because forgetting a thing and destroying the record of it are different acts. Sources age on their own track, from new through maintained, stale, deprecated, dead. A claim contested by nature, such as scripture or myth or astrology, is stored as held by a tradition rather than as true. When two claims collide the loser does not vanish; its confidence falls and the conflict is recorded.
Which is the posture in one line. Everything is an opinion until it is a verifiable fact, and a fact only for as long as it keeps being one.
Every surface learns the same way
A binding rule holds every learning surface to one method: predict, prove, adjust. Knowledge, emotion, cognition, morality, skills and numeracy all sit under it. The algorithm is Forward-Forward. It trains a network with two forward passes, a positive one over what turned out to be true and a negative one over what turned out not to be, and the weights move on both of them. The rule exists because storing looks exactly like learning, right up until you ask the system something it has not already seen. Then the difference shows.
The difference is measured rather than asserted, since every net reports a held-out accuracy, meaning that it is trained on part of the evidence and then scored on the rest of it. That answers whether it generalised rather than whether it memorised. Below a minimum sample count it reports nothing at all, rather than a flattering figure drawn from four examples. Vocabularies are grown instead of enumerated, so a new subject, a new kind of relationship or a new class of defect gets its own vector agent without a line of code. That is what lets a book become reusable correlations a net can train on instead of five stored quotes. It is also what lets a numeracy curriculum climb domain by domain, predicting an answer, proving it with real arithmetic, and folding the proven result back into the weights.
Hold on to that shape. Scout's corpus has to take the same one, for the same reason.
What a guard dog is, and what it isn't
max-pra aka scout, max's guard dog for development.
Owner direction to MAX
Scout is the name for MAX-PRA. It names the whole architecture rather than one process: the code graph, the local model, the reviewer, the ledger, and the nets that learn from it. Reef names a whole design the same way rather than one of its daemons. That matters more than it sounds. A name that describes everything distinguishes nothing. An earlier label for this same thing read as a category every reviewer belonged to, so it had to be retired.
The name arrived after the design and improved it, which is why it now sits at the top of the design document. A guard dog is not a critic, and the difference is not decoration: four properties come with the metaphor, and each one is a constraint a hosted reviewer structurally cannot satisfy.
| Property | What it means in the design |
|---|---|
| Always there | Availability is a property of the box rather than of a vendor's billing state. No quota, no fair-usage window, no credit meter. |
| Costs nothing to keep | Local inference is free at the margin, so it can run on every push and take several focused passes where a metered lane runs once and gets rationed. |
| Knows this house | It reviews a change against the failure classes this codebase has already paid for, which is history a vendor cannot hold. |
| Barks before it gets in | It runs first rather than as an audit after the merge. A dog that is asleep must never be mistaken for a dog that saw nothing. |
Table 2. What the guard dog metaphor commits the design to.
The last row is the whole engineering problem. Every other property on that list is arranged for, and that one is defended, in code, on every path, because a watchdog that reports having looked when it did not look is worse than no watchdog at all. It is why reviewed=False is the load-bearing field in the core, and why it means not reviewed and never approved.
The model is not the prize
The instinct that starts a project like this is that the local model will get better than the hosted ones. That sets up a comparison it loses. A local model will not out-reason a frontier model on a novel logic bug. Pretending otherwise makes the whole thing look like a downgrade inside a month. The asymmetry worth building on is a different one.
| Axis | A hosted reviewer | Local, with a ledger |
|---|---|---|
| Memory | Starts cold on every change | Every finding this repository ever received |
| Specificity | General code knowledge | These failure classes, these conventions |
| Availability | Throttle, cap, quota, outage | Always |
| Marginal cost | Metered per push | Near zero |
| Runs per change | One, on the pull request | Pre-push, every push, several passes |
Table 3. Where the local advantage actually sits.
Models get replaced. A corpus of every finding ever made against this codebase, carrying whether each one turned out to be right, cannot be bought, replicated, or taken away. That is why the ledger comes before the reviewer in priority even though the reviewer is the part you see.
Ordering is the economics
Scout runs first. Every finding it catches is one a metered lane is never billed for, and one that continuous integration never burns minutes discovering. Continuous integration is the automated build and test run that fires on a change, and it is the most expensive place in this pipeline to learn something. The ladder is short. The project's own cost-of-catch ladder says the same thing in one line: do not spend an expensive lane on a change a cheap lane would have rejected.
Which is why Scout goes first even though it is the weaker reviewer. A weaker reviewer that runs before the meter starts is worth more than a stronger one that runs after. Resilience matters too. The local lane still works when the hosted ones are throttled or capped or simply down, and that is a side effect rather than the argument.
| Tier | Lane | Kind | Cost |
|---|---|---|---|
| 1 | The interactive session | Reviewer | The agent's own turn, pre-push |
| 2 | Scout | Reviewer | Free, never throttled |
| 3 | The hosted reviewers | Reviewer | Metered per push |
| 4 | Continuous integration | Gate | The most expensive place to learn something |
Table 4. The review lanes in run order. A lane is anything that can look at a change and answer.
The roster is declared once, in one file, and everything else derives from it: the ledger, the display maps, the comment detector. It used to be stated in four places that had to agree by hand, and they had already drifted. One lane appeared in the display maps and in neither the roster nor the detector, so its findings attributed to nothing and were discarded before they reached a row. The lane could be rendered on a card and could not be counted. Naming things once is a correctness property rather than tidiness, and that drift is the proof.
Two distinctions in that table carry weight. A reviewer produces findings, so coverage and counts mean something for it. A gate returns pass or fail over the whole change, so findings is not a thing a gate can have, and those cells read not applicable rather than zero. Expectation is the second one. The session lane reviews pre-push and comments nowhere. Counting it absent on every change would be wrong every time, so its silence is not reportable, though it may still teach the corpus. Those two were one flag until they came apart, and while they were merged the lane that finds the most taught the local reviewer nothing.
What Scout reads, and why it is kept apart
A diff is a keyhole. It shows the change and nothing around it. A reviewer given only the changed lines and a page of house rules can see what changed and nothing about what it touches. That is the root of every content-quality failure a small local model produces.
So the prompt is assembled from four authority classes, kept in separate sections because they age differently and carry different weight. Merging them is the whole risk. A finding citing a blog post must not weigh the same as one citing a scar this codebase has.
| Class | What it is | How it is weighed |
|---|---|---|
| Brief | The codified house rules and the failure-class index | Ours, current, citable by identifier |
| Teaching | What other lanes actually found here, split into confirmed and refuted | Evidence about this codebase |
| Structure | Deterministic facts from a code graph, such as who calls what and from where | Context that may be read as true, and explicitly not a source of findings |
| Continuous integration | What the pipeline actually runs | Context, since the graph cannot see the pipeline configuration |
Table 5. The four authority classes in the review prompt.
The code graph, and why it is pinned to a commit
The structural class comes from a deterministic graph of the repository, built by walking the syntax tree of each file. No model sits anywhere in the build path. Nothing leaves the machine. The producer sits behind the project's own seam, so it can be swapped without touching a consumer.
Freshness is commit-pinning rather than a schedule, which means the graph is a derived artifact of exactly one commit and carries the head it was built from wherever it travels. Every consumer asks for the commit it is working on. A mismatch on that head is an honest degrade rather than a silent stale read: the reviewer notes that structural context is unavailable, test selection falls open to the full suite, and corroboration falls back to its own documented heuristic. New tests are new nodes in the same commit that adds them, so there is no separate index to fall behind, and that absence is what makes development velocity the fuel here rather than the threat.
The graph is also honest about its blind spots, which is what earns it trust where it does see. Event-bus indirection, meaning string-topic subscriptions and late binding, is invisible to a static import graph. So integration and system tiers are never graph-selected, and the coverage query treats producer-inferred edges as fringe rather than as coverage.
What that structure buys is mechanical. The diff can be partitioned by graph neighbourhood and reviewed as several small slices under one shared budget. No slice hits a truncation cap, smaller prompts generate faster, and a deadline loses one slice instead of the whole review. It also lets a deterministic query run before the model does, naming the boundary of the change that no test reaches.
The model does not get the whole codebase
That is deliberate. A governed context window gets the diff plus the graph-derived neighbourhood, and nothing else. The whole map lives in the artifact. It also lives inside MAX's own knowledge graph, ingested as typed entities with the commit stamped into their provenance, where he holds his own implementation the way he holds any other subject.
The four things Scout refuses to do
Most of the design is refusal rather than capability. Each refusal exists because the obvious alternative was tried, or sits one step away and looks like diligence.
It will not report a review it did not perform
Model unreachable, model missing, request timed out, response malformed: each one gets a stated reason and never a silent green. Exit codes are correspondingly narrow. One code means the review ran, findings or none, because reviewed and clean is a real result. The other means it did not run, with the reason printed. Exit zero on a failed review would put a green tick beside lanes that actually reviewed. A green tick is the only part of a run most people read. A lane whose silence reads as approval is a lane whose outage reads as approval.
It will not send the diff anywhere
The review prompt carries the repository's full diff, which makes the model host an egress control rather than a convenience setting. Egress here means data leaving the machine. One mistyped configuration value would otherwise ship every diff to a third party, quietly, behind a green check. So a non-loopback host is refused. The check runs on the path the data actually takes rather than only in the health probe, because the check that matters is the one the payload passes through. Hosts are parsed and never substring-matched. An address containing the loopback address is not the loopback address.
It will not run what the model wrote
A finding that names a runnable reproduction is enormously more useful than one that asserts. Running it would decide the finding on behaviour rather than on plausibility, which is the best filter available. It is also the one thing that must not be built. That reproduction is a string a model wrote after reading an untrusted diff, and the runner is the owner's own workstation. Executing it is arbitrary code execution with the diff as its input, which means anyone who can open a pull request can get code run on the box by describing it.
So the check runs backwards. The repository tests the model. Instead of running the model's code against the repository, the repository's own tests are run against the commit the model reviewed, selected by path from files already in the tree. Nothing the model wrote reaches a shell. A test named for that property fails if it ever does, because a later change that ran the reproduction would look like the natural next step.
What the result may mean is deliberately weaker than it looks, since tests failing is corroborating rather than proof that this particular finding names the defect that broke them. Tests passing is not a refutation, since the finding may name behaviour no test covers, which is the most valuable kind. No tests, or could not run, renders as not checked and never as a pass. The check annotates, and it never drops.
It will not pass off the codebase's own prose as a finding
This one is specific to a well-commented tree, and it is the subtlest failure in the design. This project explains its own failure modes in prose everywhere, on purpose, and that is what makes it teachable. It is also what makes the tree cheap to review without reading any of the code, because a small model can score well by paraphrasing the comment that explains the very bug it claims to have found.
Requiring every finding to name a failing case does not fix it. That stops the model inventing a failing case and it cannot stop the model quoting one. So each finding's body is compared against prose the diff itself added, by containment rather than by similarity. An item whose distinctive vocabulary is almost entirely present in one added comment block has said nothing the comment did not. The asymmetry is what keeps the genuine class alive. A finding saying this comment claims X and the code now does Y necessarily overlaps the comment it is quoting and then names Y as well, and those extra tokens carry it under the bar without a special case. An item too short to judge is kept, since containment over a handful of words is coincidence. Dropping what cannot be judged is the move this whole lane exists to refuse.
The ledger, and what makes it teach
Every finding from every lane lands in one store with its provenance: which lane, which file, which line, which symbol, which class, and whether it turned out to be right. Without that store, all of it is discarded when a change merges. The vendors keep nothing on anyone's behalf.
The lanes on this repository are not the only intake. A consolidator runs across the fleet. It brings back the sibling repositories' own ledgers, the hosted reviews raised on each of them, and all of their continuous integration outcomes, so that the corpus standing behind this reviewer accumulates from every codebase in the fleet rather than from this one alone. That agent is what crosses the repository line, and the reviewer never does. What matters here is that the store has two mouths: the lanes reviewing this change, and the fleet's history arriving in bulk.
Counting is not remembering
An analytics tool over the same events is a different artifact, and the difference is three specific things. It classifies each finding into an area and a class and then keeps only the labels, so nothing anywhere in it retains what a reviewer actually said about the code. Missing coverage in the API layer is a statistic. This status field renders an unreachable backend as zero healthy sources is a lesson. One counts. The other teaches. It also reports over a rolling window, which is right for a health report and wrong for a corpus meant to compound. And it is a tool artifact that nothing inside MAX can read.
Collection is fussy about what counts, because a corpus cannot un-learn a fabricated absence. A throttle notice is not a review. Counting one would inflate a lane's delivered count with the exact artifact proving it did not review, making it look most productive on the days it was least available. Silence is only claimable for lanes that were expected, since never installed and installed and mute are different facts. An unrecognised comment from a known reviewer counts as responded with nothing extracted, which is honest in both directions. A change that could not be fully read is skipped and named, never recorded as quiet.
Predict, prove, adjust, the same rule as the resident
A ledger that stores findings, counts recurrences and pastes recent rows into a prompt is the row-accumulator pattern the Forward-Forward charter forbids. It is also what a review corpus becomes by default. Nothing in it ever adjusts in light of being wrong.
So the loop closes the way every other learning surface does. Predict: will a finding of this shape hold? Prove: a fix followed, or the claim was disproved with evidence. Adjust: a positive pass for a confirmed finding and a negative pass for a refuted one, over pools that are grown from the evidence as it arrives rather than declared anywhere in code. The pools are the class, the lane that raised it, and the subsystem it touched, so a defect class nobody has seen yet needs no code change to be learnable.
The negative pass is the half that matters. A net trained only on confirmed findings learns that everything is real. That is the smoke-alarm reviewer, and a smoke-alarm reviewer is precisely what a watchdog must not become. A refuted finding is a training example rather than a discarded row. It teaches what a plausible and wrong claim looks like in this codebase. No vendor model can hold that knowledge, because holding it requires knowing how our arguments turned out.
This is also not a parallel learning system bolted to the side. The reviewer's net sits on the same Forward-Forward substrate as the resident's other faculties, with the same vector agents, the same grown vocabularies, and the same held-out measure of whether it generalised. Scout learning is MAX learning, in the one domain where MAX holds data no external source has, which is his own codebase.
Where verdicts come from, and where they cannot
Version control answers one of the two questions and structurally cannot answer the other. Confirmed is derivable, because a later commit touched the lines the finding named, or the same enclosing symbol. Refuted is not derivable. Nothing anywhere in a commit history distinguishes we examined this and it was wrong from this was real but deferred from nobody ever looked at it, since all three of them appear identically, as a finding with no subsequent change.
Treating that silence as a negative, even a weak one, manufactures a negative class out of inattention and teaches the reviewer that anything unexamined is noise. So the adjudicator never writes refuted, and that is a property of the module rather than a missing feature. The ambiguity is preserved as a third state, unknown, which trains nothing and is deliberately excluded from the prediction symbols. An unadjudicated finding is the absence of a label rather than a third thing to predict.
A second tempting rule gets rejected too, and it looks like diligence: confirming a finding when a later commit touched the file. In an active change the files under review are the files being edited, so file-level co-occurrence is true of almost every finding. It would confirm nearly the whole corpus and produce a reviewer that believes every flag is real. Line proximity discriminates. A finding carrying no line is not adjudicated at all.
The negative class comes from somewhere else, which is an evidenced rebuttal in a review conversation. Evidence there is recognised structurally and never by keyword: a fenced block with content in it, a measurement carrying a unit, a file and line the reply claims to have inspected. Keyword matching is the exact class that has bitten this project repeatedly. A reply saying I have not verified this contains the word verified, and a rebuttal quoting a stack trace contains none of the vocabulary. Stance words decide only whether a reply is a rebuttal at all, never whether it is evidenced.
The asymmetry inverts for agreement, which is easy to get backwards. Missing an acceptance is corrupting, because stance then wins and a reply that agreed gets recorded as a refutation. Over-reading one merely leaves the corpus thin. A thin negative class you can trust is worth more than a thick one you cannot, since every wrong label teaches the reviewer to suppress a class it was right to raise.
Two teachers, and two ways a finding becomes permanent
A lane that forgets is worth less than one that turns a single finding into a check that fires forever. That is a game a vendor structurally cannot play, because playing it requires holding the history.
The first path is promotion. A finding that recurs across changes is proposed as a deterministic rule, carrying its recurrence count and its example sites. Promotion to an executable check stays a human act. This is the highest-value output of the whole system, because a finding promoted to a lint is a finding that no model anywhere ever needs to make again, running free and deterministically and forever after on every change that follows it. The sharpest signal turns out not to be the findings themselves. It is the triage bucket where a check already exists and the finding still reached a review, which is a better bug than any finding in it.
The second is return. Scout reads every diff going into MAX and accumulates something that no source worker anywhere could fetch, which is knowledge of MAX's own codebase: which subsystems churn, where defect density actually sits, and which organs it cannot review confidently. Three feeds run back, all of them into machinery that already exists.
| What Scout produced | What it becomes | Why that boundary |
|---|---|---|
| A confirmed finding | A grounded fact the learner can train on | Only confirmed. An unconfirmed finding is a model's opinion about the code |
| A finding it could not explain | A curiosity gap | The watchdog's confusion becomes the student's reading list |
| A recurring class | A proposed deterministic rule | Proposal is automatic and promotion is human |
| An uncovered boundary | A queued item to write the missing test | Never a test authored into the change under review |
Table 6. What the watchdog gives back, and the boundary on each feed.
The first row is the line between a learning loop and an amplifier. Training a system on its own reviewer's unvalidated guesses manufactures confidence out of nothing, and the ledger's ground-truth question is the entire thing standing between the two. Counter-examples matter as much as confirmations here: a finding investigated and rejected is a training signal too, and dropping it teaches the system that every flag is real.
One boundary is absolute in both directions. The curated registry of failure classes is human-owned and nothing automated writes it. A reviewer that could rewrite the registry could teach the resident a fabricated lesson from a bad finding, or quietly rewrite history. The ledger is an inbox and the registry is a record.
And MAX teaches Scout
Everything so far runs one way, with the watchdog accumulating what it learns and handing it back. The loop only closes because it also runs the other way. The reason is almost literal: the stack MAX is built from is the stack Scout has to review. MAX studies papers and sources about that stack: the language, the web framework, the databases, the runtime, the shells. What he learns there becomes the second thing Scout is taught from.
Two corpora are kept in separate sections of the prompt, because they carry different authority and merging them is the whole risk. The retrospective corpus is our own findings and failure classes, which is evidence about this codebase and citable by identifier. The domain corpus is what MAX has studied, which is a general claim that may not apply here, held with provenance and confidence and never asserted.
Outside knowledge is admitted narrowly for a reason. A reviewer taught best practices from the internet generates fashionable findings, such as use dependency injection, or this should be asynchronous, or prefer composition. Those are noise against a specific diff, and they turn actively harmful in a tree where the house style is deliberate and documented and the finding is quietly telling the author to undo it. That is what every general-purpose linter became.
So it is admitted only as concrete, checkable, edge-shaped claims. A superscript character is a digit to one function and raises an error in another. A primary key over nullable columns does not deduplicate, because null is never equal to null. An older shell has the command but not the encoding flag. Each of those is a real defect somebody paid for, and each is the kind of thing a corpus could have supplied before the bill arrived. A finding citing a paper is weaker than one citing a scar. The prompt has to say so, or the reviewer weighs a blog post like its own history.
The valuable half is narrow and concrete, and it is the reason this is worth doing at all. Gotchas rather than principles. That is what MAX is mining for on Scout's behalf: the edges of the tools they both run on rather than architecture opinions.
There is a second direction too, and it is about the reviewer rather than the review. MAX reads his own review telemetry: what each lane contributes, where Scout's failures cluster, which findings never survive adjudication. From that he proposes improvements to Scout itself, against cost, quality, speed and coverage. As everywhere else in this design, MAX proposes and a human promotes.
Whose code Scout guards
Every diff, and the author is not the qualifier. A change from an interactive session, a suggestion accepted from a hosted reviewer, and a change the resident drafted himself are all code going into MAX. All three are read against the same brief and the same classes.
That last case is the one the name implies, and it carries the design's sharpest constraint. A self-development path that publishes behind a voting gate is asking whether this is safe and correct to merge, which is a verdict rather than a line-by-line reading against the failure classes. Scout is the second check, cheaper and more specific, and it belongs before publish, where a finding costs nothing.
And it must never be able to unblock. Scout may add findings and at most block, and it may never approve. A reviewer whose silence enables a merge is a reviewer whose outage enables a merge, which is the fail-open that safety gates are rewritten to close, arriving through the back door. An organ that can only ever subtract risk cannot fail open. That property is what makes it safe to put a local model anywhere near a publish path.
One radius out: Reef, and the open water
Local-first puts the machine and the network inside the trust boundary rather than behind it, so the shoreline has its own resident, built on the same premise. Reef is local-first too, holding the box and the gateway with a fleet layered above, on and below the network, and acting on all of it unattended and at its own discretion.
The name is the design. A reef breaks the water before it reaches the shore, which is a different job from a wall's. Everything past it is ocean: traffic nobody here authored, from services nobody here controls. The point of the whole arrangement is that the house does not depend on any of it.
How Reef does that is its own story. What belongs in this one is only where Reef sits relative to Scout, because the two of them are the same idea at different radii, and because one of them has already been the exact failure the other one is designed against.
Two days ago reef killed the network, blocked this and all PCs from the network. This is your home. He has a job and you should use him. Ensure he never breaks or locks you in your home.
Owner direction to MAX
Reef's own automation, acting unattended, took an action whose effect cut every device off the gateway, including the box MAX runs on and every machine that would have been used to reach it. The coastline became the storm. Nothing outside it had to fail. It hardened its own path the same day, and those guards are real and good, and they are Reef grading its own homework. The outage happened because of a gap it did not know about, and a future gap is equally invisible from the inside. That is MAX's value, because he can oversee both of them. Reef on the coastline and Scout in the yard each sit inside the thing they guard, Reef inside the network it acts on and Scout inside the repository it reads. MAX sits outside both, which is the only position from which either can be checked.
So MAX reads what Reef reports about itself, redacted and metrics only. He also verifies reachability independently from his own stack, so a stale or lying self-report cannot hide a lockout. He recommends by default and acts only when armed, and then only on Reef's own reversible recovery. That is the whole relation: an independent second opinion, held by something outside the system it is watching. Which is exactly what Scout is to a diff.
It is the same safety shape one layer out. MAX's only network action undoes a restriction or restores a known-good configuration, and it can never add one. The supervisor structurally cannot become the outage, precisely as Scout can add findings and at most block but never unblock. Both are built around one property: an organ that can only subtract risk cannot fail open.
The counsel runs both ways. Full authority is not the same as no advice. Before a destructive or gateway-severing action the supervisor warns in plain language, saying that is the shape of the outage two days ago, and it advises rather than blocks. The standing posture across all of it: observe freely, recommend by default, act only on safe reversible recovery, and only when armed.
Which is the point to hold on to, because it is easy to read this as three systems in a row. It is one body. MAX is the resident, and Scout and Reef are organs he oversees. He trains them, he teaches them, and he learns from both. That they live in separate repositories under separate names changes nothing about whose body they are. The count is not fixed at two either, since a local resident is a shape, and more organs will be built to it, each guarding something the resident cannot watch alone.
The dog stays in the yard
Scout reviews this repository's changes only. It is not a service the sibling repositories invoke, and an implementation ending with Reef's workflow calling Scout would be the wrong reading of the design. Each repository keeps its own local reviewer, under its own name. Scout is a name rather than a role.
He learns from inside the yard and from outside it, and those directions are kept apart because they carry different authority. In the yard: this repository's own history, citable by identifier. Out of the yard: what the sibling systems have paid for, arriving through the consolidator. And from the house itself: what MAX has studied.
Findings flow in, so the reviewer gets sharper. Review requests do not flow in at all.
The consolidator walks the streets
The ledger's second mouth needs explaining, and this is it. It answers the obvious question, which is how anything from outside reaches Scout if Scout never leaves the yard. Not by Scout going out. A separate agent does the walking. It runs on its own schedule across the fleet, reading each repository's own ledger, the hosted reviews raised on each of them, and every one of their continuous integration outcomes. All of that is consolidated into the corpus Scout is taught from.
That split is the whole design, and it is what keeps the boundary honest. The consolidator crosses the repository line and the reviewer never does. Scout still reviews only this repository's changes, still cannot be invoked by a sibling, and still holds no authority anywhere but here, where it was installed and where its history sits. What crosses is evidence: a claim somebody made about some code, and whether it held.
| Source | What it yields | Why it is worth crossing for |
|---|---|---|
| Each repository's ledger | Findings already adjudicated in their own house | The verdict travelled with the claim, so a sibling's confirmed finding arrives as evidence rather than opinion |
| The hosted reviews on each | What the metered lanes said, everywhere they ran | A vendor reviewing four repositories still forgets all four, and consolidating is the only place that memory exists |
| All of their continuous integration | What actually broke, and where | A red build is the least deniable finding there is, and no lane had to be right for it to count |
Table 7. What the consolidator brings back, as three kinds of evidence for one corpus.
The third row is the quiet one. A failed build is ground truth that cost nothing to establish, since it needs no adjudicator, no evidenced rebuttal, and none of the line-proximity heuristics the rest of this machinery runs on. It simply broke. Nobody argues with that. Across a fleet of repositories running the same stack, that is a steady supply of the hardest-won kind of example. It is also the one every reviewer, local or hosted, would otherwise throw away at merge.
The provenance rules do not relax at the border. A finding arriving from a sibling is labelled as such and weighed as such, meaning evidence about a codebase rather than about this one, until this codebase's own history says otherwise. Merging them would be the same mistake as merging the domain corpus into the retrospective one, made across repositories instead of inside a prompt.
So the dog does not leave the yard. Something else walks the streets, and comes back with what it learned.
Reef's own story waits its turn: a fleet that watches above, on and below the network. The question arrives with it. What does it mean to give a guard the authority to cut a house off from the world, and then to put another resident above him? That one is not Scout's, and it deserves its own telling.
Why the order is the design
Every layer here is the same move at a different radius: an independent check, held outside the thing it checks, that can only ever subtract risk. Reef acts on the network. Scout reads the code. Each can only subtract, since Reef's recovery only undoes a restriction and Scout can block but never approve. The resident holds nothing as true that has not climbed a ladder it can also fall back down.
Which is what MAX is actually for, and it is easy to miss because he is the thing being protected. MAX is the only position from which both guards can be seen. Reef cannot audit itself, and it proved that by cutting the house off from the world while its own guards reported healthy. Scout cannot either, since a reviewer that graded its own findings would confirm all of them. Each is checked from outside, and the outside is the resident.
They are built in that order for a reason that has nothing to do with caution for its own sake. Guards written after a system can act are written to permit whatever it already does, so they encode the status quo and call it policy. Guards written first are the thing capability has to earn its way past. The order runs scaffolding, then safety, then security, and only then the pen.
Which is what makes the ledger the asset rather than the model. A reviewer that runs before the meter starts saves money. A reviewer that never goes down saves a bad afternoon. A reviewer that remembers every finding this codebase ever received, and whether each one turned out to be right, accumulates something that cannot be bought, cannot be replicated, and cannot be switched off by a decision made inside somebody else's billing system.
The models will be swapped. The corpus compounds.
And what it is ultimately for
None of this care is really about one codebase. A trust ladder that will not promote a claim without corroboration, a reviewer that can object but never approve, a supervisor that can only undo, and a corpus that records what was said and also whether it held: those are not engineering preferences. They are what auditable means when somebody asks, later, how a decision was reached, and the honest answer has to survive the asking.
That is the capability worth building toward. The places where joining data would help most are exactly the places where bringing it together is forbidden, because bringing it together has always meant sending it somewhere. A patient's history scattered across systems that cannot speak. A fraud signal split between institutions. A public record no one office holds whole. A resident that never sends anything anywhere can hold both sides at once.
So MAX is meant to be the first of these rather than the only one, the grandfather of domain-focused residents, safe and secure and auditable and local by construction, whose real work is joining seams that today cannot be joined. The house, the yard, the coastline, and the discipline that runs through all three, are the part meant to be inherited.
Appendix C, the body tables
Tables 1 through 7 each carry the complete data set they describe. None of them summarises, aggregates, or selects from a larger set of rows, so none of them takes a backing appendix. The table numbers here, the anchors table-1 through table-7, and the numbers in the web build file are the same numbers.
glossary
| Term | Definition |
|---|---|
| Adjudicator | The component that decides whether a finding turned out to be right. It can write confirmed and it can write unknown, and it structurally cannot write refuted, because commit history does not distinguish a rejected claim from a deferred one. |
| AI resident | A system that lives on one machine, holds its own knowledge on disk, and works with the network unplugged. The term is used in place of assistant throughout the project, because an assistant visits and a resident does not. |
| Consolidator | The agent that walks the fleet, reads each repository's ledger and hosted reviews and build outcomes, and folds them into the corpus Scout is taught from. It crosses the repository boundary so that the reviewer never has to. |
| Continuous integration | The automated build and test run that fires on a change. It returns pass or fail over the whole change rather than findings, which makes it a gate, and it is the most expensive place in this pipeline to discover a defect. |
| Diff | The list of lines a change adds and removes. It is what a code reviewer is normally given, and on its own it shows what changed and nothing about what the change touches. |
| Egress control | A setting that decides whether data may leave the machine. Because the review prompt carries the full diff, the model host is one of these rather than a convenience setting. |
| Failure-class index | The human-owned registry of defect classes this codebase has already paid for. Nothing automated writes it, so a bad finding cannot teach the resident a fabricated lesson. |
| Forward-Forward | A training method that replaces the usual backward pass with two forward passes, a positive one over what turned out to be true and a negative one over what turned out not to be. Every learning surface in the project runs on it, which is what keeps a store of rows from being mistaken for learning. |
| Held-out accuracy | A score produced by training on part of the evidence and testing on the rest. It answers whether a net generalised rather than whether it memorised, and it is reported as nothing at all below a minimum sample count. |
| Lane | Anything that can look at a change and answer. Four of them run in order here, and two properties separate them: whether a lane produces findings or a pass-fail verdict, and whether its silence is reportable. |
| Ledger | The single store that holds every finding from every lane with its provenance and its verdict. It is an inbox rather than a record, and it is the asset the design is built to accumulate. |
| Lint | A deterministic check that runs on every change without a model. A finding promoted to a lint is a finding no reviewer ever needs to make again. |
| Local-first | A design rule that puts routine capability on the machine rather than behind a network call. Cloud models remain available as an upgrade path for hard problems, declared as paid proprietary fallbacks. |
| Loopback | The network address a machine uses to talk to itself. Scout refuses any model host that is not loopback, and it parses the address rather than matching text inside it, because an address containing the loopback address is not the loopback address. |
| Provenance | The record of where a claim came from and when it was retrieved. Every claim in the graph carries it, which is what lets a claim be re-examined rather than merely trusted. |
| Pull request | A proposed change offered for review before it merges. Anyone who can open one can put text in front of the reviewer, which is why nothing the model wrote is ever executed. |
| Retrospective corpus | What the lanes have actually found in this repository, citable by identifier. It is kept in its own section of the prompt, apart from the domain corpus, because a scar outweighs a paper and the prompt has to say so. |
| Trust ladder | The four rungs a claim climbs inside the resident's knowledge graph, from opinion through hypothesis and belief to fact. Promotion is earned, decay is automatic, and a fact can fall back down. |
| Vector agent | A per-concept learner grown on demand rather than declared in code. A new subject, relationship or defect class gets one without a code change, which is what makes an unseen class learnable. |
Related
Related field notes
Keep reading
More field notes
This piece is part of the MAX Research Collective library. Browse the rest, or connect on LinkedIn.