Workstreams

Workstreams are AI-powered workflows that analyse documents and generate architectural outputs. They reduce the manual effort of creating architecture documentation, designs, and reviews. You will find Workstreams in the left sidebar.

Workstream Types

Type	What It Does
New Design	Generate an architecture design from business requirements, standards, and existing context objects
Reverse Engineer	Extract architectural elements from existing system documentation
Forward Engineer	Generate implementation documentation from an architecture model
Design Review	Assess a technology design against best practices, requirements, or internal standards

Design Types

When you start a New Design, the first step is choosing a design type: the kind of document you want to produce:

Design Type	What It Produces
Solution Blueprint	An end-to-end solution design document: context, requirements, target design, diagrams, and decisions.
Solution Pattern (coming soon)	A reusable solution pattern: the problem, its context and forces, and the proven design that resolves them.
Key Design Decision (coming soon)	A single significant decision: context, options considered, the decision, and its consequences.

Each design type pairs with a default template. You can also supply your own template at the Custom Template step to control the structure of the output.

Providing Context

Workstreams accept three kinds of input. Combine them to give the AI the richest possible context:

• Upload documents: PDF, DOCX, PPTX, TXT, MD, XML, or HTML files containing requirements, standards, or architecture documentation
• Add URLs: Web pages to fetch and analyse
• Select context objects: Existing objects from the Repository to provide architectural context

Running a Workstream

1. Navigate to Workstreams in the left sidebar.
2. Select the workstream type.
3. Provide inputs (documents, URLs, context objects).
4. Start the workstream.

The workstream runs as a background job. You can monitor its progress on the Jobs page.

What Workstreams Produce

Depending on the type and inputs, a workstream can generate:

• Architecture diagrams: Rendered from PlantUML in formats such as Cloud Architecture, Flowcharts, Sequence Diagrams, ERD, BPMN, Context Diagrams, and Component Diagrams
• Objects and associations: Extracted elements are created in the Repository for review
• Requirements traceability report: A matrix mapping each input requirement to the design elements that satisfy it (see below)
• Coverage assessment: A summary of how completely the generated design addresses the supplied requirements, standards, and context (see below)
• Assessment summaries: For design reviews, a structured evaluation of gaps, risks, and recommendations
• Generated documents: Downloadable from the Jobs page

Requirements Traceability and Coverage

Every workstream that produces a design (New Design, Reverse Engineer, Forward Engineer, and Design Review) generates a requirements traceability report and a coverage assessment alongside the design artefacts.

Requirements Traceability Report

The traceability report extracts the discrete requirements, constraints, and standards from your inputs (uploaded documents, URLs, and context objects) and maps each one to the design elements that address it.

For each requirement, the report shows:

• Requirement ID and source: Where the requirement came from (which document and section, URL, or context object)
• Requirement statement: The extracted requirement text
• Type: Functional, non-functional, constraint, standard, or assumption
• Linked design elements: The diagrams, objects, associations, or document sections that satisfy the requirement
• Status: Satisfied, partially satisfied, or unaddressed

This view makes it easy to demonstrate to stakeholders that the design has considered every input and to drill into the specific element that addresses a given requirement.

Coverage Assessment

The coverage assessment summarises the traceability data into a single quality view of the design:

• Coverage score: The proportion of input requirements that are fully satisfied by the generated design
• Gaps: Requirements that are unaddressed or only partially addressed, with suggested follow-up actions
• Assumptions: Statements the AI inferred where source material was ambiguous or missing
• Out-of-scope items: Inputs that were deliberately excluded from the design, with reasoning

The coverage assessment is included in the generated design document and is also available as a standalone report from the Jobs page.

Reviewing Results

After a workstream completes, review the generated outputs on the Jobs page before they are committed to the Repository. Use the traceability report and coverage assessment to validate that the design addresses your requirements before publishing.

Grounded in Your Model

Workstreams do not generate in a vacuum. They are grounded in the knowledge already in your workspace: the approved guidance in your Reference Library, the objects and relationships in your Repository, and the context you supply. Relevant context is retrieved semantically and fed to the design so outputs align with your standards and existing landscape.

When a generated design conflicts with established guidance, ArchNGN can flag the deviation and propose a corresponding Architecture Decision for review, so divergences are captured rather than lost.

Token Usage

Workstream jobs consume AI tokens from your account allowance. Token costs vary depending on the AI mode selected. For a full breakdown of costs by job type and AI mode, see Usage.