Skip to main content

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.

​
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. 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:
1

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

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

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.”
Below those three, the page shows secondary information: per-phase risk distribution, remediation velocity sparkline, coverage strip, and the 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 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 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.