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

# Audit Readiness

> The home view for Functional Safety Managers and Quality Directors

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

## Who this page is for

Audit Readiness is the page designed for the **Functional Safety Manager**
and the **Quality Director** — the people who don't upload documents
or triage individual findings, but who own the question "are we
audit-ready?" and need to answer it confidently every Monday morning.

If you're an engineer working on remediation, you spend more time on
[Findings](/user-guide/findings). If you run the program, you live on
this page.

## What it answers in three seconds

The page is laid out to answer three questions in order:

<Steps>
  <Step title="Are we audit-ready?">
    A single big number: the overall audit-readiness score (0-100).
    Color-coded: green ≥80 (ready), amber ≥60 (at risk), red \<60 (blocked).
  </Step>

  <Step title="What's blocking us?">
    The Top 5 Blockers list — the highest-severity open findings,
    sorted by severity then age. Each is one click to its full context.
  </Step>

  <Step title="When can we be ready?">
    A timeline projection: "X weeks at current velocity" — based on the
    actual rate at which your team has been resolving findings over
    the last 4-8 weeks. If velocity is zero, the projection says
    "Not enough resolution data to project."
  </Step>
</Steps>

Below those three, the page shows secondary information: per-phase risk
distribution, remediation velocity sparkline, coverage strip, and the
[Traceability](/user-guide/traceability) panel.

## How the score is computed

The audit-readiness score uses the same penalty math as the per-document
compliance score, applied to **all open findings in the workspace**:

```
score = 100 - sum(severity_penalty for each open finding)
where penalties: critical=15, high=8, medium=4, low=2
```

Resolved and Accepted findings don't deduct. The score is clamped to
0-100. This is the unified scoring module — same algorithm everywhere,
no per-page reinventions.

When you have [products](/user-guide/products) defined, the score is
computed per product and rolled up. The overall workspace number is
the average across all products.

## The blockers list

"Blockers" means findings that would prevent an audit from passing —
specifically, **Critical and High severity findings in Open or In
Progress state**. Medium and Low findings are real and worth fixing,
but they don't block.

The list shows the top 5 by severity then age (oldest critical first,
since that's the one most likely to be missed). Each entry has:

* The finding title
* The standard clause it violates
* Severity badge
* Source document name
* A "Review →" button that jumps directly to the finding's full context

If you have more than 5 blockers, click "View all blockers" at the
bottom to see the full filtered Findings page.

## Velocity and the timeline projection

Conformly tracks how many findings your team resolves per week, over a
rolling 4-8 week window. The result is your **resolution velocity** —
e.g. "8.3 gaps/week."

The timeline projection divides remaining blockers by velocity:

```
weeks_remaining = blocking_gaps / avg_weekly_velocity
projected_date = today + weeks_remaining
```

So if you have 24 blocking gaps and a velocity of 8/week, the projection
says "\~3 weeks at current velocity (8.0 gaps/week)" with a concrete
projected date.

This is intentionally a rough projection, not a precision plan. It's
designed for the conversation **"can we book the audit for next month?"**
The answer is "yes if velocity holds, no if it drops, here's the data."

If your velocity is zero (nobody has resolved anything in the rolling
window), the projection says "Not enough resolution data to project"
and gives no date. That's a deliberate choice — making up a number
in that case would be misleading.

## Risk by phase

A stacked bar chart showing critical/high/medium/low counts per V-Model
phase. Phases come from your work product categories
(requirements / architecture / testing / documentation).

Use this to spot **systemic problems** rather than individual gaps.
A spike of high findings in the architecture phase means your
architecture documentation is the weak link, not your test plans.
That's a different remediation strategy than fixing 12 unrelated
findings one at a time.

## Coverage strip

Two progress bars at the bottom of the page:

* **Standards checked** — how many of your selected standards have
  actually been used in at least one analysis
* **Work products analyzed** — how many of the documents in your
  workspace have a compliance score (vs uploaded but not yet analyzed)

These are the "did you actually do the work?" indicators. Even if your
score is 100%, if Standards checked is 1/3 and Work products analyzed
is 2/15, the score isn't a real readiness signal — it's just the score
of the stuff you did look at.

## Traceability coverage

The bottom of the page shows the [Traceability](/user-guide/traceability)
panel — V-Model coverage per product. ASPICE and ISO 26262 require
bidirectional traceability across the V-Model, and this is where
auditors will start. Conformly derives the coverage automatically from
your existing documents, so there's nothing manual to maintain.

## Why the page is read-only

Audit Readiness has no edit actions. By design. The role of the FuSa
manager is to **see the truth and make decisions about it** — not to
poke at individual findings. Every link on the page jumps to the
appropriate edit surface (Findings page, individual finding, document
viewer), but the readiness page itself never modifies anything.

The one action button on the page is "Review findings" which navigates
to the filtered Findings list.