Screens
A bridge, a hospital or a tower is built by an , a , dozens of , hundreds of workers and the watching over them, often for years.
Today each of them keeps their own records in their own tools. VantageOS is the one system they all work in: the plan, the people, safety, money and the record of what happened.
The plan, safety, contracts, payments and site records each live in a different tool or on paper. Nobody has the whole picture, and the gaps between the tools are where things go wrong. Three that every project knows:
An illustrative morning at Operation Fraser Crossing, the simulated project the platform is tested on. Each step links to where the page explains how it works.
Every module shares the same projects, people and records, so nothing is typed twice. Open any module for a guided tour of the real, running app on Operation Fraser Crossing, a demo project. Each screen comes with a short explanation, and numbered callouts walk you round it one part at a time.
When a project ends up in a dispute, both sides argue over whose records are right. VantageOS writes contract and dispute histories to a hash chain: each entry is sealed with a fingerprint that also covers the entry before it. Change anything after the fact and every seal after it stops matching, so the platform can say exactly which entry was altered.
Try it. Change a word in any entry.
services/immutable_audit.py · services/contract_ledger.py
| Rule the platform holds itself to | What it means in practice |
|---|---|
| No made-up numbers | Where there's no evidence for a figure, the platform says so instead of showing a plausible placeholder. A checker scans the code for hard-coded values passed off as measured. |
| Fail closed | Security and safety controls refuse when unsure. The privacy engine won't start without its language model, and production won't start if its database account could get past the walls between companies. |
| Nothing is deleted | Retired code moves to an archive instead of disappearing, so its history stays readable. |
Every AI request goes through one router. It tries models on your own machines first, and moves to a cloud model only if none can answer, and only to providers the deployment has switched on. A request asks for a kind of work, never a particular model, so what runs behind it can change. The goal is models of our own.
Canadian ones outlined; they check real checksums, not just the shape of a number. The answer comes back with the real values put back in. If the privacy engine can't load, it refuses to run rather than letting text through.
| Job | What does it | Where it runs |
|---|---|---|
| Speech to text | A speech model | On your own machines. Sending audio to a cloud service stays off unless an admin turns it on. |
| Hard-hat and vest detection | A vision model | On your own machines. It refuses a model that wasn't trained on safety gear, so a general one can't pass as a hard-hat detector. |
| Forecasting | Statistical time-series models | On the platform's server |
| Optimisation | Mixed-integer and linear programming | On the platform's server |
| Schedule confidence | Monte Carlo simulation | On the platform's server |
| Reading and writing documents | Language models, through the router | Your own machines first, then cloud |
Pick a province and what happened. These are the platform's own rules, run for real when this page was built: which regulator, who is responsible, and the deadline counted from the moment it happened. Where a rule needs a fact nobody has given yet, it names the fact instead of guessing.
Prompt payment laws set how many days a payer has after a proper invoice. Deadlines cascade from the owner to the general contractor to each trade.
Many companies share one VantageOS, often rivals on the same project. None can see another's records, and that isn't left to each screen to remember. A request has to get through four walls.
Inside a project, people belong to companies and report to someone. A record is visible to the person who made it and the chain above them. Nobody can report to themselves or create a loop.
Company tables carry an organisation that can't be empty, stamped on every insert from the signed-in person.
The database layer adds "only this organisation" to every read. A read with no organisation set raises an error instead of returning everything.
Row-level security in the database itself hides every other company's rows, even from a query that forgot the filter.
In production, the server checks its own database account at startup and refuses to run if that account could get past row-level security.
Measured from the code. Most tables carry their company. Some hang off a parent that does. Some belong to a project, where members come from several companies. A few belong to nobody on purpose, each with its reason written down.
Most software describes itself from its plans. VantageOS generates its own map from the code on every pass: which routes the running app serves, which screens reach them, which tables are walled off, which parts are on the event spine. Every claim cites a file and line, and a validator checks the citations still hold. Every number on this page comes from that map.
Operation Fraser Crossing is a simulated major project in Port Coquitlam, BC. Its dataset runs to thousands of workers, and none of it is bulk-loaded: every company, person and incident is entered through the screens, as the people who lived them, on their own dates.
Below here is for engineers: the path of one request, the whole event spine drawn, the guards that keep the code honest, and every change to the database. There's something at the bottom for anyone who makes it.
Keep digging ↓scripts/readiness/run_all.py · scripts/platform_map.py · apps/api/src/platform_api/replay
Every tap becomes a request to the server. Before it touches any data, it passes through layers, outermost first, each with one job. This list is read from the running application, in the order it runs.
Left, the parts of the platform that announce events. Middle, every kind of event, read from the code. Right, the handlers that act on them. Tap anything to trace its wires; tap empty space to reset.
Each time the code changes, a set of guards reads the whole codebase. Most carry a list of known problems. The rule is one-way: a new problem fails the build, and a fixed one must be crossed off, so each list can only shrink. The orange line is its history.
Ready means served, reached from a screen, walled off by company, on the event spine and free of silent fallbacks. The rest work and are being brought up to that bar, one guard at a time.
The database's shape is built by a chain of migrations: numbered steps, each building on the last, from an empty database to today's. The bars show how many landed each day. Drag through them.
Almost nobody reads this far.