Glossary
Some of our vocabulary is genuinely ambiguous in ordinary English — 'operating system' most of all. Rather than explain it on every call, here is the same glossary we hold ourselves to internally, including what each term is NOT. That second line is usually the useful one.
The platform that runs a business
A custom platform that holds the actual operation — quoting, dispatch, scheduling, invoicing, field work and reporting in one place, with roles, an audit trail and settings a manager can change. It is what we build for clients, and it replaces the spreadsheet-plus-four-tools arrangement most businesses grow into.
NOT an operating system in the computing sense — nothing to do with Windows, macOS or Linux. And not a single app bolted onto five others: if the data is not joined up underneath, it is a tool, not an operating system.
The intelligence layer of an Operating System
The layer that acts on the work rather than storing it — answering from the records, queueing actions, building artifacts on request, and refusing requests outside a person's permissions. It is built from an operating system's own context, rules, flows and memory, which is why it cannot be bought as a generic box. We built ours to run Nexcore; it is the reason the factory is a factory rather than a checklist.
NOT a standalone product — it is an add-on tier built on top of an Operating System, and it cannot exist without one: the operating system comes first, the brain is added when you are ready. NOT included by default. NOT a chatbot pointed at your files, and NOT a generic model: a model with no context, rules, flows or memory is a confident guess. Formerly listed here as “System”; renamed 2026-08-13 when the two pages became one.
The standardised build loop
The repeatable process every build passes through: map, spec, audit, build, verify, record. Same six steps on every slice of every project, producing the same documentation and the same shape of output each time. It is why a second system costs less than the first.
NOT a physical place, and NOT a template or a boilerplate we paste. The output is custom every time; the process producing it is what is standardised.
The unit of work
One shippable piece of working software, scoped to named files, with a defined edge. A slice is finished when it has been driven in a real browser — including its failure branches — and the documentation has been updated.
NOT a sprint, a phase, or a ticket. A sprint is a period of time; a slice is a thing that either works end to end or is not done. Half a slice does not ship.
Driven in a real browser, both branches
A change has been exercised in an actual browser against a live database, on every route it touches, and on both sides of every gate — the blocked path as carefully as the happy path, because the blocked path is the one protecting the business.
NOT "it compiles", NOT "the tests pass", and NOT "it worked on my machine". Automated tests are evidence; they are not the same claim. A feature that has never been used through a browser has not been shown to work.
A front door into the operating system
A public site that reads from and writes to the same database as the internal system — so a form submission becomes a record where the work happens, not an email somebody retypes.
NOT a brochure site with a contact form, and NOT a separate CMS kept loosely in sync. If the website and the system hold two copies of a customer, it is not connected.
Two reasons, both practical. It settles a distinction that genuinely confuses people on a first call — an Operating System holds your data, its Brain acts on it — so writing it down once is cheaper than explaining it every time. And a company whose differentiator is its method should be willing to publish the method. "Read what we mean" is a stronger position than "trust us".