The era of mockups is over

Rafael

• 2026-10-15

On Monday evening we had dinner with a potential customer from a large aerospace engine maker. They make engines for airliners, business jets and military aircraft, in a civil and a defence business that must not see each other's records, and the conversation turned to how they handle non-conformances.

The usual answer to that question is a mockup: a slide with a screenshot, or a clickable prototype on made-up data that falls apart as soon as someone asks "what does the defence engineer see?". This time we started a coding agent (Claude Code) on it during dinner. Before we asked for the bill there was a live application on our demo server, ready to show, with data that reads like their own and an AI assistant built into it.

The repository's first commit, our application template, is at 20:08 (all times CEST). The application was deployed and tested at 21:11. The last commit of the evening, at 22:18, added the features we wanted to show first.

What a mockup cannot show

A non-conformance report (NCR) is raised when a part, an assembly or an engine does not match its definition. Quality then has to contain it, find the root cause, have the Material Review Board (MRB) decide what happens to the hardware, get any departure approved by the right authority, and make sure it does not happen again. For this customer, the civil business gets a departure approved by its own design organisation, and the defence business by the customer's quality representative.

The questions that decide whether software fits that work are the ones a mockup cannot answer:

• Can an engineer on one programme see another programme's NCRs? Can the civil business see defence records?
• When the MRB chair records a "Use as is" disposition, does the concession get raised, and who approves it?
• Has this problem happened before, on another engine, in the other division, under different words?
• Can the assistant answer from the records, and does it see only what the person asking may see?

Answering them takes working access control, a working workflow and records to run them on, and that is what we asked the agent to build.

What was running before the bill

The data is synthetic and was made in two passes. A script generated the structure: identifiers, dates, workflow state, which part, which supplier, which engine. Then one authoring agent per partition (two civil widebody partitions, civil business and regional, defence Europe, defence US, and the cross-programme CAPAs) wrote the text an engineer would write: the as-found description with the measured value against the requirement, the containment, the investigation, the MRB rationale. A validator checked that every field describes a step the NCR has reached, so an NCR still in containment does not already name its root cause, and that nobody in a workflow history acts on a record they cannot see.

How the agent built it

The agent did not start from an empty repository. It started from the same application template we used for the aviation market intelligence app: a CLAUDE.md with the working agreement, one skill per layer of a Curiosity application, and a commented reference implementation of each layer. The working agreement sets the build order: the corpus, then the connector, then the workspace configuration, then the endpoints and the AI layer, then the front end. Each layer may only depend on one built before it.

The git history of the evening:

The pieces, and where each is documented:

• The connector is a .NET console application on Curiosity.Library. It writes the products, parts, NCRs, concessions, CAPAs and workflow events into the graph, creates the 22 access groups and the 14 demo users, and makes every record that names a product owned by that product's division group and programme group.
• Endpoints are C# scripts stored in the workspace: the dashboard, the lists behind every tile, the NCR detail, raising an NCR, moving it to its next step, and the similar NCRs. Every read runs as the person calling it.
• The front end is C# compiled to JavaScript with Transpose and built from Tesserae components: the home page, a renderer for every node type, the NCR sheet with its workflow, the Raise NCR form and the chat view.
• The AI layer is the assistant, a workflow tool, a sandbox, and the search and consult tools, described below.

The agent also tested its own work. A Playwright script raises an NCR as a quality engineer, walks it through every step as the person whose role that step is, and checks the status after each step: 9 of 9 checks passed. Two more scripts cover persona switching (4 of 4) and the guest (6 of 6). An access matrix script logs in as each of the 14 users and counts what each can see.

Walking an NCR from raised to closed

Every NCR opens on its workflow. The next step says what it needs (here, the lines of enquiry for the investigation) and moves the NCR on when it is filled in. When the MRB chair records the disposition, the workflow re-plans itself: "Use as is" or "Repair" raises a concession to the design organisation (civil) or the customer's quality representative (defence); "Rework" or "Scrap" goes straight to corrective action. The concession and the CAPA are created by the endpoint and owned by the same groups as the product, so they are visible to exactly the same people.

The same workspace, seen by fourteen people

Access control was the point of this demo, so the presenter needs to show it without logging in and out fourteen times. "View as a persona" lists every demo user with their role and scope, and switching uses the workspace's own user impersonation, which only an administrator can start.

As the quality engineer for one defence engine, the home page has one division, one programme and eleven open NCRs. The civil business does not exist for this engineer: there is no Civil Aerospace entry in the sidebar, and a link to a civil NCR answers with a 403. Every count on the page is computed live from the graph for the person viewing it, through the same ownership rules, so the numbers agree with what the lists show.

The permission-aware search tutorial shows the same mechanism on a smaller example.

"Has this happened before?"

The question a quality engineer asks first about a new NCR is whether it has happened before. Twelve recurring problems are hidden in the data, each spanning several programmes, sometimes both divisions, and each NCR describes its symptom in its own words. One NCR calls it an alpha case, another an oxygen-enriched surface layer, a third a hardness reading above the parent material.

The answer is a scenario in the similarity engine: the NCR's title, description and investigation are compared with every other NCR's through sentence embeddings, and the graph adds what they share: the same part number, engine, supplier, defect code or making site, each weighted by how rare it is. Every row shows why it surfaced. NCRs the person cannot see are dropped before anything is counted.

Measured against the answer key, which is kept out of the graph, every member of every recurring problem finds the others: 236 of 236 in the top 12, and 217 of 236 in the top 5, in about 0.6 seconds per call.

An assistant that works through the records as you

The NCR Quality Assistant replaces the workspace's default chat. It has four tools:

• NCR Workflow, an AI tool that calls the application's own endpoints: the dashboard, the queues, where an NCR stands, the similar NCRs, and moving an NCR to its next step when the user asks.
• NCR Workbench, a sandbox: every record the user can see as a JSON file under /records, with bash, jq and Python, for questions that need counting and comparing across many records.
• Search Records and consult, to find a record and read it in full with its history.

Every tool runs as the person chatting. Ask about an NCR outside your programmes and the answer is "I can't find that NCR in the records you can see", because for the tools it does not exist.

Two questions, start to finish

We asked the assistant two of the example questions while writing this post, as the presenter, who can see both divisions.

The first was "Which suppliers are behind the most open NCRs, and on which programmes?". No endpoint answers that, so the assistant worked in the sandbox: it wrote the open NCRs to a table in its scratch folder, checked the columns, and counted with awk and Python, in 18 tool calls. Each call can be opened to see the script and what it printed.

The answer is a table of 14 suppliers behind 86 of the 109 open NCRs, split by division and severity with the cost of quality, followed by what stands out: one supplier has 10 open NCRs and no corrective action on any of them, another carries four separate CAPAs against open NCRs, and ten suppliers have open NCRs in both divisions.

The second came from the defence NCR's "Has this happened before?" card. Its "Did this happen in the past?" button opens a chat with the similar NCRs and their CAPAs already attached. The assistant read them, searched the records for the failure mechanism, and came back with a verdict after about five minutes: one of the attached NCRs is the same problem, a civil NCR at the same supplier raised nine days earlier, still in containment and with no CAPA. The NCR the similarity engine ranked first only looks alike: same part number and defect code, but a different supplier and a different mechanism. It ended by offering to draft the lines of enquiry for the investigation, and left the NCR where it was.

We checked that against the answer key, which the assistant cannot reach. The top-ranked NCR is part of one of the twelve planted recurring problems, at a different harness supplier, and the defence NCR is not in it. The twin the assistant found was not planted: the generator gave both NCRs the same supplier and defect code, two authoring agents working on different partitions wrote similar failures for them, and the assistant matched them.

What still needed a person

The agent wrote a TODO.md alongside the code, and it is an accurate list of what the demo does not do yet. Any user who can see an NCR can move it on, so the demo relies on the right person doing each step. The similarity measurement covers the recurring problems but not the planted "false friends", NCRs that share keywords with a recurring problem and have a local cause. A full rebuild of the workspace from the repository was not rehearsed. And a few recurring problems landed on parts whose material does not fit the cause, which a materials engineer would notice.

The use case came from the conversation at dinner. Which of these gaps matter for this customer is for us and them to decide before the demo goes any further.

Why we do not build mockups any more

A mockup proves that someone can draw the screens. This evening took the time between ordering and paying, and what it produced answers the questions a quality lead asks: who sees what, what happens at the MRB, whether this has happened before, and what the assistant does about records the user may not see. Moving it onto the customer's own data means writing a connector against their systems. The endpoints, the access model and the assistant already run on the product they would use.

You can see similar demos on our website at demos.curiosity.ai.