We have spent decades building better tools for duplicating supervisory engineering.

Archipelago should make great controls technicians more effective, not ask them to become software engineers.

The record comes first

Before any of the rest, a building needs a complete record of its own automation: every backup, every controller program, every drawing and submittal, every sequence, and a line for every change with a name and a date. Almost no building has one. The pieces exist, scattered across contractors' laptops and old servers, and when something changes nobody can say what, when, or who. Everyone is putting software on top of buildings; almost nobody is getting the full record first. Archipelago starts there, with a free record-keeper you install on a server you own, and everything below is what the record makes possible. The record.

The work after the work

A building gets engineered once, properly, by people who know what they are doing. The mechanical engineer sizes the equipment and writes the sequences. The controls contractor programs the controllers: every point named, every loop tuned, every interlock wired, every limit set. By the time the controllers are running, the building is described in more detail than it will ever be again.

Then the supervisory layer gets built. And most of what goes into it is a second, hand-made copy of what the controllers already hold. Equipment trees. Point mappings. Graphics. Alarms. Histories. Navigation. Relationships. Everything the operator will see is reconstructed from scratch, by a technician, from the same facts the controller already knows.

We got good at this. The industry has templates, relativized graphics, macros, bulk imports and exports, spreadsheet workflows, tagging tools and equipment libraries. A skilled integrator can stand up a supervisor for a big job in days rather than weeks. That is a real achievement. It is also the problem in disguise: we built excellent tools for duplicating engineering, and we are still duplicating it.

Why copies drift

Eighty VAV boxes are not eighty copies of one box. Some are cooling-only. Some have hot water reheat, some have electric stages, some are fan-powered. Some carry an exhaust interlock or another special sequence. They have different minimum and maximum airflows, different setpoints, different sensors, different outputs. They are served by different air handlers and they serve different spaces.

Every one of those differences has to be reflected everywhere the box is represented: the graphic, the point list, the alarm limits, the history set, the navigation, the documentation. A duplicated box inherits the wrong airflow settings. A reheat graphic lands on a cooling-only box. An interlock is missing on the one box that has it. Two AHU groups start with the same graphic and drift apart as they are maintained separately. A program changes on a controller and the supervisor never hears about it.

These are not graphics problems. They are the problem of keeping several representations of the same engineering in sync by hand.

What Archipelago does instead

Archipelago understands each piece of equipment as an individual instance of a common equipment model. What is shared is defined once: the equipment type, the view template, the alarm and history policy. What is individual is held per instance, with a source for each fact: reheat type, airflow limits, setpoints, the served space, the serving air handler, interlocks, commissioning state.

The graphic is generated from the instance. The heating valve appears because the box actually has one. Electric stages appear only where they exist. The exhaust interlock appears when that relationship exists and has been established. The AHU relationship lives in the model, so changing which AHU serves a box changes the relationship and everything that depends on it, not a file. Operational parameters come from the controller or from authoritative engineering data, never from values copied out of another box.

And when a parameter or a relationship cannot be established reliably, Archipelago says so and asks a technician. It never silently invents an equipment characteristic, a parameter, or a relationship.

Where every fact comes from

Every fact in the model carries a label: observed on a live device, imported from an engineering file, inferred by a rule with a stated confidence, or confirmed by a named person. Nothing is overwritten. A confirmation supersedes an inference; the chain stays visible. This is what it means to trust a generated BAS: you can always ask it why it thinks what it thinks, and it can always answer with the file, the device, the rule, or the person.

We will never claim that a controller program reveals something it does not contain. A wiresheet is a graph of blocks; we can say what is connected to what, not what the sequence means. A controller file lists exposed objects; we can read the objects, not the logic behind them. The site says what each source can and cannot tell us, and the software says the same thing in its coverage report.

The larger opportunity

Once the engineering is understood, the same model can drive equipment graphics, navigation, point displays, alarm and history configuration, troubleshooting context, commissioning verification, dependency relationships, a documented API, tools an assistant can use, and whatever diagnostics come later. Drift between imported engineering, live controller configuration and the supervisory representation becomes something you can detect rather than something you discover at two in the morning.

The goal is not to generate graphics faster. The goal is to stop independently maintaining multiple copies of the same engineering information.

What we are not

• Not a replacement for Niagara, Metasys, Distech, or any controller or supervisor. Archipelago sits beside them and reads what they already know.
• Not another dashboard. Dashboards show values. Archipelago builds the model those values hang on.
• Not an AI product. It is useful with no language model anywhere near it. If you want to point one at it, the tools are there and they are read-only.
• Not a place your building's record goes to live. It runs on your side of the firewall, the record is yours and exportable, and Cloud is an option an administrator turns on, and the screen that turns it on says exactly what will be sent.
• Not a replacement for technicians. We are building software that can finally use their expertise, and the engineering it produces, without making them repeat themselves.

How we work

Open source, so the code that reads your files can be read by anyone. Local first, tested by running the whole suite with the network turned off. Vendor neutral: every brand is a connector or an importer behind the same interface, and none of them is the platform. Read-only by default, with writing as a separate capability that is off until a named person turns it on. Honest about status: everything on this site is marked available, preview, or planned, and a synthetic demonstration is labeled as one.

The building has already been engineered. Why are we engineering it again?