We recently had dinner to discuss a potential engagement with a large aerospace engine manufacturer. It makes engines for airliners, business jets and military aircraft, in a civil and a defense business that must not see each other's records, and the conversation turned to how it handles 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 defense engineer see?". This time we started a coding agent on it during dinner. Before we asked for the bill there was a live application on our demo server, with data that reads like the manufacturer's 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 contains it, finds the root cause, has the Material Review Board (MRB) decide what happens to the hardware, gets any departure approved by the right authority, and makes sure it does not happen again. Here the civil business gets a departure approved by its own design organization, the defense 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 program see another program's NCRs? Can the civil business see defense 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. That is what we asked the agent to build.

What was running before the bill

Products	20 engine programs: 11 civil, 9 defense
Records	259 NCRs, 79 concessions, 107 corrective actions (CAPAs), 1,523 workflow events, 490 part numbers, 51 engines, 16 suppliers
Text	about 78,000 words of NCR prose, written in the register of a quality engineer
Hidden in the data	12 recurring problems across programs and divisions, each described in different words per NCR
Access	2 division groups, 20 program groups, 14 demo users with different scopes, a read-only guest
Graph	2,717 nodes and 14,933 edges, ingested in 24 seconds
AI	the NCR Quality Assistant with a workflow tool, a sandbox over the records, search and consult

The data 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, defense Europe, defense US, and the cross-program 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 started from the application template we used for the aviation market intelligence app: a working agreement, one skill per layer of a Curiosity Studio application, and a commented reference implementation of each layer. The working agreement sets the build order: corpus, connector, workspace configuration, endpoints and AI layer, front end. Each layer may only depend on one built before it.

The git history of the evening:

Time	Commit	What it contains
20:08	Initial commit	The template: skills, reference implementations, a sample application
20:42	Corpus, connector with access control, endpoints, front end	240 files: the data, the .NET connector, the workflow endpoints, the Transpose front end
21:11	Deploy and verify	Indexes, a definitions export and re-import, a Playwright end-to-end test of the workflow, the deployment record
21:50	Persona switching and the NCR Quality Assistant	The assistant, its tools and its sandbox; "View as a persona" for the presenter
22:18	Guest access, "Has this happened before?", assistant entry points	The similarity endpoint and its card, "ask" buttons on every record, the read-only guest

The pieces, and where each is documented:

• The connector, a .NET console application on Curiosity.Library, writes the records 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 program group.
• Endpoints, C# scripts stored in the workspace: the dashboard, the lists behind every tile, the NCR detail, raising an NCR, moving it on, the similar NCRs. Every read runs as the person calling it.
• The front end, 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: 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: 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 inquiry 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 organization (civil) or the customer's quality representative (defense); "Rework" or "Scrap" goes straight to corrective action. The endpoint creates the concession and the CAPA owned by the same groups as the product, so exactly the same people see them.

The same workspace, seen by fourteen people

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

As the quality engineer for one defense engine, the home page has one division, one program 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 the lists.

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 programs and sometimes both divisions, and each NCR describes its symptom in its own words: one 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 (part number, engine, supplier, defect code, 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 over the application's own endpoints: the dashboard, the queues, where an NCR stands, the similar NCRs, and moving an NCR on 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 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 programs and the answer is "I can't find that NCR in the records you can see": 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 programs?". 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 opens to show the script and what it printed.

The answer is a table of 14 suppliers behind 86 of the 109 open NCRs, by division and severity with the cost of quality, then 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 defense 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 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 offered to draft the lines of inquiry 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 belongs to one of the twelve planted recurring problems, at a different harness supplier, and the defense 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 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.

Which of these gaps matter for the manufacturer is something to settle 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.

Similar demos are at demos.curiosity.ai.