ASYST by STREaMLiNE
Start free

Under the hood

You will have to defend this model. Here is what holds it up.

A generated artefact is worth nothing at a gate review unless you can say how it was produced, what checked it, and what happens when its source changes.

Nothing reaches your project until it validates.

Every stage declares the shape of its output in code, and the result is checked against it before it is written anywhere.

  • Parsed as JSON, then validated against the stage schema
  • On failure, asked again with the exact validation errors, twice
  • Still failing after a final repair: the stage raises. It never writes partial data.

Model · Validation

Validation model: nothing is written until it validatesA stage generates output, which is checked against its declared schema. A pass writes to the project. A failure goes to a repair step carrying the actual validation error, which loops back to the stage, which generates again; if repair fails too, the stage raises and nothing is written. STAGE N generates SCHEMA declared shape writes REPAIR with the actual error RAISED never written through nothing reaches the project until it validates

The chain an auditor pulls on is computed, not written by a model.

Component identification and traceability assembly contain no language-model call. Traceability is a graph query, computed on demand, so it cannot drift.

  • Requirements, functions and components are nodes; relationships are edges
  • Each approved subsystem becomes a component, each recorded interface an interface
  • The inputs were partly model-generated. The linking is not.

Model · Computed traceability

Computed traceability modelREQ-014 is satisfied by FUNC-021 and FUNC-022 and allocated to COMP-007; FUNC-021 is verified by VV-014 and COMP-007 drives RISK-009. The chain is a query over these typed edges, computed on demand, not a document written once. REQ-014 FUNC-021 satisfied by FUNC-022 satisfied by COMP-007 allocated to VV-014 verified by RISK-009 drives SELECT … WHERE traced_to computed on demand

A gap is reported as a gap, and an absent stage is never reported as zero.

The failure mode of a generative tool is a confident blank. ASYST keeps nothing is wrong and nothing was checked apart.

  • Coverage states what is traced, what is not, and names the untraced
  • Orphans are counted and listed by identifier
  • A view missing its input says so, instead of showing zero

Model · Gap reporting

Gap reporting modelTraceability shows 100 per cent, 42 of 42 traced, in green. V and V shows 0 per cent in amber because the stage has not run. Three orphans, REQ-031, FUNC-018 and REQ-044, are listed by identifier, and a view whose input is missing says not computable rather than showing zero.coverage carries its own shortfall 100% traceability · 42 of 42 0% V&V · stage not run orphans, listed by identifier REQ-031 FUNC-018 REQ-044 NOT COMPUTABLE beats a reassuring zero
An ASYST project dashboard showing five panels: requirements by type, requirements by priority, a risk score distribution with eight likelihood-by-consequence bars, and two coverage dials reading V and V coverage 0 per cent in red and traceability coverage 100 per cent in green.
A real project, mid-flight. Traceability is complete at 100%; V&V is honestly 0% because that stage has not run. Neither is rounded into the other.

Change the brief and you are told exactly what is now out of date.

ASYST records what each artefact was generated from and flags what is now stale. Each edge names the input that justifies it.

  • Flagging follows the stage dependency chain all the way down
  • A stage that needs regenerating stays marked, never quietly fresh
  • The dependency graph is asserted acyclic as it loads

Model · Staleness

Staleness modelThe brief is amended to version 2. The requirement set and the functions were generated from version 1 and are flagged stale in amber; the risk register was generated from version 2 and is current. BRIEF v2 amended today what each artefact was built from REQ SET from BRIEF v1 STALE FUNCTIONS from BRIEF v1 STALE RISKS from BRIEF v2 the input behind every artefact is recorded

The decomposition is yours to approve before the run goes on.

A run stops after it proposes the subsystem breakdown, and persists as awaiting review.

  • Resuming is a distinct permission, not open to anyone signed in
  • The approval is written to the audit record in its own transaction

Model · Approval gate

Approval gate modelStage 1 context and stage 2 subsystems run, then an amber approval gate stops the run before stage 3. The run is persisted as awaiting review, and only the reviewer role can resume it. ROLE: reviewer STAGE 1 context STAGE 2 subsystems approval gate STAGE 3 waiting AWAITING REVIEW persisted as a run state, not held in memory

Which model runs it, and where, is configuration rather than architecture.

Every language-model call goes through one module. No stage holds its own client or its own key.

  • Prompts live in a version-controlled module per workflow
  • Changing how a stage is asked is a reviewable diff with a history

Model · One model gateway

Model gateway modelStages 2, 5 and 8 all call one gateway that owns every language-model call, which routes to model A, model B or an on-premises model. Prompts are versioned per workflow. No stage holds its own client or key. STAGE 2 STAGE 5 STAGE 8 ONE GATEWAY every LLM call model-a model-b on-prem PROMPTS: versioned per workflow no stage holds its own client or its own key

Who did what, on the record.

Sign-in through Microsoft Entra ID, Google or GitHub, with PKCE and pinned signature algorithms. ASYST stores no passwords.

  • Project, member, brief, regeneration and run actions are written to an audit record
  • Append-only at the database grant, not by convention
  • Runs are persisted rows: queued, running, awaiting review, completed, cancelled or failed

Model · Audit record

Audit record modelFour audit rows, LOG-011 to LOG-014: an engineer created the project and updated the brief, a reviewer approved the subsystems and resumed the run. The record is append-only, enforced by a database grant of insert with no update and no delete.who did what, on the record LOG-011 created project engineer LOG-012 updated brief engineer LOG-013 approved subsystems reviewer LOG-014 resumed run reviewer APPEND ONLY GRANT: insert no update, no delete · enforced by the database

Every capture on this site comes from one real project.

The Autonomous Warehouse Inspection Drone, generated by ASYST from a brief and live in production, gaps still in it.

An ASYST traceability graph starting at requirement SYS-F-016, a timestamping requirement, verified by VV-SYS-F-016 and satisfied by FUNC-017, fanning right through functions FUNC-024, FUNC-016-01, FUNC-016-02, FUNC-035 and FUNC-012 into eleven components from COMP-001 to COMP-012, with each edge labelled verified by, satisfied by, triggers, traced to, allocated to or interfaces with.
One requirement traced to the eleven components it reaches. Open the project and the same chain is navigable in either direction.

Open the live project

Sign in with GitHub, Microsoft or Google. The free tier covers the whole nine-stage pipeline.

Test it against a brief you already know the answer to.

Free while ASYST is in early access. Run it on a programme you have already done by hand.

Start free
Next 03Pricing

Free during early access, and what the tiers become at general availability.