Local Witness Checklist¶
Validation protocol — instantiates Patchwise Global Certification
Defines what counts as valid evidence that the global property holds inside one patch, and records it the same way everywhere, so patch verdicts are comparable.
The Local Witness Checklist defines, for a single patch, what counts as valid local evidence that the global property holds there — and standardizes how that evidence is recorded so that witnesses from different patches can be compared. It is the per-patch acceptance criterion together with its record schema. It says nothing about how patches fit together at their edges — that is the overlap test — and nothing about whether the patches cover the whole — that is the audit. It governs what happens inside one patch, translating the abstract global property P into a concrete local pass or fail that can be logged, provenanced, and later combined.
Example¶
A semiconductor fab wants to certify a finished wafer as "every good die meets spec." It cannot test "the wafer" as one object; it tests each die. The Local Witness Checklist fixes exactly what a valid witness for a single die is: probe this set of pads, apply these voltage and timing conditions, and bin the die PASS only if every parametric measurement sits inside the window derived from the chip's specification — then record die coordinate, bin, and the measured margins in a fixed schema. Two design choices carry the weight. First, the local criterion is derived from the global property: the die-level test is the chip spec P translated to one die. Second, every die is recorded identically, so a die at the wafer's edge and one at its center emit comparable witnesses. When the checklist runs across the wafer, each die produces a standardized record. It has said nothing about how neighboring die interact along the kerf; a die can pass in isolation and still misbehave as part of a shared structure — a seam question the checklist deliberately never touches.
How it works¶
- Translate the property. Turn the global claim
Pinto a concrete acceptance criterion for one patch. - Fix the witness type and threshold. Decide whether the witness is a test, a proof, a measurement, an inspection, or an expert judgment, and set the bar it must clear.
- Standardize the record. Define one schema so witnesses from different patches are comparable or explicitly translatable — the load-bearing choice, because incomparable records cannot be safely aggregated.
- Emit a record per patch. Output pass/fail plus supporting evidence and provenance, one record per patch.
Tuning parameters¶
- Criterion strictness — a tighter local threshold catches more marginal defects but rejects patches that were good enough; it trades yield against escapes.
- Evidence depth — a quick check versus an exhaustive one; more depth makes each witness more credible and each patch more expensive.
- Standardization degree — how uniform the record schema is across patches: uniform records aggregate cleanly, flexible ones capture local nuance but risk incomparability.
- Witness type — proof versus test versus expert judgment, chosen per patch to match what evidence that patch can actually yield.
When it helps, and when it misleads¶
Its strength is that it makes local evidence uniform and combinable. Without a shared criterion and schema, patch verdicts arrive in different currencies and cannot be safely combined into anything global; the checklist is what earns the right to aggregate later.
Its failure mode is a witness that passes without actually witnessing P — a proxy that correlates with the property but is not it, so a patch is stamped good on evidence that does not track the real claim. This is a construct-validity gap.[n1] The classic misuse compounds it: treating "every patch passed my checklist" as the global verdict, when coverage, seams, and the aggregation rule all still stand between local passes and a whole. The guarding discipline is to run an informal self-check that the local criterion genuinely tracks P, and to keep the checklist's output as an input to certification rather than the certificate.
How it implements the components¶
local_witness_record— its core output: the standardized, provenanced per-patch pass/fail evidence.global_verdict_target— it translates the global propertyPinto the local acceptance criterion; it fills the property half of the target that each patch is tested against.
Does not implement overlap_compatibility_condition — whether two patches' witnesses agree where they meet is checked by Overlap Compatibility Test, its nearest twin. The checklist validates the inside of one patch; the overlap test validates the seam between two.
Related¶
- Instantiates: Patchwise Global Certification — the checklist produces the local witnesses the rest of the pattern combines.
- Consumes: Patch Cover Inventory supplies the patch set the checklist is run against.
- Sibling mechanisms: Patch Cover Inventory · Overlap Compatibility Test · Gluing or Recomposition Workflow · Obstruction Register Review · Coverage Completeness Audit · Global Certificate Template · Local-to-Global Dashboard
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Local Witness Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it defines what counts as valid evidence that the global property holds inside one patch, and records it the same way everywhere, so patch verdicts are comparable.
Independent corroboration: The frozen evidence defines Local Witness Checklist as 'Defines what counts as valid evidence that the global property holds inside one patch, and records it the same way everywhere, so patch verdicts are comparable', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Per-unit acceptance tests and standardized inspection evidence originate in engineering quality assurance and verification.
Related originating lineages:
- Accounting & Auditing — Assurance practice contributes standardized evidence records that can be combined into a broader conclusion.
- Mathematics — Patchwise proof and local witnesses for global properties originate in mathematical local-to-global reasoning.
- Statistics & Experimental Design — Construct-valid tests and comparable measurements materially shape what counts as admissible local evidence.
Review resolution: Light authoritative research supports engineering_design as the primary provenance: Per-unit acceptance tests and standardized inspection evidence originate in engineering quality assurance and verification. NASA engineering guidance uses per-criterion checklists and objective test evidence for acceptance and verification. The competing reviewed lineage (mathematics) and other formative traditions remain explicit alternates rather than being erased or confused with downstream applicability. origin_mode=cross_disciplinary_synthesis records the relationship among those origin traditions, while domain_reach=universal separately records how broadly the generalized mechanism can be applied.
Attribution caveat: The local-to-global certification framing is an encyclopedia synthesis, while the checklist mechanics are established QA practice. The checklist is an encyclopedia operationalization of a mathematical certification pattern.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
- https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695413/SWE-034%2B-%2BAcceptance%2BCriteria — NASA engineering guidance uses per-criterion checklists and objective test evidence for acceptance and verification.
Notes¶
[n1] Construct validity is the degree to which a test actually measures the concept it claims to measure. A local witness with poor construct validity passes patches that do not truly have property P — the checklist's central risk, and why the criterion must be checked against P, not just against convenience. ↩