Yes, most of the text below is generated. Yes, it sounds a bit unhinged. But generally, could a set of overly principles harnesses like this be used not just to build software, but also hardware for robotics?

The VTS Triangle

A first draft. 2026-10-08.

The premise

Three tools, one for each thing a software company must keep doing: decide what to build, run it somewhere, and keep it safe.

Corner	Tool	Job	State today
Product	Vulcan	Turn a requirement into a working, flagged feature in the real codebase	Prototype.
Deployment	Terminus	Move the same system between sizes, from a single Raspberry Pi to a highly available cluster, to keep cloud spend minimal	Does not exist.
Security	Seia	Attack the application continuously: OWASP, authorisation, new routes	Exists as the red-team harness (/red-team), to be renamed.

With all three, Dryark becomes an AI-first software factory: people decide what deserves to exist and what must never happen, and the machines do most of the rest.

The names

The names are Roman, and each god’s character says what the tool is for.

Vulcan, the smith

Vulcan is the god of fire and the forge. He made what the other gods relied on: Jupiter’s thunderbolts and the arms of heroes.

He makes real things for others to use. His work is judged in use, not on the bench. Vulcan’s output is working code in the real codebase, not a picture of it.
His fire creates and destroys. Rome kept his shrine at the edge of the city because the same fire that forges also burns. Cheap generation is that fire: it needs a hearth, which is why Vulcan works behind flags and stops at gates.
He is the imperfect god. Lame, and thrown down from Olympus, he is defined by craft and not by appearance. A rough frame of grey boxes is enough to start from.
He built his own helpers. In the Greek telling, as Hephaestus, he forged golden attendants that could think and speak. The smith with made assistants is the oldest picture we have of this way of working.

Terminus, the boundary

Terminus is the god of boundary stones. Each February, at the Terminalia, the neighbours on both sides of a stone garlanded it and made their offering together.

He does not move. When the temple of Jupiter was built on the Capitol, the other gods gave way; Terminus refused, and his stone stayed inside the temple. His motto in later tradition is concedo nulli, “I yield to no one”. The contract between the application and what it runs on stays fixed, whatever size the hardware is.
He is worshipped under open sky. The roof above his stone was left open. A boundary must be visible to be honoured: limits, quotas and capacities are stated, not discovered in an outage.
A boundary is an agreement between neighbours. Both sides tend the same stone. Each node knows where it ends and the next begins, and both agree.
The stones stay put while the territory grows. Ovid has Rome’s boundary become the world’s. Scale changes; the markers do not. A Raspberry Pi and a cluster honour the same edges.

Seia, the guardian of the sown seed

Seia is a minor agricultural goddess, recorded by Pliny and Augustine, with an image in the Circus Maximus. She protects the seed from the moment it is sown until it breaks the surface.

She guards what cannot be seen. Underground, nothing shows whether the seed is safe. Security is the same: it sends no signal until it fails. Seia is the fitness function for everything the market is blind to.
She guards the most vulnerable stage. A seed is weakest just after planting, and a feature is weakest just after it ships: new routes, new data paths, nothing yet attacked. Every Vulcan run plants something for Seia to watch.
Her work is unglamorous and continuous. She is not an Olympian, and nobody thanks her for a harvest that did not fail. Seia runs on a schedule whether or not anyone is looking.
She is the first of three. Segetia takes over once the grain is above ground, and Tutilina guards it in the store. That is a hint at what comes after Seia: protection for a feature while it grows in use, and for the data at rest.

What we believe

1. The codebase is the factory floor. A prototyping system is only as good as what it stands on. Vulcan works at DryArk’s stage because four things already exist: a design system and its tokens, seams worth composing (Diana, the graph, search, the auth chains), rules and tests written into the repo, and a habit of putting unfinished work behind flags. Below that threshold a system like this makes demos. Above it, it makes candidate features. Bootstrapping is therefore still engineering in the old sense, and it matters more now, because everything generated afterwards inherits it.

2. Cheap code moves the bottleneck to judgement. Generating a page takes minutes. Deciding what it should do takes the afternoon. The valuable moments are the ones where a design contradicts a requirement, or a review notices that a test could never have passed. So requirements come first, in plain scenarios a person approves, before anything cheap begins. A machine never rewrites a requirement to fit what it built.

3. Prototypes end up in production, so we build them as if they will. Vulcan’s output is real code that follows every rule of the repo, behind a flag, reviewed by a developer. It is not a mockup. The dangerous prototype is the one that looks finished: it compiles, it demos, and its access test has never run. “Looks done” is not a state we recognise.

4. The market is one fitness function. It is not the only one. Usage tells us which features deserve to survive, and we should let it. But it is slow and noisy at our scale, it rewards refinement over invention, and it is blind to everything a user cannot see. Security, data integrity and one library leaking into another send no signal until they fail, and then the signal is a catastrophe. Those properties need their own selection pressure, applied on purpose and on a schedule. That is Seia, and it is why the triangle has three corners and not one.

5. Bets come from people. Nobody’s usage data asks for a voice interface that sets your thought against what others have said. Selection can refine a bet; it does not originate one.

6. Cheaper features mean more features, unless we choose otherwise. Jevons applies to software. Every bet that survives is surface to run, secure and maintain. The factory needs a way to retire features as readily as it creates them, and Project Walnut applies to generated code exactly as it does to ours.

7. Other people’s limits are part of the design. A third party’s quota ended our “live” Figma loop in ten minutes. Rapid systems lean on services we do not control. We find the limits before we design around a dependency, and we prefer what runs locally and frugally: a speech model on the laptop, a language model on the desk, a Pi in the cupboard.

8. The same system, at every size, at the lowest cost that carries the load. Terminus exists so that scale is a setting and not a rewrite. The thing that runs on a Raspberry Pi for one team is the thing that runs highly available for many. Its goal is to minimise cloud spend: frugal first, larger only when the load says so, and smaller again when it stops saying so.

9. Humans hold the gates. Each tool stops at named points and waits for a person: approve the scenarios, confirm the branch, review the pull request, sign off the finding. Authority to act is granted narrowly, written down, and checked by the tool before it uses it.

How the corners hold each other up

Vulcan needs Seia. Every Vulcan run adds routes and data paths. Seia audits each new route, and a feature is not finished until it has been attacked.
Vulcan needs Terminus. A prototype is judged by people using it. Terminus gives each candidate somewhere real to run, cheaply, and takes it away again.
Seia needs Terminus. Attacks should be run against an environment that is like production and is not production.
Terminus needs both. What it deploys must be worth deploying and safe to expose.
All three need the reading. Usage tells Vulcan what to keep, Terminus when to move, and Seia where the exposure is.

Reading the market: an offshoot of Vulcan

Tenet 4 says the market is a fitness function. This is the instrument that reads it. It is an offshoot of Vulcan, not a fourth corner: Vulcan makes candidates, and this tells us which ones people actually use.

What it draws on. Three sources, each answering a different question:

Source	What it tells us
A maintained set of SQL queries	What people have done: usage of the platform over time, by feature, library and cohort, and where the spikes are. The queries are kept in the repo and versioned, so a number means the same thing next quarter as it did this one.
Grafana	How the system behaved while they did it: request metrics, latency and error rates.
PostHog	What it was like for them: as much real-user monitoring as we can get, including the paths people take and where they give up.

What it is for.

Judging Vulcan’s candidates. Each feature is behind a flag and has a usage query of its own. Ideally that query is written at the same time as the scenarios: before building, we say what would tell us the feature was worth keeping.
Retiring what was not chosen. A feature with no usage after a fair trial is a candidate for removal. Without this instrument, tenet 6 is only an intention.
Informing the dial. A usage spike, or a sustained rise, is the signal on which a machine proposes a move to Terminus. A sustained fall is the signal to move back down.
Showing Seia where to look. The most used paths are the most exposed ones.

Its limits, stated plainly.

At our scale the numbers are small. A spike can be one enthusiastic team. It reports evidence, and a person draws the conclusion.
It measures what people did, not what they wanted. It cannot see the feature nobody has thought to ask for (tenet 5).
It reads counts and behaviour, never the content of a private library.
It only reads. It changes nothing in production, and it runs with credentials a person has granted for that purpose.

Terminus: the dial

Terminus is an orchestrator of orchestrators. It does not schedule containers itself; it decides which thing should be doing the scheduling, and moves DryArk there.

The goal is to minimise cloud spend. Terminus is not there to make it bigger. It is there so that we never pay for capacity we are not using, and never have to rewrite anything on the day we need more.

The dial. There is one control, and it has a small number of stops. At one end is a single Raspberry Pi. At the other is the equivalent of a full highly available cluster: AWS Fargate, or the same shape somewhere cheaper, with read replicas for the database or a serverless Postgres such as Neon. In between are the stops we actually expect to use, including where we are now and a highly available setup on DigitalOcean or another low-cost provider.

Stop	Shape	Notes
Lowest	A single Raspberry Pi	Everything on one box.
…	One small cloud node
Today	Managed app platform and one database	About $50 a month.
…	Highly available on DigitalOcean or another cheap provider	Several nodes, a database with failover.
Highest	Full HA cluster (Fargate or equivalent), read replicas or Neon

The stops in between are a sketch. Naming them properly is the first piece of design work.

The dial is set by a human or by a machine. A person can turn it because a customer is coming, or a budget is going. A machine can propose a turn because the load, the latency or the bill says so. Either way, a turn is a decision with a cost attached, and someone signs it.

A move. Changing the dial is called a move. Turning it up is a move. Turning it down is a move, and it is treated with exactly the same seriousness: most systems can scale up and few can come back down, which is how cloud bills only ever grow. A move that cannot be reversed is a defect in the plan.

What Terminus produces. For each move, Terminus works through Pulumi and writes two things:

A spec for the target stop: the infrastructure as Pulumi code, with its expected monthly cost next to the current one.
A data migration strategy: how the database, the embeddings and stored files get from here to there, in what order, how long writes pause (if at all), how the move is verified, and how it is undone.

A person reviews both and applies them. Infrastructure stays a human responsibility; Terminus does the drafting, the arithmetic and the rehearsal.

What stays fixed. This is where the god earns his name. The application does not know which stop it is on. The boundary between DryArk and whatever runs it (how it is configured, how it finds its database, how it is told to start and stop) is the stone that does not move. Everything Terminus does happens on the far side of that line.

What we do not know yet.

Which stops are worth supporting, and what each costs.
What the signals are that should prompt a machine to propose a move.
How a move is rehearsed safely. Seia’s need for a production-like environment and Vulcan’s need for short-lived ones are probably the same mechanism.
How much of the lower end is real. A Pi is a statement about frugality and about customers who want DryArk on their own premises; whether it is also a deployment target we test is undecided.

What is not yet true

Vulcan has not completed a run. Its live Figma loop was replaced by sync on request.
Terminus is a name and a page of intent. No stop on the dial is defined, and no move has been planned or made.
Seia is the existing red-team harness under an old name, focused on authorisation; its OWASP coverage beyond that is to be defined.
The market-reading offshoot of Vulcan does not exist. Some of its raw material does: ad hoc diagnostic SQL, Grafana dashboards and a PostHog integration. Nothing draws them together, and no feature has a usage query defined for it.
Nothing yet retires a feature or connects the three tools to each other.

Open questions

Who writes the scenarios in a year: developers, or the design team directly? The answer decides what Vulcan must guard against.
What is the smallest Terminus that is useful: one Pi, or the step from one node to two?
What does Seia block, and what does it only report?
What counts as a fair trial for a feature: how long, and how much usage, before we call it chosen or not chosen?
What is the rule for removing a feature that the market did not choose?

VTS, a way of building things