Design Graph

Premise

Aerospace programs lose more value to broken traceability than to broken engineering. A requirement gets refined, a part number gets revised, a test result gets entered against the old part — and by the time anyone notices, the program has been quietly designing against two different versions of itself for six months.

Digital-thread tools exist (Teamcenter, Windchill, 3DEXPERIENCE) but they're heavy, expensive, and structured around large-team configuration management rather than around how a small engineering team actually thinks. The premise here is that a graph database with the right schema — not just any node cloud — can deliver the part of the digital thread that matters at two orders of magnitude less weight.

One graph, several architectures

The database underneath is unremarkable: nodes and edges. What makes it a design tool rather than a diagram is the framework on top. Every node is typed by what it is in the design — a Function, a Component, a Requirement, a Risk — and every edge is typed by the semantic relationship it carries — CONTAINS, PERFORMED_BY, DRIVES, VERIFIES. Those types let the same graph hold several architectures at once, woven over the same parts:

• a functional architecture — what the system must do
• a physical architecture — what the system is
• the allocation between them — every function mapped to the hardware that performs it

…plus the requirements that constrain it, the decisions that shaped it, the evidence that verifies it, and the risks that threaten it — all under a single effectivity. That weave is the whole point. A flat node cloud is just the database; the architecture is the value.

Nodes

67

Relationships

98

Node types

8

Relationship types

8

Below is the Apollo program rendered through the same lenses the working tool uses. Switch between the physical product tree, the functional architecture, and the allocation that binds one to the other — then click any node to trace it: where it sits physically, what function it performs, what requirements drive it, what verifies it.

The schema is the point

A node isn't a generic dot and an edge isn't a generic line. Each one carries meaning, and that meaning is what lets a single query answer "what performs this function," "what's physically inside this assembly," or "what evidence closes this requirement." Here is the working vocabulary the Apollo corpus uses — typed nodes grouped by the architecture they belong to, and the semantic relationships that connect them.

Effectivity is what makes it engineering

The trick that elevates this above diagram-drawing is effectivity: every node and edge carries the configuration range it applies to. A requirement that changed between Apollo 11 and Apollo 15 doesn't get overwritten; it gets a new effectivity. Querying "the requirements that applied to Apollo 13" returns exactly the set that was active on that mission — not the latest baseline, not yesterday's revision. The Apollo graph above is pinned to one effectivity (Apollo Program); the working tool slices the same nodes by mission, block, and serialized configuration. This is what real digital-thread tools spend hundreds of thousands of dollars per seat to provide.

The raw graph

Underneath every structured view above is one graph. Here it is with the framework stripped away — just typed nodes and typed edges, the database the architecture sits on. Useful for seeing the whole shape at once; drag to pan, scroll to zoom, filter node types in the chip row.

Public showcase vs private working tool

This page renders a public reference dataset (Apollo) exported from a running instance of the design graph, using the same schema that powers the private working instance used for active project work. The two are deliberately separated:

Public face

design.dauntless.systems

Public data

Apollo reference graph (read-only)

Private face

studio.dauntless.systems

Private data

Active project graphs

Public auth

None — view-only

Private auth

Cloudflare Access

This page

Static snapshot · zero attack surface

Schema

schema_v2 · effectivity-aware

The snapshot on this page is fully static: a JSON manifest exported from the live graph at publish time, so there's no database behind the website and nothing to attack. The same graph also runs as a live, read-only instance — destined for design.dauntless.systems — with editing gated behind Cloudflare Access at studio.*, so the public can explore but only I can build. Read-only there isn't cosmetic: the API rejects every write at the door.

How it works internally

The private working instance is what gets used for active work:

Graph

Neo4j (Docker)

API

FastAPI · read/write + agent contract

UI

Next.js · physical/functional/library nav

Domains

Core · reliability · analysis · config · ERP · MES

Effectivity

Per-node + per-edge versioning

Verification

FMEA · RBD · evidence rollup

AI integration

Documented read/write data contract

Remote access

Cloudflare Tunnel

A documented AI data contract lets agents read and write to the graph through a constrained interface — relevant because the long-term play is to have design agents reason about the graph directly rather than scrape READMEs.

What's next

Three threads. Stand up the live read-only instance — point design.dauntless.systems at an Apollo-seeded graph in a read-only serving mode and move the working tool behind Cloudflare Access at studio.*, so this page can link straight into a live, explorable graph instead of a snapshot. Expand the Apollo corpus — the current graph is the architecture spine; thermal, GN&C, and life-support subgraphs would round out the public reference. Open the corpus on GitHub — the export pipeline is well-suited to community contributions of specific components or sub-mission events.