smallbox

CompanyGraph · purpose as a control structure

A system built to steer its own certainty.

Most of the code in CompanyGraph — the stock-analysis platform I built and run — was generated with an AI assistant. I lead with that because this page is partly about what it did and did not change. What it did not change is the hard part: a system has a purpose, limited resources, and pressure — and the work is to make the purpose operational enough that the whole thing keeps steering toward it. CompanyGraph’s purpose is small to state and expensive to keep: communicate useful company structure without pretending to know more than the data can support. This page is the story of that purpose becoming a control structure. It is not a moral claim about software. It is a control problem — and the evidence is live, so you can check it rather than take my word.

01It starts as a purpose, not a virtue.

Before any architecture, there is a question a cybernetic system answers first: what is this thing steering toward? CompanyGraph does not steer toward “the truth about this company.” It steers toward something more restrained, and deliberately more passive: here are structures we can observe in the available data, here is what supports them, here is where our certainty stops — treat it as a thinking surface, not a verdict. That target is a choice, not a moral position. The same method — purpose, sensing, feedback, constraint, correction — could build something that steers toward conversion, urgency, and confident action instead. It would study fear, scarcity, and status, and it would amplify persuasion rather than regulate it. Cybernetics does not pick the goal for you. It asks what the goal is, what limits exist, and how the structure keeps behaviour aligned with it.

Because this purpose includes bounded communication, the architecture has to regulate speech rather than inflate it. And that turns one plain fact into the whole engine of the design: being honest about a limit is not humility — it is control. A system that lies about what it can support starts fighting itself: the screen says one thing, the data can’t back it, the prompt quietly fills the gap, the documentation drifts, the assistant confidently continues — and the product stops steering. It is now pulled by fluency, noise, and convenience. Every mechanism below exists to keep that from happening.

02Why the control has to be physical.

Here is the whole argument for the engineering in one move. I could produce the careful look entirely on the surface: write a measured sentence, add a verified badge, print a confidence label, colour a chart to seem responsible. It would take an afternoon. And it would be an open loop — an output with no controller behind it, a UI pretending to be regulated with nothing actually regulating it.

The real version is the opposite discipline: if the screen is going to say verified, or reproducible, or a structural reading, or we cannot yet see this, then something physical in the backend has to make that word earned — a verifier that recomputed it, a stored packet, a trust record, a placement decision, a gate that refuses to render when the support is missing. The code is not decoration on the product. The code is the control mechanism; without it, the purpose is just a sentence and the UI is free to drift. That is why a page about careful speech is really a page about backend architecture.

03One purpose, made to steer every layer.

The purpose does not live in a mission statement. It lives as a control loop — sense, read, check, grade, decide, act — where each stage is a responsibility boundary that owns one question the purpose needs answered, and enforces one constraint in code. The domain model is not “just implementation.” Each shape exists because the purpose needs that responsibility to have a home.

THE PURPOSEcommunicate useful structure — without overstating certaintydata quality — sensea number it can’t trust becomes null, not a confident guessthe observation — readbelow the firing line, nothing is stored — nothing to misquoteindependent proof — check“verified” means a second, separate implementation agreedtrust record — gradethe level is computed from checks, never set by hand; a formula change resets itplacement — decideproven ≠ shown — a name that promises a verdict is kept off the pagethe render gate — actrenders only when placed, captioned, rolled out, and reproducible — at oncethe words a reader meetsverified · a reading · cannot-yet-see — each in its own registererror detection · correction · even of its own description

Stage by stage, with the mechanism named so you can find it:

  • Data quality owns what may be sensed. A vendor number that fails a sanity bound becomes null with a reason, never a confident value. The house phrase is literally in the code: valid-or-null, never confident-wrong. A wrong number dressed as a metric is noise the rest of the loop would faithfully amplify, so it is stopped before any meaning is built on it.
  • The observation owns what appears to be present. One formula’s reading, scored 0–100. Below the firing line of 70, the row is not even written — there is nothing weak to surface later, because it was never stored. A sparse company page is the loop working, not a gap.
  • Proof owns whether a separate check agrees. Verified has an auditable meaning: a second, deliberately independent implementation recomputed the claim from the raw numbers and matched. Keeping the two implementations separate is the point — sharing them would make the check prove nothing. The accepted cost is that the maths is maintained twice.
  • Trust owns how firmly the product may stand behind it. The level is computed from the checks, never typed by a human. Each piece of evidence is stamped with the formula version it proved; change the formula and the old trust is automatically withdrawn until it is re-earned.
  • Placement owns whether a reader should meet it. “Can we rely on it?” and “should a reader meet it, as this?” are different responsibilities. A figure can reproduce perfectly and still be kept off the page because its name promises a verdict the arithmetic does not support.
  • The render gate owns the act. A claim reaches a reader only when it is placed, its caption approved, its rollout on, and its trust level reproducible — all four at once. Checked-but-not-shown is a normal, healthy state of this system.
  • The words own the register. A verified figure reads solid with its arithmetic; a structural reading is labelled as a reading and drawn muted; what the system cannot see is stated as a gap, not smoothed over. Pictures obey the same law, so a chart can never quietly promote a reading into a fact.

None of this asks to be believed. The current state of the loop is public on the product itself: the live trust ledger — every observation’s level and limits, including everything still untrusted — and the claim loop in its own words. The structure behind them is drawn in full on System anatomy.

04The loop watches its own description.

A control loop is only closed if it can detect its own error. The accent arc in the drawing curves back to the top for that reason — and it reaches further than the data. The same purpose governs how the system describes itself: when the running code and its own comments drift apart, that is an error, not a cosmetic issue. The next person to read the comment will believe a system that no longer exists, and act on it.

This is not aspirational. While assembling the evidence for this very page, an automated sweep of the codebase found three places where the prose had gone stale — a comment claiming the engine still stored weak signals it had actually stopped storing weeks earlier; a doc undercounting the number of independent verifiers in the proof chain. The fixes shipped the same session. The loop built to catch drift in the product’s claims caught the drift in its own account of itself. That correction cycle — detect, fix at the layer that owns it, and where it matters record a public correction — is the product, more than any single feature is.

05Where Claude steers, and where it can’t.

I will be plain about the assistant, because pretending otherwise would break the same rule the product runs on. AI wrote a great deal of this code, moved patterns across a dozen admin pages, authored tests at scale, and — including for this page — ran the parallel sweeps that gathered the evidence. The volume is not achievable solo without it. That is real, and I am not going to understate it to sound more impressive.

Here is the genuinely interesting part, and it is cybernetic too. When the purpose is made operational in the environment — the docs state it, the code shows the boundary, the domain model gives the vocabulary, the tests fix what must stay true, the UI shows the register, the corrections show what happens on drift — the assistant needs far less direct control. It can enter the structure and continue it, because the structure teaches it what “correct” means here. It can even use the product’s own rules to check the product, which is exactly how the stale comments above were caught. A clear enough purpose starts making the small decisions, so I do not have to make each one by hand. That is what “self-steering” means — not autonomous in the fantasy sense, but a system whose grammar lets the next piece of work compare itself against the purpose.

What the assistant does not do is close the loop. It produces plausible structure fast, which means it produces plausible-but-wrong structure fast when no one holds the purpose. The moves it did not decide are the ones that mattered: which service a piece of meaning belongs to; that the two independent maths implementations must not be helpfully merged, because merging them would destroy the proof; that a metric ranking’s obvious “improvement” was in fact the bug; that a technically-correct number can still be the wrong thing to say to a reader; and once, that a boundary I had already shipped was wrong and had to be reversed on purpose. The bottleneck moved from typing the code to holding the purpose the code answers to. (I keep an honest note on that working relationship in Orientation, not oracle.)

06Limits are the operating reality.

Every organism runs on limited resources, and this product is no exception: limited data, limited models, limited verification, limited visual witnesses, limited company-specific context, limited attention, limited money, limited build capacity. Those limits are not embarrassing — they are the operating reality, and making them visible is a control requirement, because a system that hides its limits stops steering. So, honestly: the editorial placement pass has not been run yet, so today the render gate mostly enforces its safe default — refuse — rather than a rich set of decisions. The visual “what the formula read” witness covers about a fifth of the observation catalogue; the rest declare plainly that no picture exists yet. And the register discipline is enforced in the type system for pictures but only in the prompt and a fail-loud parser for prose — a wrong register in a generated sentence would still have to be caught in review. A page arguing against overstatement should state its own.

07What this is meant to show.

Not that I hand-typed a system — I did not. And not that the product proves any truth about a company — it is built precisely to avoid that claim. What it shows is narrower, and more useful to judge me by: a product’s purpose can be made operational enough that the whole system — and the AI working inside it — keeps steering toward that purpose without constant personal force. Someone has to declare what the system is for, make it real at every layer, notice when a layer stops answering to it, and route each correction to the layer that owns the mistake.

Judge the work by the coherence of the artifact, not by who typed it. The same purpose is visible in the data checks, the domain model, the proof path, the tests, the interface language, and the public correction record — and that coherence is the thing a person had to keep steering.

This is the kind of work I do.

Turning a product’s purpose into a control structure — backend boundaries, a domain model, verification, tests, interface language, and the feedback that keeps every layer honest — and making it operational enough to use AI at speed without handing it the responsibility. If that is useful to you, the whole system is open to read.