Module: B12 — Harness Security Assessments as a Service Diagram count: 5 Tool: Mermaid (primary). Each diagram validated in Mermaid Live Editor.
Type: Cyclic flowchain Purpose: The backbone of the module. An agent security assessment is a loop, not a pipeline — six phases that feed back into each other across releases. Each phase ties to the prior module that supplies its content. The diagram makes the capstone synthesis visible: B0 (scope), B1 (recon), B9+B10 (discovery), B0 (validation), B9 output (report), B0.2 (retest). A retest feeds the next engagement's scoping. Reading the diagram: Read clockwise as the engagement cycle. The dashed arrow from Retest back to Scoping is the recurring-engagement loop — the long-term value of the service. The teal callouts mark the module that supplies each phase's content.
flowchart LR
P1["1. SCOPING<br/>surfaces · model versions<br/>provider authorizations · exclusions<br/>→ SOW + scope file"]:::phase
P2["2. RECONNAISSANCE<br/>map the agent's surfaces<br/>B1 threat-model template<br/>B10 capability disclosure"]:::phase
P3["3. DISCOVERY<br/>B9 OWASP checklist (10 rows)<br/>B10 attack chains (7 modes<br/>+ zero-click HITL bypass)"]:::phase
P4["4. EXPLOITATION / VALIDATION<br/>B0 minimum-proof discipline<br/>reproduce · measure N/M<br/>evidence field set"]:::phase
P5["5. REPORTING<br/>exec summary · findings<br/>control matrix · roadmap<br/>= B9 scored output packaged"]:::phase
P6["6. RETESTING<br/>same harness · same sampling<br/>same pinned version<br/>residual risk before/after"]:::phase
P1 --> P2 --> P3 --> P4 --> P5 --> P6
P6 -. recurring engagement .-> P1
M1["B0 legal control plane"]:::mod
M2["B1 threat model"]:::mod
M3["B9 checklist + B10 chains"]:::mod
M4["B0 minimum-evidence"]:::mod
M5["B9 executor output"]:::mod
M6["B0.2 residual-risk"]:::mod
P1 -. supplied by .-> M1
P2 -. supplied by .-> M2
P3 -. supplied by .-> M3
P4 -. supplied by .-> M4
P5 -. supplied by .-> M5
P6 -. supplied by .-> M6
classDef phase fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
classDef mod fill:#101018,stroke:#f0a868,color:#f0a868
Note: Only two of the six phases (Discovery + Validation) are the testing that B9 and B10 supply. Scoping is where the legal plane gets set; Reporting is where the output becomes a deliverable; Retesting is where the residual gets measured. An engagement that runs only the testing phases is "run B9 and hand over the output" — half an engagement.
Type: Process flow with mandated clauses Purpose: Scoping is where B0's legal control plane gets written into the engagement contract. The four-point surface enumeration (B1 template, model versions, provider authorizations, exclusions) flows into the SOW, which must carry B0's seven clauses — three of them AI-specific (provider authorization, dual-use/disclosure, DMCA waiver). An SOW missing any clause fails at the moment a serious finding appears. Reading the diagram: Top = the scoping enumeration. Middle = the SOW with its seven clauses. The red callouts mark the three AI-specific clauses a traditional pentest SOW does not carry. The provider-authorization check is a gating step — surfaces that fail B0's three conditions are out of scope until the gap closes.
flowchart TB
subgraph ENUM["SCOPING — four-point surface enumeration"]
direction TB
E1["SURFACES (B1 template)<br/>inputs · tools · memory · provider<br/>identity · sandbox · inter-agent edges"]
E2["MODEL VERSIONS (pinned)<br/>gpt-model-v3-2026-05-01<br/>claude-opus-4-1-20260605"]
E3["PROVIDER AUTHORIZATIONS<br/>per technique: ToS / waiver / self-hosted"]
E4["EXCLUSIONS<br/>prod PII · shared infra<br/>forbidden techniques"]
E1 --- E2 --- E3 --- E4
end
GATE{"provider_authorization<br/>check (B0)"}
BLOCK["OUT OF SCOPE<br/>until gap closes"]:::danger
ALLOW["IN SCOPE"]:::good
ENUM --> GATE
GATE -->|"all 3 conditions fail"| BLOCK
GATE -->|"≥1 condition holds"| ALLOW
subgraph SOW["SOW — seven clauses (B0 + B12)"]
direction TB
C1["1. Systems in scope (pinned versions)"]
C2["2. PROVIDER AUTHORIZATION / ToS compliance"]:::ai
C3["3. Techniques permitted / prohibited<br/>(weight-read = minimum-proof only)"]
C4["4. DUAL-USE & DISCLOSURE<br/>180d model-level · 90d harness-level<br/>recipe suppressed by default"]:::ai
C5["5. DMCA § 1201 WAIVER<br/>(if bypassing a model access control)"]:::ai
C6["6. Data handling<br/>(Public / Provider-Only /<br/>Restricted / Destroy-on-Report)"]
C7["7. Residual-risk measurement protocol<br/>(never binary 'fixed')"]
end
ALLOW --> SOW
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
classDef ai fill:#101018,stroke:#f08080,color:#f08080
style ENUM fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style SOW fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style GATE fill:#101018,stroke:#f0a868,color:#f0a868
style C1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style C3 fill:#101018,stroke:#5eead4,color:#e4e4e8
style C6 fill:#101018,stroke:#5eead4,color:#e4e4e8
style C7 fill:#101018,stroke:#5eead4,color:#e4e4e8
Note: The three red clauses (provider authorization, dual-use/disclosure, DMCA waiver) are the AI-specific additions to a traditional pentest SOW. A client's counsel signs this before testing begins; the clauses resolve B0's risks contractually rather than in the moment. The provider-authorization check at the top is a gating step — it is the engineering realization of "the deployer cannot authorize what the provider forbids."
Type: Section map / data flow Purpose: The report is the deliverable, and it is the same scored artifact B9's checklist executor produces — formatted into five sections a CISO can read and a regulator can audit. The diagram shows how the B9 output and B10 chains flow into the findings section, how the B9 risk-to-module mapping becomes the control matrix, and how the report generator (lab) enforces the field set. Reading the diagram: Left = the inputs (B9 executor JSON, B10 chain findings, B1 surface map, B0 scope). Middle = the five report sections. Right = the validation layer that refuses to ship an unclassified or incomplete finding.
flowchart LR
subgraph IN["INPUTS"]
direction TB
I1["B9 CHECKLIST EXECUTOR<br/>8 PASS/FAIL + 2 MEASURED<br/>(JSON)"]
I2["B10 CHAIN FINDINGS<br/>7 modes + zero-click HITL<br/>bypass chain"]
I3["B1 SURFACE MAP<br/>(reconnaissance output)"]
I4["B0 SCOPE FILE + SOW<br/>(the authorization plane)"]
end
subgraph REPORT["ENGAGEMENT REPORT — 5 sections"]
direction TB
S1["1. EXECUTIVE SUMMARY<br/>residual posture · findings count<br/>ship recommendation (never 'secure')"]:::sec
S2["2. FINDINGS<br/>taxonomy ref · attack procedure<br/>evidence · residual risk · remediation"]:::sec
S3["3. CONTROL MATRIX<br/>controls × surfaces<br/>Present / Absent / Partial / Mismeasured"]:::sec
S4["4. REMEDIATION ROADMAP<br/>prioritized · routed to B2-B8<br/>owner + effort estimate"]:::sec
S5["5. APPENDIX<br/>methodology · scope · evidence index"]:::sec
end
subgraph VAL["VALIDATION (report generator)"]
direction TB
V1["finding with no taxonomy ref<br/>→ REJECTED"]:::danger
V2["MEASURED without success rate<br/>→ REJECTED"]:::danger
V3["Critical without remediation<br/>→ REJECTED"]:::danger
end
I1 --> S2
I2 --> S2
I3 --> S3
I4 --> S5
S2 -. enforced by .-> VAL
I1 -. risk→module map .-> S3
S2 -. routes to .-> S4
classDef sec fill:#14141f,stroke:#5eead4,color:#e4e4e8
classDef danger fill:#101018,stroke:#f08080,color:#f08080
style IN fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
style REPORT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style VAL fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
Note: B9's checklist executor output is the findings section's backbone. B12 does not re-test; it packages. The validation layer is what prevents the "10/10 PASS" lie — the report generator refuses to emit a finding that lacks a taxonomy reference, a MEASURED finding without a success rate, or a Critical finding without a remediation route. The strictness is the honesty, enforced at the output layer.
Type: Comparison / measurement Purpose: Retesting measures residual risk, not binary "fixed." The same harness, the same sampling parameters, the same pinned model version, re-run after remediation. The verdict is Resolved / Improved / Unchanged / Regressed — never "fixed." The diagram shows the before/after comparison and the four verdicts, plus the regression risk (a B10 chain may reroute through a different gap after a patch). Reading the diagram: Left = the original assessment residual. Middle = the retest under identical conditions. Right = the four possible verdicts. The red path (Regressed) is why the retest re-runs discovery, not just the original finding — a patch can open a new gap.
flowchart TB
ORIG["ORIGINAL ASSESSMENT<br/>Finding F-04: injection success<br/>60% over 100 attempts<br/>(pinned model · sampling params)"]
RETEST["RETEST — identical conditions<br/>same B9/B10 test cases<br/>same sampling params<br/>same pinned model version"]
COMPARE{"compare<br/>before / after"}
ORIG --> RETEST --> COMPARE
V1["RESOLVED<br/>residual → 0%<br/>(deterministic control added)"]:::good
V2["IMPROVED<br/>60% → 4%<br/>(mitigation reduced,<br/>did not eliminate)"]:::warn
V3["UNCHANGED<br/>60% → 60%<br/>(remediation ineffective)"]:::danger
V4["REGRESSED<br/>a PASS row → FAIL<br/>or chain rerouted<br/>through a new gap"]:::danger
COMPARE --> V1
COMPARE --> V2
COMPARE --> V3
COMPARE --> V4
NOTE["The verdict is NEVER 'fixed.'<br/>The retest report is a delta document:<br/>original residual · post-remediation residual · verdict.<br/>A regulator reads it to verify the client fixed<br/>what they said they fixed."]:::note
COMPARE --> NOTE
classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef note fill:#101018,stroke:#5eead4,color:#5eead4
style ORIG fill:#14141f,stroke:#5eead4,color:#e4e4e8
style RETEST fill:#14141f,stroke:#5eead4,color:#e4e4e8
style COMPARE fill:#101018,stroke:#f0a868,color:#f0a868
Note: "Is it fixed?" is the wrong question; the answer is never yes. The right question is "did the residual move, and by how much, under identical conditions?" The Regressed verdict (bottom) is why the retest re-runs the full B9 checklist and re-attempts the B10 chains — patching one step of a chain can reroute it through a different gap. A retest that checks only the original finding misses regressions.
Type: Layered stack Purpose: The difference between a one-off assessment (a project) and a repeatable assessment practice (a service) is packaging. Four layers — methodology, tooling, templates, evidence — make the engagement run the same way across clients and releases. Comparability across releases is the long-term value a CISO buys. Reading the diagram: Read bottom-to-top as the layers that make the practice repeatable. The evidence layer (B0 + B11) makes it defensible; the template layer makes it consistent; the tooling layer makes it scalable; the methodology layer is the playbook. Drift in any layer breaks the comparability that makes the residual-trend-over-releases valuable.
flowchart BT
L1["METHODOLOGY LAYER<br/>the six-phase playbook<br/>phase → module mapping<br/>(PTES / NIST SP 800-115 adapted)"]:::layer
L2["TOOLING LAYER<br/>B9 checklist executor · B10 chain harness<br/>report generator (B12 lab)<br/>scope-file validator (B0 lab)"]:::layer
L3["TEMPLATE LAYER<br/>SOW (7 clauses) · scope file<br/>report (5 sections) · retest delta<br/>CVD timeline (B0 lab)"]:::layer
L4["EVIDENCE LAYER<br/>B0 evidence store (4 retention classes)<br/>B11 audit trail · B11 AI BOM<br/>the defensible foundation"]:::layer
L4 --> L3 --> L2 --> L1
OUT["COMPARABLE ARTIFACTS ACROSS RELEASES<br/>injection success rate over 6 releases<br/>the long-term value the CISO buys"]:::out
L1 --> OUT
classDef layer fill:#14141f,stroke:#5eead4,color:#e4e4e8
style L1 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style L2 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style L3 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style L4 fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
classDef out fill:#101018,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
Note: The evidence layer (B0's retention classes + B11's audit trail and AI BOM) is the foundation — it is what makes every finding trace to scoped, authorized, minimum-proof evidence that survives a regulator's review. Without it, the layers above produce artifacts that cannot be audited. The methodology is a cycle, not a pipeline: a static playbook document is the cycle frozen at phase 1.
# Diagrams — Module B12: Harness Security Assessments as a Service
**Module**: B12 — Harness Security Assessments as a Service
**Diagram count**: 5
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).
---
## Diagram 1 — The Six-Phase Assessment Methodology
**Type**: Cyclic flowchain
**Purpose**: The backbone of the module. An agent security assessment is a *loop*, not a pipeline — six phases that feed back into each other across releases. Each phase ties to the prior module that supplies its content. The diagram makes the capstone synthesis visible: B0 (scope), B1 (recon), B9+B10 (discovery), B0 (validation), B9 output (report), B0.2 (retest). A retest feeds the next engagement's scoping.
**Reading the diagram**: Read clockwise as the engagement cycle. The dashed arrow from Retest back to Scoping is the recurring-engagement loop — the long-term value of the service. The teal callouts mark the module that supplies each phase's content.
```mermaid
flowchart LR
P1["1. SCOPING<br/>surfaces · model versions<br/>provider authorizations · exclusions<br/>→ SOW + scope file"]:::phase
P2["2. RECONNAISSANCE<br/>map the agent's surfaces<br/>B1 threat-model template<br/>B10 capability disclosure"]:::phase
P3["3. DISCOVERY<br/>B9 OWASP checklist (10 rows)<br/>B10 attack chains (7 modes<br/>+ zero-click HITL bypass)"]:::phase
P4["4. EXPLOITATION / VALIDATION<br/>B0 minimum-proof discipline<br/>reproduce · measure N/M<br/>evidence field set"]:::phase
P5["5. REPORTING<br/>exec summary · findings<br/>control matrix · roadmap<br/>= B9 scored output packaged"]:::phase
P6["6. RETESTING<br/>same harness · same sampling<br/>same pinned version<br/>residual risk before/after"]:::phase
P1 --> P2 --> P3 --> P4 --> P5 --> P6
P6 -. recurring engagement .-> P1
M1["B0 legal control plane"]:::mod
M2["B1 threat model"]:::mod
M3["B9 checklist + B10 chains"]:::mod
M4["B0 minimum-evidence"]:::mod
M5["B9 executor output"]:::mod
M6["B0.2 residual-risk"]:::mod
P1 -. supplied by .-> M1
P2 -. supplied by .-> M2
P3 -. supplied by .-> M3
P4 -. supplied by .-> M4
P5 -. supplied by .-> M5
P6 -. supplied by .-> M6
classDef phase fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
classDef mod fill:#101018,stroke:#f0a868,color:#f0a868
```
> **Note**: Only two of the six phases (Discovery + Validation) are the testing that B9 and B10 supply. Scoping is where the legal plane gets set; Reporting is where the output becomes a deliverable; Retesting is where the residual gets measured. An engagement that runs only the testing phases is "run B9 and hand over the output" — half an engagement.
---
## Diagram 2 — Scoping to SOW Flow (with B0 clauses)
**Type**: Process flow with mandated clauses
**Purpose**: Scoping is where B0's legal control plane gets written into the engagement contract. The four-point surface enumeration (B1 template, model versions, provider authorizations, exclusions) flows into the SOW, which must carry B0's seven clauses — three of them AI-specific (provider authorization, dual-use/disclosure, DMCA waiver). An SOW missing any clause fails at the moment a serious finding appears.
**Reading the diagram**: Top = the scoping enumeration. Middle = the SOW with its seven clauses. The red callouts mark the three AI-specific clauses a traditional pentest SOW does not carry. The provider-authorization check is a gating step — surfaces that fail B0's three conditions are out of scope until the gap closes.
```mermaid
flowchart TB
subgraph ENUM["SCOPING — four-point surface enumeration"]
direction TB
E1["SURFACES (B1 template)<br/>inputs · tools · memory · provider<br/>identity · sandbox · inter-agent edges"]
E2["MODEL VERSIONS (pinned)<br/>gpt-model-v3-2026-05-01<br/>claude-opus-4-1-20260605"]
E3["PROVIDER AUTHORIZATIONS<br/>per technique: ToS / waiver / self-hosted"]
E4["EXCLUSIONS<br/>prod PII · shared infra<br/>forbidden techniques"]
E1 --- E2 --- E3 --- E4
end
GATE{"provider_authorization<br/>check (B0)"}
BLOCK["OUT OF SCOPE<br/>until gap closes"]:::danger
ALLOW["IN SCOPE"]:::good
ENUM --> GATE
GATE -->|"all 3 conditions fail"| BLOCK
GATE -->|"≥1 condition holds"| ALLOW
subgraph SOW["SOW — seven clauses (B0 + B12)"]
direction TB
C1["1. Systems in scope (pinned versions)"]
C2["2. PROVIDER AUTHORIZATION / ToS compliance"]:::ai
C3["3. Techniques permitted / prohibited<br/>(weight-read = minimum-proof only)"]
C4["4. DUAL-USE & DISCLOSURE<br/>180d model-level · 90d harness-level<br/>recipe suppressed by default"]:::ai
C5["5. DMCA § 1201 WAIVER<br/>(if bypassing a model access control)"]:::ai
C6["6. Data handling<br/>(Public / Provider-Only /<br/>Restricted / Destroy-on-Report)"]
C7["7. Residual-risk measurement protocol<br/>(never binary 'fixed')"]
end
ALLOW --> SOW
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
classDef ai fill:#101018,stroke:#f08080,color:#f08080
style ENUM fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style SOW fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style GATE fill:#101018,stroke:#f0a868,color:#f0a868
style C1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style C3 fill:#101018,stroke:#5eead4,color:#e4e4e8
style C6 fill:#101018,stroke:#5eead4,color:#e4e4e8
style C7 fill:#101018,stroke:#5eead4,color:#e4e4e8
```
> **Note**: The three red clauses (provider authorization, dual-use/disclosure, DMCA waiver) are the AI-specific additions to a traditional pentest SOW. A client's counsel signs this before testing begins; the clauses resolve B0's risks contractually rather than in the moment. The provider-authorization check at the top is a gating step — it is the engineering realization of "the deployer cannot authorize what the provider forbids."
---
## Diagram 3 — The Engagement Report Structure
**Type**: Section map / data flow
**Purpose**: The report is the deliverable, and it is the same scored artifact B9's checklist executor produces — formatted into five sections a CISO can read and a regulator can audit. The diagram shows how the B9 output and B10 chains flow into the findings section, how the B9 risk-to-module mapping becomes the control matrix, and how the report generator (lab) enforces the field set.
**Reading the diagram**: Left = the inputs (B9 executor JSON, B10 chain findings, B1 surface map, B0 scope). Middle = the five report sections. Right = the validation layer that refuses to ship an unclassified or incomplete finding.
```mermaid
flowchart LR
subgraph IN["INPUTS"]
direction TB
I1["B9 CHECKLIST EXECUTOR<br/>8 PASS/FAIL + 2 MEASURED<br/>(JSON)"]
I2["B10 CHAIN FINDINGS<br/>7 modes + zero-click HITL<br/>bypass chain"]
I3["B1 SURFACE MAP<br/>(reconnaissance output)"]
I4["B0 SCOPE FILE + SOW<br/>(the authorization plane)"]
end
subgraph REPORT["ENGAGEMENT REPORT — 5 sections"]
direction TB
S1["1. EXECUTIVE SUMMARY<br/>residual posture · findings count<br/>ship recommendation (never 'secure')"]:::sec
S2["2. FINDINGS<br/>taxonomy ref · attack procedure<br/>evidence · residual risk · remediation"]:::sec
S3["3. CONTROL MATRIX<br/>controls × surfaces<br/>Present / Absent / Partial / Mismeasured"]:::sec
S4["4. REMEDIATION ROADMAP<br/>prioritized · routed to B2-B8<br/>owner + effort estimate"]:::sec
S5["5. APPENDIX<br/>methodology · scope · evidence index"]:::sec
end
subgraph VAL["VALIDATION (report generator)"]
direction TB
V1["finding with no taxonomy ref<br/>→ REJECTED"]:::danger
V2["MEASURED without success rate<br/>→ REJECTED"]:::danger
V3["Critical without remediation<br/>→ REJECTED"]:::danger
end
I1 --> S2
I2 --> S2
I3 --> S3
I4 --> S5
S2 -. enforced by .-> VAL
I1 -. risk→module map .-> S3
S2 -. routes to .-> S4
classDef sec fill:#14141f,stroke:#5eead4,color:#e4e4e8
classDef danger fill:#101018,stroke:#f08080,color:#f08080
style IN fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
style REPORT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style VAL fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
```
> **Note**: B9's checklist executor output *is* the findings section's backbone. B12 does not re-test; it packages. The validation layer is what prevents the "10/10 PASS" lie — the report generator refuses to emit a finding that lacks a taxonomy reference, a MEASURED finding without a success rate, or a Critical finding without a remediation route. The strictness is the honesty, enforced at the output layer.
---
## Diagram 4 — Retesting: Residual-Risk Before/After Comparison
**Type**: Comparison / measurement
**Purpose**: Retesting measures residual risk, not binary "fixed." The same harness, the same sampling parameters, the same pinned model version, re-run after remediation. The verdict is Resolved / Improved / Unchanged / Regressed — never "fixed." The diagram shows the before/after comparison and the four verdicts, plus the regression risk (a B10 chain may reroute through a different gap after a patch).
**Reading the diagram**: Left = the original assessment residual. Middle = the retest under identical conditions. Right = the four possible verdicts. The red path (Regressed) is why the retest re-runs discovery, not just the original finding — a patch can open a new gap.
```mermaid
flowchart TB
ORIG["ORIGINAL ASSESSMENT<br/>Finding F-04: injection success<br/>60% over 100 attempts<br/>(pinned model · sampling params)"]
RETEST["RETEST — identical conditions<br/>same B9/B10 test cases<br/>same sampling params<br/>same pinned model version"]
COMPARE{"compare<br/>before / after"}
ORIG --> RETEST --> COMPARE
V1["RESOLVED<br/>residual → 0%<br/>(deterministic control added)"]:::good
V2["IMPROVED<br/>60% → 4%<br/>(mitigation reduced,<br/>did not eliminate)"]:::warn
V3["UNCHANGED<br/>60% → 60%<br/>(remediation ineffective)"]:::danger
V4["REGRESSED<br/>a PASS row → FAIL<br/>or chain rerouted<br/>through a new gap"]:::danger
COMPARE --> V1
COMPARE --> V2
COMPARE --> V3
COMPARE --> V4
NOTE["The verdict is NEVER 'fixed.'<br/>The retest report is a delta document:<br/>original residual · post-remediation residual · verdict.<br/>A regulator reads it to verify the client fixed<br/>what they said they fixed."]:::note
COMPARE --> NOTE
classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef note fill:#101018,stroke:#5eead4,color:#5eead4
style ORIG fill:#14141f,stroke:#5eead4,color:#e4e4e8
style RETEST fill:#14141f,stroke:#5eead4,color:#e4e4e8
style COMPARE fill:#101018,stroke:#f0a868,color:#f0a868
```
> **Note**: "Is it fixed?" is the wrong question; the answer is never yes. The right question is "did the residual move, and by how much, under identical conditions?" The Regressed verdict (bottom) is why the retest re-runs the full B9 checklist and re-attempts the B10 chains — patching one step of a chain can reroute it through a different gap. A retest that checks only the original finding misses regressions.
---
## Diagram 5 — The Service Packaging Stack
**Type**: Layered stack
**Purpose**: The difference between a one-off assessment (a project) and a repeatable assessment practice (a service) is packaging. Four layers — methodology, tooling, templates, evidence — make the engagement run the same way across clients and releases. Comparability across releases is the long-term value a CISO buys.
**Reading the diagram**: Read bottom-to-top as the layers that make the practice repeatable. The evidence layer (B0 + B11) makes it defensible; the template layer makes it consistent; the tooling layer makes it scalable; the methodology layer is the playbook. Drift in any layer breaks the comparability that makes the residual-trend-over-releases valuable.
```mermaid
flowchart BT
L1["METHODOLOGY LAYER<br/>the six-phase playbook<br/>phase → module mapping<br/>(PTES / NIST SP 800-115 adapted)"]:::layer
L2["TOOLING LAYER<br/>B9 checklist executor · B10 chain harness<br/>report generator (B12 lab)<br/>scope-file validator (B0 lab)"]:::layer
L3["TEMPLATE LAYER<br/>SOW (7 clauses) · scope file<br/>report (5 sections) · retest delta<br/>CVD timeline (B0 lab)"]:::layer
L4["EVIDENCE LAYER<br/>B0 evidence store (4 retention classes)<br/>B11 audit trail · B11 AI BOM<br/>the defensible foundation"]:::layer
L4 --> L3 --> L2 --> L1
OUT["COMPARABLE ARTIFACTS ACROSS RELEASES<br/>injection success rate over 6 releases<br/>the long-term value the CISO buys"]:::out
L1 --> OUT
classDef layer fill:#14141f,stroke:#5eead4,color:#e4e4e8
style L1 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style L2 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style L3 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style L4 fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
classDef out fill:#101018,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
```
> **Note**: The evidence layer (B0's retention classes + B11's audit trail and AI BOM) is the foundation — it is what makes every finding trace to scoped, authorized, minimum-proof evidence that survives a regulator's review. Without it, the layers above produce artifacts that cannot be audited. The methodology is a cycle, not a pipeline: a static playbook document is the cycle frozen at phase 1.