Enterprise architecture · Governed inventory
Applications, the components inside them, their interfaces, and what is deployed where. Pipelines write in what shipped. Every record shows who changed it and when. Impact questions get answered from the graph, not the hallway.
The old way
Spreadsheets, wiki diagrams and fact sheets all share one flaw: a person has to remember to update them. Nobody does, so the map stops being trusted, and every impact question goes back to asking around.
It was, in March. Three releases later nobody opened the page.
Artifacts and Deployments are written by the build, not by a person. Current version per environment and the full history are both one query.
Answered by a Slack thread, two architects, and a guess.
Impact is a traversal from one bound node. Traffic seen in traces but not yet confirmed shows up as Discovered, never as fact.
The tool has an audit log. It is a CSV export you request from the vendor.
The change history is append-only and lives beside the record. A deleted record leaves a tombstone at its address, not a 404.
How it works
The inventory stays true because the parts that change daily are written by the things that change them. Architects decide what exists; pipelines say what shipped.
Applications, the Components inside them, the Interfaces between them, the Capabilities they support. Each is one record with one owner of its edges. A Component can belong to more than one Application, because shared databases exist.
A build records its Artifact. A deploy records the Deployment: which component, which environment, which version, when, by whom. A promotion into a gated environment waits for an approver.
# from the deploy job POST /vordai/deployments { "component": "payments-api", "environment": "prod", "artifactVersion": "v2.13.4" } → 201 · recorded by pipeline · 09:41
Every relationship is an edge in a graph store, so the questions that used to take a meeting are a traversal. The answers are computed when you ask, never stored to go stale.
Capabilities
Not a feature list. Six jobs an architect has to do this quarter, and the part of Vordai that does them.
An Application is what the business names. A Component is what you deploy: the service, the web front end, the database. Vordai models both, and the edge between them is many-to-many, so a database two applications share is one record, not two lies.
Each deployment is a row: component, environment, version, timestamp, who. Current version per environment and the full history are both one question. Nothing is overwritten.
Mark an environment as gated and a promotion into it waits for an approver. Approving is a separate authority from administering, so the person who can delete an application is not automatically the person who can ship to production.
The change history is append-only and shown on the record itself, relationship changes included on both ends. A deleted record leaves a tombstone at its address saying what it was and who removed it.
A component depends on a versioned release of a package. Ask which releases expire in the next ninety days and the answer is computed against today's clock, never stored to go stale.
Every list pages, searches, sorts and filters on governed vocabularies, with facets counted server-side. Lifecycle and health stay two separate badges everywhere, because a deprecated application can be perfectly healthy, and a live one can be down.
Cameras, gateways, racks: the things the organisation has. Typed, imported in bulk, filtered at scale, and linked to the environments and deployments that run on them.
What we can stand behind
Vordai is pre-release and has no customers to quote. What follows is how the product behaves, measured where a number is given, and one case labelled as the illustration it is.
One domain service owns every rule. The browser hides buttons; it never decides. If a validation is not enforced there, it does not exist.
Sign-in is OIDC against your identity provider, terminated server-side. The session is an opaque httpOnly cookie. The domain service is never internet-facing.
A keyset page of Applications over a 40,000-node label, on a developer laptop against the graph store. Pre-release figure; we will publish the method.
The ledger database is a Component contained by four Applications. Any tool that assumes one application per component either duplicates it or picks a winner. Vordai holds one record with four containing edges, and when a pipeline asks where to deploy, the four are consulted and a disagreement is an honest "no answer" rather than a guess.
When the card switch is finally retired, its record stays as a tombstone, its successor edge points at the gateway that replaced it, and the capabilities it carried roll up to the new one the same afternoon.
Built with Rust, PostgreSQL, a standalone graph store, and a Lit front end. Self-hosted in your network.
Early access
Not open yet. We are building Vordai with a small number of teams first, and there is nothing to sign up to while that is true. The terms above are what early access will be when it opens.
Fair questions
Three things LeanIX does not do: model the Components inside an Application, let a pipeline record Artifacts and Deployments directly, and show an append-only change history on every record. If your pain is that the inventory is never current, those are the three that fix it.
Migration tooling is not built yet. Today the path is the API and CSV import for assets. We will say so plainly rather than sell you a connector that does not exist.
They will not, and the design does not depend on it. What changes daily, what is built and what is deployed, is written by the pipeline. What changes quarterly, what exists and what it supports, is what people model. Discovered interfaces from traces show up for review rather than being silently added.
Self-hosted only, today. Identity, roles, workflow and the change history live in PostgreSQL. The architecture graph lives in a standalone graph server. Both are yours to back up and query. The domain service is never exposed to the internet; only the small front-end service is.
Not yet. Ownership, cost, risk and surveys are designed and not built. The reports that exist are the ones the graph answers directly: impact, capability rollups, expiring releases, an asset map. We would rather tell you that than have you find out.
Standard OIDC with PKCE against any issuer that supports discovery. Auth0 is what it is developed against; pointing it elsewhere is a configuration change. Tokens are held server-side. The browser only ever sees an opaque session cookie.
Every inventory list pages server-side and has been measured against a label of 40,000 nodes. Asset registers of the same order are the reason assets sit in PostgreSQL rather than the graph. It is pre-release software; if your estate is larger than that, we would like to test against it with you.
Bring one application and its pipeline. In an afternoon you will have a record that is still true next quarter.