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.
Out of every big project, the bridges, hospitals, transit lines and towers, how many finish on time, on budget and deliver what they promised?
Less than 1%. One project in 200.
Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (2023), from Flyvbjerg's database of major projects.
On a public project, every dollar over budget is a taxpayer's dollar: money that could have kept a clinic open or put food on a family's table. Every week a crew spends chasing which version of a drawing is current, re-entering the same numbers in another tool, or arguing over who said what, is a week not spent building the things people are waiting for.
It happens in the gaps. The plan, safety, contracts, payments and site records each live in a different tool or on paper, so nobody has the whole picture. Three gaps every project knows:
Every one of those gaps comes back to the same problem: the record lives in too many places.
Want to see the solution?
Show me ↓VantageOS takes the pain points of a project, for every participant, shareholder and stakeholder at every step of the way, and solves them on one intelligent platform. The owner, the builder, every trade, every worker and every regulator work from the same record, so the plan, the people, safety, the money and the history of what happened never drift apart.
A walkthrough of the real platform: the screens people use on a project, doing the work they're for.
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.
The real screens, shown on an example discovery session. Tap a picture to go through it full screen.
Everything above is running today. These are the interfaces still on the way, starting with the one that puts the platform in every worker's pocket.
A phone app that isn't a shrunken copy of the desktop. It knows who you are, where you are on site and what's happening right now, and shows only what matters to you in that moment.
It's also a working part of the platform, not only a window onto it. Every phone on site sends in check-ins, photos, voice notes and sign-offs as they happen. That fills gaps the platform has today: the emergency roll currently has no sign-in or location source, and the app becomes that source.
The crew's day already runs on the phone: attend the safety meeting, follow the slides live, sign, work each task against the schedule, raise a ticket, close out, go home.
Pick a roleWhen 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.
VantageOS is still being built, and it's being built with the people who'll use it. Sign up and you'll be among the first let in as each part is ready.
Investor, public agency, builder or trade? Not ready to test yet? Tell us who you are and what you need, and we'll get back to you.
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.