Home Addason Digital Gospel Pricing Get Your Audit
Gospel (the product) Client pitch (60 seconds) Detailed pitch (the long version) See an example Common questions
System Reliability About me How I score sites Case studies Client guide
The operational layer

How the system runs itself

Most of what runs this service is not the website. It is the set of controls that decide who may change what, check that a change actually reached the live page, and stop a bad edit before it happens. Every claim below names the file that implements it.

What is actually in place

Five controls, each verified on 2026-07-28. The file path under each one is the implementation, not a description of it.

01

Every file has one owner

Work happens in parallel across the codebase. A registry maps every path to the lane that owns it, and a pre-edit check names the session already working in a file before a second one touches it.

The check runs against exact paths. An earlier version compared filenames only, so it fired on every index.html in the repo and taught people to ignore it. That was found and fixed rather than tolerated.

Implementation
shared-context/lanes.json scripts/lanes.mjs --check <file>
02

Work is handed off, not raced

When a task belongs to a different lane, it is passed to that lane by name with the context attached, rather than being done twice in two places and reconciled later.

The failure this removes is two people building the same thing differently and nobody noticing until a client does.

Implementation
shared-context/CHAT-COORDINATION.md scripts/lanes.mjs --who
03

A separate pass re-tests the claims

A supervising job runs on a schedule and re-checks what was reported as shipped. It tests the live served page, not the file in the repository, because those are not the same thing.

A hand-edit to generated output looks correct locally, passes a file-level check, and is silently reverted the next time its generator runs. Checking the served page is what catches that.

Implementation
data/cloud-jobs.json → session-overseer scripts/verify-live.mjs --url=<URL>
04

The rules are enforced, not remembered

A written rule that depends on someone remembering it decays. The same mistakes kept recurring until each one was moved into a hook that blocks the action at the moment it is attempted.

Three are active: one blocks guessing at credentials, one blocks editing a generated file where it is displayed instead of where it is produced, and one blocks writing over a file another session changed underneath you.

Implementation
.claude/hooks/no-credential-guessing.mjs .claude/hooks/no-generated-file-edits.mjs .claude/hooks/stale-file-guard.mjs
05

One client cannot read another

The dashboard API resolves the caller's token to a client identity on the server. The caller never supplies their own identity, so it cannot be swapped for someone else's.

A request carrying a client id that disagrees with its token is rejected outright rather than quietly corrected, because a silent correction hides an attempt. No token is rejected as unauthorized.

Implementation
netlify/functions/lib/gospel-auth.mjs netlify/functions/gospel-api.mjs (401 / 403)
06

Nothing ships unverified

Before a deploy, a static check runs across the sites. After a deploy, the live URL is fetched and read back. A change is not called done because the edit succeeded; it is called done when the served page shows it.

Pricing is included in that check, so the number on a service page cannot drift away from the canonical list without the deploy failing.

Implementation
scripts/pre-deploy-check.mjs shared-context/canonical-prices.json

What happens when something changes

The path every edit takes, in order.

1

Ownership is checked first

The file is tested against the lane registry. If another session is already in it, the work is handed over instead of started.

2

The source is located, not the symptom

If a generator produces the file, the generator is edited. A fix applied to generated output is reverted the next time it runs.

3

The pre-deploy check runs

Static checks across the sites, including price consistency against the canonical list. A failure stops the deploy.

4

The live page is read back

The deployed URL is fetched and inspected. The repository file is not treated as evidence that anything reached a visitor.

5

The change is written to the record

One line, appended, naming what changed and where, so the next session starts from what is true rather than from what was assumed.

Steps 2 and 4 exist because both failures happened. A colour fix once looked correct on the live page and would have reverted on the next build, and a feature was logged as reaching every dashboard when it had reached two.

What this does not claim

The claim is not that this system does not make mistakes. It is that the mistakes get caught here rather than by you.

  • It is not flawless. Every control listed above exists because the matching failure already happened at least once. That is why they were built.
  • The checks can be wrong too. A monitor reporting a problem is verified before anything is changed. On one day, six of seven reported outages were broken monitors rather than broken services.
  • No uptime figure is quoted here. Any number on this page would have to be measured over a period long enough to mean something, and it has not been.
  • Nothing here is autonomous. These controls decide what reaches a live page. They do not make decisions about your business, your pricing, or your copy.