SecondMark position
The unit of consequence is the operating system: code, models, data, infrastructure, operators, controls, state, and environment acting together.
The examination is bounded to defined claims, a versioned system, and evidence that can be traced to the state under review. Any material exclusion or uncertainty remains visible in the conclusion.
Core questions
What the examination needs to establish.
- 01
Which claims can source establish directly?
- 02
Which behaviors emerge only at runtime?
- 03
Where do configuration and authority escape repository review?
- 04
How should static evidence connect to production evidence?
Evidence model
Evidence is assembled around the claim—not the folder structure.
Explicit definitions
Collected, attributed, challenged, and connected to the exact system boundary under examination.
Reasoned assurance principles
Collected, attributed, challenged, and connected to the exact system boundary under examination.
Practical system implications
Collected, attributed, challenged, and connected to the exact system boundary under examination.
Boundaries and counterexamples
Collected, attributed, challenged, and connected to the exact system boundary under examination.
Intended outcome
A clearer distinction between code quality evidence and system assurance evidence, with each used only for the claims it can actually support.
Professional boundary
What an opinion does—and does not—mean.
It provides
A traceable independent conclusion on defined claims, grounded in the evidence and system state examined.
It does not provide
A guarantee that failure is impossible, a permanent certification, or a conclusion beyond the stated scope and validity conditions.