You don't need to train a model. Teach the tool.

Every code scanner ends up telling you something your team already knows is fine. The test fixture that swallows errors on purpose. The route that looks open but sits behind two-factor at the gateway. The warning your team closed last quarter, back again this morning. Each one costs a reviewer a few minutes, on every scan, forever. And the knowledge that closes it lives in one senior engineer's head.

The usual answers are bad ones. Train or fine-tune your own model, which takes months and a budget most companies will never have, and you still cannot see why it decided what it decided. Or switch the check off, and now it is off for every project, and nobody remembers who did it or why.

8.0.0 takes a third way. Your model stays exactly as it is. Your team teaches the tool, one project at a time, and every lesson can be read, traced and undone.

How teaching works

1. Record a verdict. On any finished report, a reviewer judges a finding: confirmed real, real but an accepted risk, a false positive, handled elsewhere, not in scope (test, generated or vendored code), or the wrong severity. Every verdict carries a written reason, and a verdict alone changes nothing.
2. Open a Learning Request. Like a pull request for your team's judgement, it turns verdicts into rules. Each rule starts narrow, one kind of finding in one file, and is widened only on purpose, say to every file under tests/.
3. See the impact first. Before anyone approves it, the request lists every finding in the project's recent reports whose outcome would change, before and after.
4. A second person approves it. The author never approves their own request, and revising it resets its approvals.
5. Deploy it as the next version. The project's rule set becomes v2, v3, v4. Every scan that starts afterwards uses it. A scan already running keeps the rules it started with, and every report names the rule set that judged it.
6. Roll back when you need to, or retire a single rule. Deploying an earlier version, with a reason, is a rollback. Retiring one rule is a small request of its own, approved like any other. Both are recorded and announced like everything else.

What a rule can do, and what it never does

A rule can set a finding aside with your reason, change its severity, or accept the risk until a date up to twelve months out, when the finding comes back for review. That is the whole list.

A rule never deletes, rewrites or invents a finding. A finding your team set aside stays in the report's appendix, outside the score, saying which rule set it aside and why. No rule can be written without evidence behind it, and no rule may bury a finding a reviewer has confirmed real. Rules are data, not code: they cannot run anything, read a file or reach the network.

One rule set per project

Every project gets its own rule set, numbered on its own. What you teach Ghost Architect™ Local about one project never touches another, and rolling one back never touches another. There is deliberately no switch that applies a rule to everything. Each project earns its own rules, from its own evidence.

For agencies: every client judged on its own terms

• Every client gets its own rules. A false positive you tuned out of one client's codebase never hides a finding in the next client's code.
• A new client starts clean, judged by the analysis alone until your team has looked at its code.
• Your people stay on their own clients. Developers and viewers see the verdicts, requests and rules of the projects they are assigned to, and nothing else.
• Reports that show their work. Each report names the rule set that judged it, and every finding your team set aside is still in it, naming the rule and the reason. A client can see exactly what you decided and why.
• Freeze a client's rules during their audit. An administrator locks the project's rule set, and nothing deploys for it until it is unlocked.

For companies: judgement that is written down

• Fewer repeat false positives. Once your team has decided and a second person has approved it, the next scan knows.
• Knowledge that outlives the person. What your senior engineer knows about the code becomes rules with reasons and approvals, instead of living in one head.
• An audit trail your auditors can read. Every verdict, approval, deploy and rollback is in a signed, append-only learning log and in the portal's audit log. The live rules download as a spreadsheet: each rule in words, its reason, who asked for it and who approved it.
• Change control that matches the rest of your process. Two-person approval by default, a preview before approval, versions, rollback, and email to a learning reviewers list with the reason in every message.
• Old reports stay honest. A finished report is never changed. To see last month's report under this month's rules, Ghost Architect™ Local writes a separate, labelled LR-adjusted version beside it, with the health score before and after.

Across your fleet, and off the network

What one hub's reviewers teach, every paired hub learns, each lesson signed by the hub that wrote it. Each project deploys from one home hub, every deploy checks that it is building on the rule set live now, and if two hubs ever change one project at the same time, nothing is settled silently: every side is shown and an approver chooses. For an air-gapped site, the learning travels on a file, trusted only after someone compares its key fingerprint, and nothing on it goes live until an approver there deploys it.

What it is not

It is not self-learning AI. Nothing changes because a model decided it should. Every rule carries a person's name, a reason and a second person's approval, and nothing is sent anywhere to make it work: the learning lives on your hardware, with the rest of Ghost Architect™ Local.

EJ Wisner, founder of Ghost Architect™. Local pricing is monthly, per team size, with no per-token bill; the numbers are on the pricing page.