Everything about your system, in one connected model.
Requirements, architecture, risks and tests are linked records in the same model. When one changes, the others show it.
Albatross-1Sample project
16Requirements
10Functions
21Components
8Interfaces
7Risks
9Verification cases
See it work on a sample project.
Four things SyntheraOS does, played out on the Albatross-1 sample project. Every ID and status you see comes from that project’s data.
Follow a requirement all the way to its test.
Each requirement links to the parts that deliver it and the tests that check it. If a test is missing or hasn’t run, you can see the gap.
Requirements with structureRequirements sit at stakeholder, system, subsystem and component level, each with a parent and acceptance criteria.
Linked to real partsEach function is assigned to the components that perform it, right down to the speed controller.
Planned is not passedA test shows as passed, in progress, or planned and not yet run. Nothing gets rounded up.
Interrupt one part. See everything it reaches.
The shared converter fails. SyntheraOS follows its connections to the functions that lose power, then to the requirement, risk and test that now need another look.
Physical dependenciesEach interface records its type and spec, so a power path in the model is a real power path.
Impact before approvalPropose a backup power rail and review every record it touches before anything changes.
No orphaned risksRisks stay attached to the parts and requirements they threaten.
Watch risks shrink as the fixes land.
Seven Albatross risks start at their score before any fix. As mitigations apply, they move to their score after. One of them doesn’t move.
Probability times impactEach score is probability times impact, worked out from those two numbers rather than typed in.
Inherent and residualSee the risk before and after its mitigation, side by side.
Tied to evidenceEach mitigation links to the test that has to prove it worked.
Ask in plain words. Get the records back.
Every answer cites the requirement, risk and test it came from, so you can check each sentence against the model.
Scripted example. No live AI request.
Grounded in the modelAnswers come from your project records, not from a guess about your system.
Every claim citedEach citation opens the record it came from.
States stay visibleStatuses like in review, open and planned show exactly as they are.
The software behind the system
Know what you’re building. And why it will work.
SyntheraOS is a shared workspace for engineering teams whose systems have lots of parts that depend on each other.
It connects what the system has to do, how it’s designed, what could go wrong, and the evidence that it works. Pick any part and follow what it depends on.
Four questions every project has to answer.Explore a question
Requirements and needs
Turn “make it reliable” into something you can check.
Start with a clear promise: the aircraft must keep control if one power element fails. SyntheraOS stores that requirement with its purpose, owner and acceptance criteria.
Everyone agrees what success looks like before anyone picks a solution.
Go deeper: requirements and traceability
Each requirement is versioned and has a review state, rationale, acceptance criteria and verification method. Its parent gives the context. Linked components and tests connect what you meant to what you built. Quality flags call out missing criteria instead of leaving them buried in the text.
A battery can work perfectly and the power system can still have a weak point. What matters is what depends on what. SyntheraOS links components to their functions, their interfaces and the requirements they support.
You can look at one component without losing sight of the rest of the system.
Go deeper: the connected engineering model
The model stores typed objects and the relationships between them: functions assigned to components, component hierarchies, interfaces and linked risks. That graph is what gives you traceability across disciplines. The 3D aircraft shows the physical context, and the engineering records carry the meaning.
These components are linked to the shared-supply risk.
Risk and verification
A test plan is not a test result.
Writing a requirement doesn’t prove the design meets it. SyntheraOS links each requirement to the test that has to show it, and keeps that test’s current status and related risks in view.
You can tell what’s intended, what’s under review and what’s still unproven.
Go deeper: verification and evidence
Each test records its method, procedure, owner and the requirement it checks. In this example, VER-009 is a demonstration and is still planned. RSK-011 is still open, scored probability 4 × impact 5 = 20, with no mitigation defined. Neither the 3D animation nor the scripted AI answer counts as evidence.
Sample records, showing their real review and test status.
Change impact
See what needs another look.
Adding a second power path sounds like one change. It also raises questions about the design, the requirement and the test. SyntheraOS lets you follow the linked records, so the review covers more than the part you touched.
A proposed fix stays tied to the work needed to justify it.
Go deeper: impact and configuration
An impact review follows links from the affected component to its requirements, risks and tests. Configuration control records which version is under review. Here the backup path is only a proposal. On its own it doesn’t approve the requirement, close the risk or complete the demonstration.
This is Albatross’s power system. Pick a component, cut the shared supply, then look at the engineering records it affects.
Power path available
Interactive dependency example
Albatross-1 Power architecture
Supplying powerOne shared supply.Flight control and propulsion depend on it.
Inspect a component
The battery is fine. Both functions still depend on a single converter.
Explore all 10 capabilities
Ready for the review board.
Who changed a record, how well it’s written, and what actually proves it. Shown on the Albatross-1 sample project.
TimeActionOwner
Every change, attributedEvery record keeps its owner, version and history, so a reviewer can see who changed what and when. Sample activity.
Requirement quality16 requirements
Requirements you can checkQuality checks catch vague wording, missing criteria and requirements you can’t test, before the review instead of during it.
VerificationAlbatross-1
Cases
9
Passed
2
In progress
1
Planned
6
Evidence, not assertionOnly one of sixteen requirements has a passing test today. SyntheraOS tells you so, and lists the tests still to run.
What it’s built on.
One graph of linked records, saved as baselines you can compare, broken down from mission to component.
A digital thread across every disciplineNeeds, requirements, functions, components, interfaces, risks and tests all live in one graph, linked by relationship type.Baselines you can compareFreeze the model at a review, then see exactly which records changed by the next one.Built for systems of systemsBreak the mission down to single components without losing the links. Each level keeps its own owner, status and evidence.
A working preview styled like the rest of this site. It uses the Albatross sample project, and nothing you change here updates a real project.
A little more context
Questions people ask.
Short answers first. Open the engineering detail if you want it.
What is a “digital thread”?
It’s the connected story of a system: why it’s needed, what it has to do, how it’s built and how you check it. You can follow that story either way.
In engineering terms: traceability across typed objects and relationships, including needs, requirements, functions, components, risks and verification cases. A missing relationship is a gap to review, not a connection to assume.
Engineering GPS sorts the program by lifecycle stage, shows what information is missing and suggests a next step. The team gets context for the work as well as a task list.
In engineering terms: stage context, completeness gaps, warnings and recommended actions linked to the relevant objects. The prototype includes stages from mission definition and architecture through verification and operation.
Where does AI fit into the process?
You can ask questions about the model and open the records behind each answer. Your team still reviews the engineering decision and its evidence.
In engineering terms: source-linked reasoning keeps each explanation tied to specific requirements, risks and test records. The question in the Ask demo above is scripted, so you can try it without sending a live AI request.
The aircraft is an example that makes the connections easy to see. SyntheraOS is the engineering workspace behind it. The prototype’s desalination project uses the same model structure.
In engineering terms: the core is an object-and-relationship model. A 3D view is one way to inspect context, alongside requirement, architecture, risk and verification views. This authored aircraft is illustrative, not a validated aircraft design.
Can it connect the engineering to cost and schedule?
Cost and schedule records can sit next to the design they relate to, which makes it easier to ask what a design choice means for the wider program.
In engineering terms: the Albatross sample includes cost items linked to components and suppliers, with estimate, commitment and actual-cost fields. A shared model keeps that context close to engineering changes; it does not make every consequence a known or calculated result.
Bring your system
Let’s connect the real thing.
Show us what you’re engineering. We’ll show you where SyntheraOS fits.
