Engineering philosophy
How we build
Most of what a church can check about presentation software is what the vendor chose to say. This page describes what happens before anything is said — how work is verified, and what is prevented from reaching you.
Claims we refuse to make
A specification you cannot check is not evidence. So a number does not appear on this website until it has been measured, and a capability is not described until it exists.
This is enforced rather than intended. The build refuses to publish a page containing an unresolved value, and separate checks refuse claims about platforms, prices, payment and imagery that no artifact supports.
| Refused | Why |
|---|---|
| An unmeasured hardware figure | The moment a number appears in a minimum column, somebody buys hardware against it |
| A price that is not approved | A published price is a commitment, and one that disagrees with itself is worse than none |
| An operating system named as the product | A platform is a deployment target. It is not what the software is |
| A download link with no signed artifact behind it | An action that does not work is a defect, not a placeholder |
| A mock interface presented as a screenshot | A screenshot is a claim about what the software looks like |
| A certification we have not run | We publish the exact versions tested, and what the test did not cover |
Where information is missing, the page says so
Several pages on this site state plainly that something has not been tested or has not been decided. That is deliberate. Stating an absence is information; filling it with a plausible value is a guess dressed as a specification.
Unfinished work is not published
Every page on this site carries a declared publication state. The state is recorded in one registry and read by the build; it is never inferred from a page's own metadata.
| State | What the server does | Unresolved values allowed? |
|---|---|---|
| Published | Serves normally, and may be indexed | None |
| Preview-ready | Serves, but is withheld from search indexes | None |
| Held | Not built at all. The address returns not-found | Yes — in the source file only, which is never published |
| Reserved | Nothing exists at the address | No page exists |
Marking a page “do not index” is not access control
A search-engine directive asks a crawler not to list a page. It does nothing about a visitor who follows a link, types the address or shares it. A page that answers a request is a published page, whatever its metadata says. That is why unfinished documents on this site are not built into the output at all, rather than hidden inside it.
Four legal documents are in that state today. They are awaiting counsel, their addresses return not-found, and no page on this site links to them. See Legal.
What is checked, every time
Every change runs the same sequence before it can be published. Any one failure stops the release. There is no override, and no “publish anyway”.
| Check | What it prevents |
|---|---|
| Metadata generation is repeatable | A page whose description was edited by hand and would be silently overwritten |
| Constitutional validation | False availability claims, promotional language, inconsistent spelling, broken internal links |
| Document structure audit | Malformed or inaccessible markup |
| Unresolved-value detection | A page shipping with a value nobody supplied |
| Payload budget | Pages that grow heavy enough to be slow on a modest connection |
| Operational consistency | Security headers and recovery assets drifting from what is declared |
| Build | Held pages reaching the output; links to documents that are not published |
| Publication integrity | Any unresolved value anywhere in the published output — checked by walking the whole tree |
| Design and truthfulness conformance | Structure, accessibility, brand consistency, platform claims, commercial claims, payment claims and imagery |
The last two check the published output, not the source files, and they walk the whole directory rather than scanning the top level. That distinction was learned the hard way: a top-level scan once reported a clean result while pages one level down were serving unresolved values to anyone who asked for them.
Proving a check actually works
A check that never fails is indistinguishable from a check that cannot fail. So each rule is proved by deliberately breaking the site and confirming the build stops.
A defect is injected — a price where none is approved, a payment method that is not supported, an undeclared image, an operating system named as the product — and the build must fail and name the rule. The file is then restored. A rule that does not block its own defect is not trusted, whatever it looks like.
This is not theoretical
A set of rules once shipped that matched nothing at all, because the tool used to write them silently removed characters the patterns depended on. Every test passed, against rules that could never fire. The rules are now written directly, and a separate check confirms the patterns survived before the result is believed.
Forty-five injected defects are on record across the platform, commercial, payment and imagery rule sets — every one of them blocked before the rule was accepted.
How a change reaches you
| Stage | What happens | What stops it |
|---|---|---|
| 1. Build | Pages are generated from one registry; held pages are excluded | A link to a document that is not published |
| 2. Validation | The full sequence above runs | Any single failure |
| 3. Negative testing | Rules are proved against injected defects | A rule that does not block its own defect |
| 4. Publication verification | The whole output tree is walked and inspected | An unresolved value anywhere |
| 5. Independent re-run | The same sequence runs again on a clean machine | Anything that only worked locally |
| 6. Live verification | Every published address is requested and compared, byte for byte, against what was built | Any difference at all |
A deployment is not trusted because it reported success
Stage six exists because a successful deploy and a correct site are different things. Content delivery networks can serve an older copy for some time after a change. So every published address is fetched as an ordinary visitor would fetch it, and compared against what was built. The most recent verification matched all twenty-seven published addresses exactly.
This site also loads nothing from anyone else. No third-party scripts, no fonts from elsewhere, no analytics, no embedded players. The count of external sources is zero, and a check enforces that it stays zero.
How this system grew
None of this arrived complete. Each stage was added after a real failure, and each one closed the class of problem that caused it.
| Milestone | What prompted it | What it now prevents |
|---|---|---|
| Publication integrity | Unfinished legal pages were being served because they were marked “do not index” | Unfinished work is not built at all, and the output tree is inspected in full |
| Design and truthfulness conformance | A written standard that nobody could enforce across thirty addresses | Structure, accessibility and brand consistency are checked mechanically |
| Platform governance | The site described support for an operating system that had shipped nothing | What may be said about a platform follows from whether an artifact exists |
| Budget governance | Documentation inside the code was being counted as weight visitors download | The limit measures what actually ships, so writing things down is never penalised |
| Commercial governance | A commercial contact address existed on four pages and appeared in no record | Every commercial fact comes from one registry, and an undeclared contact stops the build |
| Payment governance | Nothing prevented a second payment path being added by someone solving a real problem | One payment provider, enforced; no payment information is ever collected here |
| Imagery governance | A long-standing promise not to publish mock interfaces, with nothing enforcing it | Every image must be declared, sourced to a build, and teach something |
The pattern is consistent: a problem is found, the class of problem is closed mechanically, and the reason is written down where the next person will read it. Nothing above is a policy anyone has to remember.
Why this matters more than a feature list
LogosPilot runs in front of a congregation, live, with no second take. In that setting the question is not how many capabilities a product lists. It is whether the things it claims are true, and whether the people who built it behave the same way when nobody is checking.
A feature list is easy to write and impossible to verify. The discipline on this page is harder to write and — deliberately — possible to check: the exact versions we certified against are published, along with what the certification did not cover, and the limits we have not measured are stated as unmeasured.
What this costs you
It means this site sometimes tells you less than a competitor will. There are no customer counts, no star scores, no success stories and no promises about dates. When something is unknown, you get the word “unknown” instead of a comfortable number. We think that is the right trade for software you will depend on during a service.
If you are evaluating LogosPilot on behalf of a church, the companion to this page is LogosPilot for church IT, which answers what installs, what connects, what leaves the machine and what does not.