Rebuilding Sylang on the data platform
Sylang started as a text language in git, the way my old architecture language worked. This summer I moved its source of truth into the customer's own data platform. The decisions, the trade-offs, and the numbers behind them.
At Continental I wrote an architecture language that ended up generating ASIL-D braking and driver-assistance software in more than 10 million vehicles. It worked for one reason: it made traceability impossible to skip. Every block, interface and requirement had to be connected, or the build failed.
Sylang began the same way. Text files in git, a precise language, an editor plugin, and a book that teaches the modelling discipline behind it. For a single engineer it is excellent. For a company, I kept running into the same three questions.
| Question a company asks | Text files in git | What it needs |
|---|---|---|
| Can a manager see coverage across every programme? | Only by parsing every repository | A query |
| Can an AI agent and an engineer edit the same element safely? | Merge conflicts | Element-level edits with review |
| Where does the evidence live, when it runs to 100M+ records? | Not in git | A data platform |
So in August I changed the architecture.
Figure 1. Left: how model-based engineering usually works, with files as the source of truth. Right: Sylang now, with one model of the product stored in the customer’s data platform and the same data open to engineers and agents.
The decisions
| Decision | What I chose | Why |
|---|---|---|
| Source of truth | Normalised tables (Delta tables on Databricks), not text | Queryable, governed, and big enough for evidence |
| Where it runs | Inside the customer’s own data platform, as an app in their workspace | Their data never leaves their environment, and their existing access controls apply |
| Which platform | A portable core, plus native features that switch on when detected | Customers already chose a platform. Sylang should not make them choose again |
| First reference platform | Databricks, then one more adapter to prove the abstraction | One done properly beats four done halfway |
| Agents | Four roles: answer questions, author, review for conformance, ingest documents | Each is a different risk level and gets different permissions |
| Who can edit | People and agents, as equal participants with the same data and the same reviews | The audit trail should not care who typed it |
| Editing model | Private saves per element, visible to others on commit | Lets an agent draft without disturbing anyone |
| First slice | Product line and variant management | Every other artefact depends on variants, so it tests the model hardest |
The numbers that drove it
| Measure | Value |
|---|---|
| Largest realistic customer dataset | 100M+ records, mostly test and simulation evidence |
| Views over the same model | 4: graphical, table, document, matrix |
| Agent roles | 4 |
| Reference projects being built | 6: highway pilot (ASIL-D), electric power steering with variants, flight control computer (DO-178C), TCAS, infusion pump (IEC 62304), closed-loop glucose monitoring |
| Standards in scope | ISO 26262, DO-178C, IEC 62304, plus FMEA, FTA and cybersecurity |
| Target platforms | Databricks first; Microsoft Fabric with Foundry, Google BigQuery with Gemini, and AWS Bedrock after |
The first number settled the debate. Design models are small. Evidence is not. Once you accept that a complete engineering record includes every test result and simulation run, the only sensible home is the data platform the company already pays for.
What I gave up
Honesty matters more than enthusiasm here, so the costs:
| Trade-off | Cost |
|---|---|
| No more plain-text diffs | Reviews move from git diffs to element-level change history in the app |
| Platform dependency | Each new platform needs an adapter, and native features differ |
| Harder to try alone | A single engineer cannot just clone a repository and start |
I think those costs are worth it. The thing that made my old language valuable was never the syntax. It was the discipline: every element connected, every change traceable, nothing allowed to drift. That discipline now lives in the schema, where both engineers and agents have to respect it.
Why this matters beyond Sylang
Most enterprise AI programmes are discovering the same thing about engineering data: agents are only as good as the structure they can query. Documents and files are fine for people. Agents need connected, governed records. If your engineering tools cannot answer “what does this change touch?” with a query, that is the first thing to fix, before any agent.