> ## 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.

# Traceability

> Per-product V-Model coverage, derived from your existing documents

<style>
  {`
      p, li {
        text-align: justify;
        text-justify: inter-word;
      }
    `}
</style>

## 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                        |

The Traceability panel inside [Audit Readiness](/user-guide/audit-readiness)
runs all of that through a pure-Python coverage computation and shows
you the result. Zero manual link maintenance.

## What you see

The panel renders one collapsible row per product (when you have
[products](/user-guide/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:

```
[Requirements] → [Architecture & Design] → [Verification & Validation]
```

Each level is one of three states:

| 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.                                                    |

The three categories map to the V-Model as:

* **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.

Each broken chain has a one-line description and a clickable indicator
to jump to the affected documents.

## 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:

1. It maps cleanly to the work product categories Conformly already
   tracks (no new schema)
2. It captures 80% of the audit value — most broken-chain failures
   happen at these three transitions, not within them
3. It's visually scannable for a FuSa manager checking weekly status

A more granular per-process view (with all 11 ASPICE processes split
out and explicit derives\_from edges from the [Knowledge Graph](/user-guide/knowledge-graph))
is on the roadmap. The data model already supports it; the UI
elaboration just hasn't been built yet.