Traceability & change
Every item in Avera is versioned on one project timeline. Nothing is ever overwritten; every state your program was ever in can be read back, cited, and audited.
Every edit appends a version. History is complete by construction, not by discipline.
Controlled artifacts release at approved change levels (Rev A, Rev B); working items are tracked by version and baseline.
Ask what the program looked like at any point: for an audit, a submission, or an investigation.
Full-text and faceted search over every item, document, and link, scoped to the branch and moment you're looking at.
Every trace link is versioned and attributable, with its own history: what regulated traceability actually requires.
They bind the thing, not the version, so editing an item never orphans its trace.
When something upstream changes, every dependent link flags itself for re-verification; nothing silently rots.
"What does this change affect?" and "which fielded units does this touch?" are answers, not investigations.
Load the standards you own as clause trees; clauses link to the requirements, hazards, and tests that address them, with coverage per clause, live.
Formulas don't just compute over a row; they traverse your links. A risk priority resolves through the hazardous situation it belongs to; coverage and effectiveness roll up across whole chains.
A calculated field at work
Scores, roll-ups, and coverage are computed across connected items, not typed into cells: a value no one entered is a value no one forgets to update.
Change an input anywhere in the chain and every dependent value is current. Dashboards and worksheets never show yesterday's number.
At release, calculated values freeze into the signed version, exactly as shown. The live number and the signed number can never quietly disagree.
ISO 14971 risk scoring, verification coverage, effectiveness roll-ups: the worksheets a program runs on, driven by the graph.
A complaint on unit S/N 10412, or a market need worth a next version. Its lot, BOM revision, and design version are one query away.
Requirements, hardware design, BOM, risk file, documents, not just software. Next-gen work continues on main. Branching & variants →
Two risks to reassess, five verifications to re-run, the BOM revision, process risk and line validation, the work instruction, the submission per market, the affected units.
No to-do list for four other tools: the updated BOM revision, the line-revalidation protocol, the work-instruction update, and the submission section are the same items the impact pointed at, with AI drafting the volume work as proposals a named human approves. The impact list is the work list.
Rev D releases with its updated BOM and revalidated line. Each market's authorization record carries the decision: letter-to-file here, a new filing there. The updated submission content is ready, and release is gated where approval must come first.
The trace enumerates the affected units; the retrofit is recorded against each unit's device history; the complaint closes against the fix, or the market need ships. Nothing was rebuilt, re-keyed, or reconciled; it never left the system of record.
That loop is where device companies slow down and burn out. In one system of record, it's days.