Trust
B.O.S.S.

Governance

Where every opinion in here came from.

A tool that coaches you is only as good as the advice inside it — and “built on best practices” is the cheapest sentence in software. So BOSS treats its own beliefs as an asset that can rot: 32 practice files, every one carrying who it came from, when it was last checked, and what would make it wrong. 83 outside claims have been through the filter.

▸the filter
83 outside claims put through the filter. Adopting one as-is is the rare outcome — most that survive are modified, and a large share are turned down or held.
32 practice files, every one carrying its provenance, the date it was last checked, and the curve that says how fast its ground moves.

A claim from a stranger has earned nothing

A Reddit thread, a blog post, a conference talk, a “you must do X” best-practice — none of it gets into BOSS by being popular. It goes through /vet, which is deliberately biased toward NO and scores against a fixed rubric.

who actually said it? Attribution is checked before the claim is graded. This step exists because three claims in a row turned out to be bent on exactly that: a half-right quote, a study that didn't say what it was cited for, and a second-hand number. An attribution is a citation's load-bearing half.
does it contradict a principle? The six operating principles win. A popular practice that violates one is rejected on those grounds and the reason is recorded.
what grade is the evidence? A vendor blog post and a controlled trial are not the same input. Direction over multipliers; vendor-graded findings are labeled as such.
who does it serve — and who does it harm? Named explicitly, both directions, before any adoption.
is it a duplicate, or does it sharpen something? Sharpening an existing practice beats adding a new one. Surface area is a cost.
how much ceremony does it add? Anything that adds founder-facing ceremony has to earn it against Principle 2. Most things don't.

Four outcomes: ADOPT · ADAPT (taken, but changed and the change reasoned) · REJECT (with the reason, logged, so it isn't re-litigated every time it trends) · NOT-YET (a real condition that would re-open it). Adopting as-is is the rare outcome, not the common one — most claims that survive are modified, and a large share are turned down or held.

A deferral whose condition has expired is not a decision — it's a stale note. Those get re-decided, not left to rot.

▸the other door

The second way something gets in: you proved it

Everything above is the filter on claims from outside. There's a second door, and it's the one BOSS's first operating principle is about: when work pauses, sort what you just learned. Most of what's worth keeping isn't a blog post — it's a pattern you used three times without noticing.

/extract is that pause made into a verb. It reads your recent work — the commit log, the devlog, the code — and proposes one to three candidates, each routed one of two ways: UP into BOSS's library as a practice other projects inherit, or DOWN into your own app as hardened code that stops being a pattern you have to remember. /boss-learn is the judgment step over that routing, because those two destinations are not interchangeable and guessing wrong is how a library fills with things nobody needed.

It proposes; you decide. Nothing enters the library because a machine thought it was clever — the same standard the outside door is held to.

▸attribution

Nobody's name is on an agent

BOSS's mentors are archetypes seeded by named, attributed practices — never impersonations. The rule, kept in writing: no agent impersonates a person; mentors cite the practice. A named thinker's transferable heuristic is distilled into a practice file with the attribution attached; the agent then reasons from the practice.

The one-line lens recorded next to a practitioner is a study pointer — not that person's endorsement, and not their verbatim view. Which is why you'll never see a mentor- agent claiming to be anybody.

▸staleness

A doc rots because the ground moved, not because time passed

So every practice carries a curve — how fast its ground actually moves — and the curve routes it to whichever discipline owns it. Cadence alone provably misses: the first freshness run reported everything fresh while one practice was already wrong, seven days after it was written, because a spec had shipped in the meantime.

the sweep hunts for what's WRONG, not just missing Because the tool pushes its guidance into live projects, a stale practice isn't inert — it actively ships bad advice. Reversals count as findings.
events fire the review, not just the calendar A spec revision, a new frontier model, a breach, a regulatory ruling. Those trigger the relevant discipline directly instead of waiting for a date.
a finding is not a build Sweeps produce findings; what gets built is a separate, deliberate decision. Most findings are logged and left.

This site is held to the same rule.

The team roster, the skill reference and every count on these pages are generated at build time from the same stage manifests the CLI reads, and the build runs in the release gate. Nobody can type “15 agents” into a page and let it quietly become false. That fix exists because BOSS's own cheatsheet drifted for 56 releases while its generator was wired to nothing — a check nobody runs isn't a check.

▸the honest part

What this doesn't prove

A rigorous filter on incoming advice is not the same as evidence that the advice works. BOSS has one external founder's reaction on record and no long-run outcome data — so what's claimed here is process, not proof. The pipeline stops bad claims getting in. It does not establish that the good ones made anyone's company better. That would take users and time, and BOSS has very little of either yet.