Under the hood
A generated artefact is worth nothing at a gate review if you cannot say how it was produced, what it was checked against, and what happens to it when the requirement it came from changes. This page is about the machinery, not the output. What ASYST refuses to write, what it computes rather than generates, and what it records while it works.
Every stage declares the shape of its own output in code, and the result is checked against that schema before it is written anywhere. The check is executed, not requested of the model, and a stage that cannot produce a valid result raises an error rather than writing partial data.
Each stage names a schema object its output has to satisfy. Whether or not a given provider can be asked to honour that shape while generating, the check itself is a separate step afterwards, and it cannot be talked out of a failure.
The response is parsed as JSON, then validated against the stage schema. Both steps have to pass. A response that is valid JSON but wrong in shape fails here just as loudly as one that is not JSON at all.
On failure the model is called again with its own failed response, the exact validation errors naming each offending field, and the full schema re-injected. Not a vague instruction to try again. Two corrective passes are configured.
If both passes fail but a partial result survived, a final call asks for the fields that failed and merges them back for revalidation. If that fails too, or nothing parseable came back at all, the stage raises. It does not continue on incomplete data.
Two stages of the pipeline contain no language-model call at all. Component identification and traceability assembly are rule-based. This is deliberate, and it is the part of the system that matters most when someone asks you to justify a link.
Traceability is a graph query, not a generated document. Requirements, functions and components are written into the model as nodes with typed edges between them, and the chain is read back by traversing those edges: a requirement is satisfied by a function, which is allocated to a component. The same graph produces the same chain every time it is asked, because nothing is being composed. It is being read.
Component identification works the same way. Each approved subsystem becomes a component, each cross-subsystem interface recorded earlier becomes an interface, and each function's allocation is written into the model as an edge. There is no step at which a model is invited to decide what connects to what.
To be exact about what that does and does not buy you: the inputs both stages consume were produced earlier in the pipeline, several of them by a model. The linking is not. What an auditor pulls on is the part that was derived by rule.
The failure mode of a generative tool is not usually a wrong answer. It is a confident blank. ASYST is built so that the difference between nothing is wrong and nothing was checked is always visible.
The traceability report states how many requirements exist, how many are traced, how many are not, and lists the untraced identifiers by name. The number and the evidence for it arrive together.
Functions that carry no valid subsystem allocation are collected as gaps and recorded rather than dropped. Requirements carrying no verification entry are listed by identifier, not merely absent from a total.
Where a view depends on an artefact you have not generated, it says so and names the input it is missing, instead of rendering a reassuring zero. A count of zero means nothing was found. It never means nothing was looked at.
The same rule applies partway. The impact view needs requirements and functions to compute at all, and reads the V&V matrix, the risk register and the component edges to enrich what it shows. If one of those is missing, that dimension is flagged unavailable and the rest still computes. What it will not do is report the affected count as zero when the truthful answer is that the artefact does not exist yet.
This is the failure that quietly costs programmes money. The brief is amended, the derived artefacts are not, and nobody finds out until the two are read side by side at a review. ASYST holds a dependency graph over the pipeline stages. Updating the project brief flags every stage that derives from it as stale, following the chain the whole way down rather than one level, and records what caused it and when.
The edges are the load-bearing detail. Each one names the input that justifies it, set against the stage that actually reads that input rather than against whatever the orchestrator hands over. A stage given an input it never opens is not marked dependent on it: sub-system requirements do not invalidate the function stage, because that stage builds its own working list from the system requirements and never reads them. Two stages, the risk register and the V&V matrix, are terminal, so nothing hangs off them at all. An approximate graph would produce false staleness, and a tool that cries stale is one you learn to ignore.
Update the brief and these are the stages flagged:
The graph is asserted acyclic as it loads, so a bad edit to it fails immediately rather than hanging a request later. Regeneration is equally literal about what it can do: any stage that needs a model to be rebuilt comes back to you still marked as needing generation. It is not quietly marked fresh.
A run stops after it proposes the subsystem breakdown and persists that state as awaiting review. It does not carry on until somebody resumes it. That is where the gate belongs, because every artefact after it allocates to that breakdown: a requirement is allocated to a subsystem, a function is performed by one, a risk lands on one, an interface runs between two. Getting that wrong and finding out at stage eight is expensive.
Resuming past the gate is a distinct permission, not just an action available to whoever is logged in. An engineer can start runs, edit the brief and trigger regeneration, and cannot clear the gate. Owners and reviewers can. Viewers read only. The role that signs off the architecture is separated from the role that operates the tool, which is the arrangement your quality system almost certainly already assumes.
The approval is written to the audit record in a transaction of its own, so a dropped connection cannot take the record of it back out again.
Every language-model call in the system goes through one module. No stage, runner or workflow calls a provider SDK directly. That single boundary is what makes the provider a setting instead of a rewrite, and four are implemented behind it: OpenAI, Anthropic, Google, and Ollama against an endpoint set in your own deployment configuration. For an organisation that cannot send a project brief to a third-party API, that last option is the difference between a tool that can be assessed and one that cannot.
Prompts are held the same way. Each workflow has its own version-controlled prompt module holding the system and user templates for its stages, kept separate from the code that executes them. Changing how a stage is asked to do its job is a reviewable diff against a named file, with a commit history, rather than an edit buried in a runner.
Sign-in is through your existing identity provider: Microsoft Entra ID, Google or GitHub. ASYST issues no password of its own, so there is no credential for it to store, leak or make you rotate, and account deprovisioning stays where your IT function already manages it. Each provider flow uses PKCE, and the signature algorithms ASYST will accept on a returned token are pinned rather than read from the token itself.
Beyond sign-in, the actions that change a project are written to an audit record: creating, updating and deleting a project, adding and removing members, updating the brief, triggering regeneration, and starting or resuming a pipeline run. The record is append-only at the database grant rather than by convention, so the application can add rows to it and cannot amend or remove them.
Runs themselves are persisted rows carrying a status that advances as the pipeline progresses, through queued, running, awaiting review and completed, with cancelled and failed as terminal states. The history of how a model reached its present condition is queryable rather than reconstructed from memory.
Free while ASYST is in early access. The fastest way to judge the machinery is to run it on a programme you have already done by hand.
Start free