OQ at the Capability Boundary

Validation methodology 9 min read

New here? ValidKeep governs regulated software with linked atomic files in Git and deterministic npx validkeep verify (no LLM in the audit path). Optional ysbuild helps author specs; verify is the impartial gate either way.

Start with the ecosystem map for the platform stack (assurance profile, landscape profile, CLI, ValidKeep Hub). Then read the atomic model ($D_x$, $R_x$, $C_x$, $L_x$) if notation like $C_x$ is unfamiliar. Operational Qualification (OQ) and Performance Qualification (PQ) are explained in their own articles.

Operational Qualification (OQ) proves demand ($O_x$) by exercising only the black-box boundary $C_x$. OQ test authors stay blind to $L_x$ and implementation so tests cannot mirror developer shortcuts. Each OQ case traces to rule fragments in $O_x$ through sidecar joins enforced at npx validkeep verify time. See the atomic model for notation.

Operational Qualification treats the module as a black box: active drivers interact with the C_x perimeter only.

OQ at the capability boundary only

Pattern 12 in the architecture model forbids OQ drivers from reaching into logic or CODE. Active test scripts call the published $C_x$ interface (HTTP handlers, CLI commands, exported functions) exactly as an integrator would. If a rule lives in $R_x$, an OQ case must demonstrate it through observable boundary behavior.

OQTS and OQ test chain

*.oqts.md: strategy per module (risk-based depth, coverage posture)
*.oqtest.md: isolated case specs with fragment joins to $r \in O_x$
oqtscode / oqtestcode: harness and executable runners

The ysbuild oqtest role operates at tree scope but remains blind to $L_x$. It sees $C_x$ signatures and obligation headings sufficient to author black-box drivers.

Fractal slice

OQ runs per module, not once per release monolith. Module $M_{0.2}$ (pediatric calculator) carries its own OQ suite proving its $O_{0.2}$ via $C_{0.2}$; parent $M_0$ may add integration-level OQ that composes child capabilities without re-testing internal leaf rules already proven downstream.

CR-101 example

Adding a neonatal dose cap: new rule fragment in calc.rx.md, updated capability in calc.cx.md, new case calc-neonatal.oqtest.md driving boundary inputs that should reject out-of-range orders. npx validkeep verify ensures the case joins the rule heading; ValidKeep Hub records execution on the devcr cycle.

Contrast with PQ

OQ answers “Does the module meet stated obligations at the boundary?” PQ answers “Does internal design survive stress?” Keep them separate for CSA credibility. See PQ under load.

Anti-reach: keep tools out of $C_x$

$C_x$ describes business inputs, outputs, and errors. Database clients, HTTP pools, and service locators belong in $B_x$; wiring belongs in $L_x$. If $C_x$ lists infrastructure types, OQ drivers must mock inside black-box tests and integrators inherit hidden coupling.

Assurance parsers flag tool-like tokens in $C_x$ where anti-reach applies. Route fixes to bx or lx, not cx.