Documentation Index
Fetch the complete documentation index at: https://docs.conformly.ai/llms.txt
Use this file to discover all available pages before exploring further.
Why traceability is non-negotiable
ASPICE and ISO 26262 are unambiguous: bidirectional traceability across the V-Model is the first thing an auditor asks for. Stakeholder needs trace down to system requirements, which trace down to software requirements, which trace down to architecture, which trace down to design, which traces down to code, which traces back up through unit tests, integration tests, and validation reports. ISO 26262 additionally demands traceability of safety requirements through ASIL decomposition all the way to verification evidence. Without it, you cannot demonstrate that your safety claims are grounded in actual work products. Most compliance tools handle this by asking you to manually maintain trace links — the “give me a 4000-row matrix to fill in” approach used by Polarion, Jama, and similar. That’s exactly the toil Conformly is designed to eliminate.How Conformly does it differently
Conformly’s traceability view is derived, not maintained. Every input it needs already exists in your data:| What traceability needs | Where Conformly already has it |
|---|---|
| What type each document is | category field, set by the auto-classifier on upload |
| What clauses each standard requires | Built into the AI pipeline’s process definitions |
| Which clauses are covered by which document | Every gap row links a clause to a work product |
| Which products own which documents | Set when you tag documents during upload |
| ASIL level per product | Set when you create the product |
What you see
The panel renders one collapsible row per product (when you have products defined) — or a single workspace-wide chain if you don’t. Each chain shows three V-Model levels in a left-to-right flow:| Status | Meaning |
|---|---|
| Covered (green) | At least one document of the matching category exists AND has been analyzed (has a compliance score). |
| Partial (amber) | Documents exist but none have been analyzed yet — upload happened, analysis didn’t. |
| Missing (red) | No document of this category exists in this scope. |
- Requirements → ASPICE SYS.2, SWE.1; ISO 26262-4 §6, ISO 26262-6 §6
- Architecture & Design → ASPICE SYS.3, SWE.2, SWE.3; ISO 26262-6 §7
- Verification & Validation → ASPICE SWE.4-6, SYS.4-5; ISO 26262-6 §9
Broken chains
Below the V-Model row, the panel shows a Broken chains section listing detected inconsistencies in adjacent levels. Two patterns are flagged:- Covered upstream + missing downstream: “Requirements present but no architecture document uploaded — downstream traceability cannot be verified.” This is the most common audit failure: you have requirements but no architecture to trace them to.
- Missing upstream + covered downstream: “Architecture present but no upstream requirements to trace back to — orphaned downstream artifact.” This means you have architecture without the requirements it should derive from. The architecture might be excellent, but the trace chain is broken.
Orphans
A separate Orphaned artifacts list shows specific documents that have no upstream parent in the V-Model. The most common case is test plans uploaded without the requirements they verify — the test documents are real, but they’re floating with no requirements to trace back to. Each orphan entry names the document and explains why it’s an orphan. The fix is usually to upload the missing upstream document, not to delete the orphan.How it scales for multi-product programs
If you have one product, you see one chain. If you have twelve products in one workspace, you see twelve chains, sorted worst-first (lowest coverage at the top, so the FuSa manager’s eyes go to the problems first). The first chain is expanded by default; the others are one-click expand. A workspace summary line at the top says “N products · M ready · K open issues” so you can see the rollup without expanding anything. If some of your work products don’t have a product tag yet, they appear in an Unassigned bucket at the bottom. Tag them by deleting and re-uploading with the product picker, or by editing the work product directly from the Documents page (planned).Why this is a v1, not the final word
The current panel deliberately uses three V-Model levels (Requirements → Architecture → V&V) rather than the full nine ASPICE process areas. That’s the right scope for v1 because:- It maps cleanly to the work product categories Conformly already tracks (no new schema)
- It captures 80% of the audit value — most broken-chain failures happen at these three transitions, not within them
- It’s visually scannable for a FuSa manager checking weekly status