Module Architecture and Verification: The ValidKeep Atomic Model
The problem with many validation programs is not missing paperwork; it is two truths. Requirements live in one binder, design in another, tests in a third, and the running code quietly diverges. ValidKeep's High Assurance profile avoids that by storing each architectural idea as a small, linked artifact in Git, then compiling familiar CSV documents from those atoms when your quality unit expects them.
New here? If the ValidKeep platform stack (profiles, landscape, CLI, ValidKeep Hub) is unfamiliar, read the ecosystem map first. This article introduces atomic notation; for assurance profile options see Assurance profiles. For role isolation and the full specification, see the technical reference. Operational Qualification (OQ) and Performance Qualification (PQ) have dedicated articles once you know the symbols below.
One module at a time
Think of a regulated application as a tree of modules. Each module has an index $x$ (for example $0.2$ in module $M_{0.2}$). Everything below uses that subscript: $D_x$ means “the directive for module $x$,” not a generic letter C with a suffix.
ValidKeep separates four layers that CSV teams usually entangle:
- Demand (what the module must satisfy)
- Supply (what the module promises at its boundary)
- Implementation (how it is built inside the boundary)
- Evidence (how demand and implementation are proved)
Atomic elements (demand side)
On the demand side, obligations are authored as discrete fragments, not as one monolithic requirements chapter.
Rule fragment
One traceable obligation where $r \in O_x$. Each rule is a discrete heading, not a bullet lost in prose.
The full obligation set for module $x$ is the union of inherited directive and local requirements:
$O_x$ is what the module must satisfy. It drives the public interface and which black-box OQ tests are mandatory. Functional risk can be tagged per fragment so test depth follows CSA thinking rather than one-size-fits-all scripting.
Atomic elements (supply side)
To meet $O_x$, the module declares what it exposes and how it is built internally.
Source code
Physical implementation of $L_x$ in the repository.
A well-formed module matches obligations to capability:
Each rule $r$ is satisfied by a capability element $c$, designed in logic $l$, and realized in $CODE$. Traceability runs upstream from code to obligation: $CODE \rightarrow L_x \rightarrow C_x \rightarrow O_x$.
When module $x$ decomposes work into child modules, parent logic delegates directives $D_i$ and tools $B_i$, then integrates child capabilities $C_i$:
Read this as: local logic, parameterized by borrowed tools and child interfaces, produces the boundary capability auditors and integrators actually consume.
Fractal depth and evidence (pointers)
The same module physics repeat at every depth: balance law, trace chain, and separated OQ and PQ evidence. Container modules near the monorepo root delegate through $D_i$ and $B_i$; leaf modules carry application $CODE$. See the dedicated articles for depth:
- Fractal module model (ERP root vs TypeScript leaf, patterns, plug-and-play modules)
- OQ at the capability boundary (black-box proof of $O_x$ via $C_x$)
- PQ under load (white-box resilience of $L_x$ via ValidKeep Hub telemetry)
From atoms to traditional CSV documents
Quality units often ask for RS, FS, DS, and qualification protocols. In High Assurance those documents are rendered views compiled from the atomic files above, not a second source of truth you maintain by hand.
| Traditional artifact | Compiled from | What it represents |
|---|---|---|
| Requirement Specification (RS) | $\text{RS} = D_x \cup R_x \cup B_x$ | Problem space: mandates, stakeholder rules, and allocated tools |
| Functional Specification (FS) | $\text{FS} = C_x$ | Black-box interface the module promises |
| Design Specification (DS) | $\text{DS} = L_x \cup \left(\bigcup_i D_i\right) \cup \left(\bigcup_i B_i\right)$ | White-box logic plus delegated child mandates and tools |
| Test plans & cases | Native module files | OQ/PQ strategies and per-fragment test definitions stay first-class artifacts |
| Verification Report (VR) | ValidKeep Hub | Evidence that OQ drivers passed and PQ runs satisfied probe criteria under load |
Other assurance profiles swap node algebra and trace strictness while reusing the same ValidKeep engine. See Assurance profiles for GAMP5, SaMD, SOC2, and roadmap profiles.
How this supports CSA and CSV
Computer Software Assurance (CSA)
- Risk-based depth: obligation fragments carry functional risk; higher impact drives more rigorous OQ coverage.
- Live traceability: the graph from $O_x$ through $C_x$ to $CODE$ and tests replaces manually curated RTM spreadsheets.
- Separated evidence: black-box OQ for business rules, white-box PQ for implementation stress, both recorded in the ledger.
- Critical thinking preserved: role isolation keeps OQ authors from reading $L_x$, so tests prove the contract, not the developer's shortcuts.
Traditional CSV
When your quality unit expects classic deliverables, the same atomic model still applies. ValidKeep renders RS/FS/DS and traditional IQ/OQ/PQ protocol formats from the linked sources. You do not maintain parallel Word documents that drift from the repository.
Whether you lead with CSA or CSV, the underlying idea is the same: one governed graph in Git, familiar documents on demand, and qualification evidence that comes from executed tests and telemetry rather than attestations divorced from running software.