The MethodAtlas SABSA Architecture

Security architecture — MethodAtlas project

Organisation	MethodAtlas project
Scope	MethodAtlas development
Owner	the Architect and Programmer
Version	6.1.0 (approved)
Generated	2026-10-15
Approval	APPROVED — the Architect and Programmer at 2026-10-14T22:21:30+00:00

Generated from the approved security-architecture library

Every element below is one file in MethodAtlas’s SABSA library, owner-approved against a hash-bound snapshot and regenerated into this page so the document and the model cannot drift. This is the full architecture; the SABSA overview is the orientation and the six-layer walkthrough the readable tour.

1. Executive summary

SABSA security architecture library for the MethodAtlas project. Scope: MethodAtlas development.

Each element is one Markdown file named by its ID, in the folder of its layer. Upward links are required, so every element traces to a business driver.

Numbering gaps (retired IDs)

The IDs SS-011, SM-011, ME-011 and EV-011 are intentionally unused: they belonged to a single compound "aggregator" chain for the Credible attribute (BA-011) that was dropped during review as compound and over-reaching. Its concerns were re-homed — the service into SS-006 / CO-012, the mechanism absorbed into the retained physical mechanisms, the measure into ME-007, the evidence into EV-006 — as recorded in BA-011, SS-006, CO-012 and ME-007, and the matrix cells logical-how ("SS-011 not used") and service-management-what ("EV-011 not used"). SM-011 was the mechanism that would have realised the dropped SS-011 aggregator; the owner confirmed on 2026-10-14 that it was retired as part of the same chain.

2. Scope and approach

This architecture covers MethodAtlas development for MethodAtlas project. It follows the SABSA method: security requirements are derived from business drivers, expressed as measurable business attributes, and carried through six layers — from the business's own view down to the components — with each layer answering six questions: what, why, how, who, where and when. Every element traces upward to a business driver, so nothing is included without a business reason.

3. Basis of this document

Of 199 architecture elements, 171 are stated by MethodAtlas project, 28 are inferred from the material below, and 0 are assumptions awaiting confirmation (section 13).

Source	Cited by
00-sources/00-engagement-brief.md	BA-011 BD-010 CO-012 RO-010 SO-005 matrix/contextual-what matrix/contextual-where matrix/contextual-who matrix/logical-who matrix/service-management-where matrix/service-management-who
00-sources/01-product-overview.md	BA-004 BA-008 BA-011 BA-013 BD-001 BD-004 BD-007 BD-008 BD-010 CO-004 CO-008 CO-013 DM-005 DM-007 EV-004 EV-007 EV-013 EX-002 EX-003 EX-007 ME-004 ME-008 ME-013 RO-009 SC-001 SC-007 SC-016 SM-004 SM-007 SS-004 SS-007 SS-013 matrix/component-how matrix/component-what matrix/component-why matrix/conceptual-what matrix/contextual-what matrix/contextual-where matrix/contextual-who matrix/logical-how matrix/logical-who matrix/physical-what matrix/physical-what matrix/physical-who
00-sources/02-security-policy.md	BA-001 BA-001 BA-008 BA-008 BA-010 BA-013 BA-013 BD-001 BD-001 BD-008 BD-008 BD-009 CO-001 CO-008 CO-008 CO-010 CO-013 DM-008 EV-001 EV-007 EV-007 EV-009 EV-013 EX-001 EX-003 ME-001 ME-008 ME-008 ME-010 ME-013 RO-001 RO-007 RO-012 RO-012 RO-013 RO-014 SC-016 SC-017 SC-018 SM-001 SM-007 SM-009 SM-013 SO-005 SO-005 SS-001 SS-007 SS-007 SS-009 SS-013 ST-001 ST-002 ST-009 ST-010 TR-001 TR-007 TR-008 matrix/conceptual-what matrix/conceptual-who matrix/conceptual-why matrix/contextual-how matrix/contextual-what matrix/contextual-when matrix/contextual-who matrix/contextual-why matrix/physical-how matrix/physical-when matrix/physical-why matrix/service-management-what matrix/service-management-who matrix/service-management-why
00-sources/03-compliance-context.md	AD-002 AD-004 BA-002 BA-014 BD-002 BD-003 BD-010 CO-002 CO-014 EV-002 EV-014 EX-005 ME-002 ME-014 RM-001 RO-002 SC-005 SC-006 SC-008 SC-015 SC-019 SM-014 SM-015 SS-002 SS-014 matrix/conceptual-when matrix/contextual-when
00-sources/04-development-invariants.md	AD-002 AD-005 AD-005 AD-006 BA-002 BA-003 BA-004 BA-004 BA-005 BA-006 BA-006 BA-009 BA-013 BD-002 BD-002 BD-003 BD-004 BD-005 BD-006 BD-006 BD-009 CO-002 CO-003 CO-004 CO-004 CO-005 CO-006 CO-006 CO-009 DM-002 DM-006 EV-002 EV-003 EV-004 EV-004 EV-005 EV-008 EV-012 EX-004 EX-005 EX-007 ME-002 ME-003 ME-004 ME-004 ME-005 ME-006 ME-006 ME-009 PL-001 PL-001 RM-006 RO-006 RO-009 SC-002 SC-005 SC-008 SC-010 SC-011 SC-012 SC-014 SM-002 SM-003 SM-004 SM-005 SM-005 SM-008 SM-012 SM-015 SM-016 SO-001 SO-003 SO-005 SO-006 SS-002 SS-003 SS-004 SS-005 SS-005 SS-008 SS-012 ST-001 ST-003 ST-004 ST-005 ST-006 ST-007 ST-008 TR-002 TR-005 matrix/component-how matrix/component-how matrix/component-what matrix/component-why matrix/conceptual-how matrix/conceptual-what matrix/conceptual-when matrix/conceptual-where matrix/contextual-how matrix/contextual-how matrix/contextual-when matrix/logical-how matrix/logical-when matrix/logical-when matrix/logical-why matrix/logical-why matrix/physical-when matrix/physical-where matrix/physical-why matrix/service-management-how matrix/service-management-what matrix/service-management-when matrix/service-management-where
00-sources/05-research-build-trust-context.md	BA-010 BA-012 BD-003 BD-006 BD-007 BD-009 BD-011 CO-003 CO-010 CO-011 DM-003 DM-006 DM-007 DM-008 EV-003 EX-001 EX-010 ME-003 ME-010 ME-012 RM-002 RM-003 RO-002 RO-003 RO-004 RO-005 RO-008 RO-011 RO-013 RO-014 SC-009 SC-010 SC-011 SC-013 SC-018 SM-003 SM-009 SM-010 SM-016 SO-004 SS-003 SS-009 SS-010 ST-009 ST-012 TR-002 TR-005 TR-006 TR-008 matrix/component-why matrix/conceptual-how matrix/conceptual-why matrix/contextual-why matrix/service-management-where
00-sources/06-architecture-and-data-governance.md	AD-003 AD-007 AD-009 BA-003 BA-005 BA-007 BA-007 BA-009 BA-011 BA-013 BD-005 BD-007 BD-007 BD-010 CO-007 CO-007 CO-009 CO-012 CO-013 DM-001 DM-001 DM-002 DM-004 DM-004 DM-005 EV-006 EV-006 EV-008 EV-013 EX-002 EX-004 EX-006 EX-008 EX-009 ME-007 ME-007 ME-009 ME-013 RM-004 RM-005 RM-007 RO-004 RO-010 RO-015 SC-001 SC-002 SC-003 SC-004 SC-007 SC-012 SC-014 SM-006 SM-006 SM-008 SM-012 SM-013 SO-002 SS-006 SS-006 SS-008 SS-012 SS-013 ST-008 TR-001 TR-003 TR-003 TR-007 matrix/component-what matrix/component-where matrix/component-who matrix/component-who matrix/conceptual-when matrix/conceptual-where matrix/conceptual-where matrix/conceptual-who matrix/conceptual-who matrix/contextual-where matrix/contextual-who matrix/logical-how matrix/logical-what matrix/logical-when matrix/logical-where matrix/logical-where matrix/logical-where matrix/logical-who matrix/logical-why matrix/physical-how matrix/physical-what matrix/physical-when matrix/physical-where matrix/physical-who matrix/physical-why matrix/service-management-how matrix/service-management-what matrix/service-management-when
00-sources/07-client-decisions.md	AD-001 AD-001 AD-008 BA-006 BA-012 BD-011 CO-006 CO-011 DM-003 EV-005 EV-010 EX-001 EX-001 EX-002 EX-003 EX-004 EX-005 EX-006 EX-007 EX-008 EX-009 EX-010 EX-010 ME-006 ME-012 PL-002 RM-003 RO-011 RO-013 SC-013 SM-010 SM-017 SM-017 SO-003 SO-007 SS-005 SS-010 ST-011 ST-012 TR-004 TR-004 TR-006 matrix/component-when matrix/conceptual-how matrix/physical-how matrix/service-management-when matrix/service-management-why
00-sources/08-comment-redaction.md	EV-015 EV-015 ME-015 ME-015 RM-008 RO-015 SC-020 SC-020 SM-018 SM-018
00-sources/09-release-6.1.0.md	AD-009 AD-010 AD-011 AD-011 AD-011 BA-005 BA-006 BA-009 BA-009 BA-009 BA-011 BA-012 CO-009 CO-009 CO-012 DM-005 EV-006 EV-008 EV-008 EV-012 EX-002 EX-007 EX-008 EX-009 EX-010 EX-011 EX-011 ME-007 ME-009 ME-009 RM-004 RM-006 RM-007 SC-012 SC-012 SC-012 SM-006 SM-008 SM-018 SO-006 SS-006 SS-008 SS-008 ST-003 matrix/component-how matrix/logical-when matrix/logical-when matrix/physical-why matrix/physical-why matrix/service-management-what matrix/service-management-when matrix/service-management-why

4. Contextual layer — Business view

This layer describes the business itself: what it does, why it needs security, and the constraints it works within.

What — Assets

Which business assets, goals and decisions does security protect or enable?

The asset security protects is the trustworthiness of MethodAtlas's own output and of the development process that produces it — the product's reason to exist for a regulated-industry audience. The valuable things, captured as the business drivers, are: output "traceable, repeatable and defensible" enough to stand as audit evidence before auditors, regulators and review boards (BD-001); deterministic, reproducible structural results (BD-002); bounded, auditable AI classification (BD-003); the closed security taxonomy (BD-004) and the audit/evidence schemas (BD-005) as stable contracts; the integrity and provenance of the build and shipped distribution (BD-006); data minimisation toward external AI providers (BD-007); the confidentiality and integrity of human-review and override decisions (BD-008); secure-development discipline and coordinated disclosure (BD-009); credibility for regulated and air-gapped adoption (BD-010); and the deliberate, proportionate self-asserted trust position — published hashes, not managed-key signing (BD-011). SECURITY.md names result authenticity, audit-trail integrity and override-file confidentiality as assets treated as critical regardless of CVSS. The eleven drivers BD-001..BD-011 carry the detail.

Basis: stated · Source: 00-sources/01-product-overview.md#purpose, 00-sources/02-security-policy.md#key-trust-assets-implied-for-driver-derivation, 00-sources/00-engagement-brief.md#what-this-library-is-for

ID	Element	Description	Basis
BD-001	Output trustworthy enough to serve as audit evidence	MethodAtlas output must be trustworthy enough to stand as audit evidence before auditors, regulators and security review boards.	stated
BD-002	Deterministic, reproducible structural results	The same source revision must always produce the same deterministic structural record, independent of AI provider, model or wall-clock time.	stated
BD-003	AI-assisted classification kept bounded and auditable	AI-assisted classification must stay bounded to a closed, versioned taxonomy and an explicit method list so it can neither invent nor omit findings and its influence on the evidence remains auditable and reproducible.	stated
BD-004	Stability of the closed security taxonomy	The closed, versioned security taxonomy must remain stable and explicitly versioned so classifications stay comparable over time and coverage is not silently regressed between assessment periods.	stated
BD-005	Stability of the audit and evidence schemas	The audit and evidence schemas must remain stable, with any breaking change governed by an explicit version bump, so downstream compliance tooling and audit trails do not break.	stated
BD-006	Integrity and provenance of the build and shipped distribution	The integrity and provenance of the shipped distribution and the build that produces it must be assured, so that a tampered build or poisoned dependency cannot silently corrupt the evidence the tool emits.	stated
BD-007	Data minimisation when using external AI providers	When external AI providers are used, MethodAtlas must transmit only the minimum necessary and never production source, configuration, credentials or directory structure, preserving its data-governance boundary and its air-gapped operating mode.	stated
BD-008	Confidentiality and integrity of human-review and override decisions	The confidentiality and integrity of human-review and override decisions must be protected, because these records carry reviewer judgement and are treated as critical regardless of CVSS.	stated
BD-009	Secure-development discipline and coordinated vulnerability disclosure	As a security tool, MethodAtlas must hold its own development to the secure-development discipline it expects of others, backed by enforced quality gates and a published coordinated vulnerability-disclosure process.	stated
BD-010	Credibility for adoption in regulated and air-gapped environments	MethodAtlas must earn and sustain the credibility required for adoption by security teams in regulated and air-gapped environments, because that credibility is the precondition for the product to be used at all.	inferred
BD-011	Proportionate, self-asserted trust without managed-key release signing	MethodAtlas's own trustworthiness rests on GitHub's verifiable per-asset SHA-256 digests of its release artefacts plus deterministic, reproducible, hash-based evidence and enforced quality/supply-chain gates, rather than on managed-key cryptographic signatures of the release package, and the boundary of this self-asserted trust is to be stated explicitly.	stated

Why — Motivation

Which business risks — threats and opportunities — matter, and why?

Risk here is two-sided. The threats to the trust assets (RO-001..RO-009, RO-012..RO-014): a tampered scanner script fabricating or suppressing findings (RO-001); non-deterministic output breaking the audit trail (RO-002); prompt injection via scanned source skewing classification (RO-003); source exfiltration to a hosted AI provider (RO-004); a poisoned dependency or compromised build propagating into customers' evidence (RO-005); an unversioned schema break desynchronising downstream tooling (RO-006); override-file disclosure exposing reviewer decisions (RO-007); weak OSS security posture undermining credibility (RO-008); an unversioned taxonomy change invalidating historical classifications (RO-009); audit-trail artefact tampering after emission (RO-012); artefact-and-checksum substitution at the distribution channel (RO-013); and a reported vulnerability not triaged or fixed within SLA (RO-014). The two opportunities security makes possible: air-gapped and local-only operation opening strict-DLP adoption (RO-010), and published hash-based trust evidence differentiating the product without managed keys (RO-011). The threat framing is composed from SECURITY.md's own rationale plus the public standards that bind this product (SSDF, SLSA, OWASP LLM Top 10, Reproducible Builds, ISO/IEC 29147+30111). RO-001..RO-014 carry the detail.

Basis: inferred · Source: 00-sources/02-security-policy.md#scanner-script-integrity-result-authenticity, 00-sources/05-research-build-trust-context.md#standards-that-most-directly-bind-this-products-development

ID	Element	Description	Basis
RO-001	Tampered scanner script fabricates or suppresses findings	A helper scanner script (ts-scanner.bundle.js or py-scanner.py) is substituted or modified so it selectively fabricates or suppresses discovered test methods, producing a falsified audit report that still looks valid — including the case where the whole JAR is repackaged so the script and its MANIFEST.MF hash are rewritten together, defeating the hash-match check.	stated
RO-002	Non-deterministic output breaks the audit trail	Structural discovery output varies between runs on the same source revision, so a result cannot be regenerated and matched later, destroying its value as an auditable record.	stated
RO-003	Prompt injection via scanned source skews classification	Untrusted test source fed to the AI classifier carries an indirect prompt-injection payload that manipulates the model into mis-classifying, inventing or omitting results.	stated
RO-004	Source exfiltration to a hosted AI provider	Code under analysis, or data beyond the permitted minimum, is transmitted to a hosted AI provider and disclosed or retained outside the organisation's control.	stated
RO-005	Poisoned dependency or compromised build propagates into customers' evidence	A poisoned third-party dependency or a compromised build silently alters scanner logic so emitted attestations look valid while findings are wrong, and because the output is trusted downstream the compromise propagates into many customers' compliance packages.	stated
RO-006	Unversioned schema break desynchronises downstream tooling	A DeltaReport column or ClassificationOverride field is renamed, reordered or retyped without a schema version bump, silently breaking downstream compliance tooling and the GUI audit trail that consume it.	stated
RO-007	Override-file disclosure exposes reviewer decisions	The override files and audit-trail artefacts that record human-review decisions are disclosed to an unauthorised party, exposing reviewer judgement about security-relevant tests and the organisation's security posture.	stated
RO-008	Weak OSS security posture undermines credibility	A weak or opaque open-source security posture — low automated supply-chain score, unclear vulnerability-handling, undocumented trust claims — leads regulated buyers to reject the tool as not credible for their environment.	stated
RO-009	Unversioned taxonomy change invalidates historical classifications	The closed security taxonomy is changed without a version increment, so a label emitted by an earlier release can no longer be interpreted reliably and historical evidence loses its stable meaning.	inferred
RO-010	Air-gapped and local-only operation opens strict-DLP adoption	The fully local and manual operating tiers let MethodAtlas run with zero outbound data, opening adoption in air-gapped and strict-DLP environments that cannot use cloud-only tools.	inferred
RO-011	Published hash-based trust evidence differentiates without managed keys	Publishing deterministic, hash-based trust evidence — GitHub's per-asset SHA-256 digests, reproducibility receipts, enforced-gate reports and an explicit trust-basis statement — lets the product earn buyer confidence proportionately, without taking on the burden of managed signing keys.	inferred
RO-012	Audit-trail artefact tampered with or silently rewritten after emission	An emitted audit-trail artefact — the evidence CSV, the cumulative overrides.yaml, the attestation manifest or a reproducibility receipt — is modified or selectively rewritten after emission, so the recorded history no longer reflects what actually happened and the audit trail can no longer be relied upon.	stated
RO-013	Release artefact and its digest substituted together at the distribution channel	A release artefact and its per-asset SHA-256 digest are replaced together at the distribution channel — or the whole JAR is repackaged so a scanner script and its MANIFEST.MF hash are rewritten together — so every integrity check passes against a falsified artefact that the project does not cryptographically sign, and a buyer applying OpenSSF Signed-Releases rejects the unsigned release.	stated
RO-014	Reported product vulnerability not triaged or fixed within SLA	A vulnerability reported against MethodAtlas is not acknowledged, triaged or remediated within the published service levels, so a known weakness in a security-evidence tool stays exploitable and the project's credibility as a secure-development exemplar erodes.	inferred
RO-015	PII in source comments exfiltrated to an external AI provider	Personal data carried in source-code comments (for example Java Javadoc) is transmitted to a hosted AI provider inside the test-class source file and disclosed or retained outside the organisation's control.	stated

How — Process

Which business processes depend on security, and how?

The value-creating processes that depend on security are the product's own build, test, release and disclosure lifecycle. Building and testing: every change runs the enforced quality gates (compile, unit tests, PMD, SpotBugs, JaCoCo coverage floors, PIT mutation floors, dependency-check on CVSS≥7.0, license allowlist, CycloneDX SBOM) and the ArchUnit plugin-seam invariants — trust properties verified mechanically on every build, not merely documented. Releasing: distribution integrity depends on the supply-chain invariants (for example, the ANTLR grammar-compiler JARs excluded from lib/), on GitHub's per-asset SHA-256 digests, and on attestation manifests and reproducibility receipts. Disclosing: the coordinated vulnerability disclosure process (private GitHub advisory or PGP email) operated to published response SLAs. Each process is a point where integrity, authenticity and reproducibility are critical to the product earning the trust its regulated audience requires; a failure in any of them would directly undermine the output's standing as evidence.

Basis: stated · Source: 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/02-security-policy.md#vulnerability-handling, 00-sources/04-development-invariants.md#deliverables-on-every-change

Who — People

Who is involved: the organisation, its governance, customers, partners and suppliers?

MethodAtlas is maintained as an open-source product (github.com/Accenture/MethodAtlas); the accountable owner is the Architect and Programmer. The consuming stakeholders are security-focused teams in regulated industries who must demonstrate which tests cover which security controls to auditors, regulators and review boards. Third parties: the external AI providers (Ollama local, OpenAI, Anthropic, Azure OpenAI, Groq, xAI, GitHub Models, Mistral, OpenRouter), whose APIs and model behaviour are explicitly out of the product's own security scope; the upstream dependency and supply-chain suppliers (Maven/npm libraries such as JavaParser and the ANTLR runtime), whose integrity the build must verify; and the security researchers who report vulnerabilities through the coordinated-disclosure channel. Governance of the trust promise rests with the single owner/maintainer — a concentration carried forward as a support-model limitation at the service-management layer.

Basis: stated · Source: 00-sources/00-engagement-brief.md#library-parameters, 00-sources/01-product-overview.md#audience--market, 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/02-security-policy.md#vulnerability-handling

Where — Location

Where does the business operate: locations, jurisdictions, markets?

The product is distributed globally as open source via GitHub (github.com/Accenture/MethodAtlas), so its market is any regulated-industry team worldwide. Jurisdiction and data residency bite at the AI boundary: with a hosted provider the single test-class source is transmitted over HTTPS and provider policy governs retention, with EU-residency options named (azure_openai EU region, mistral EU), and GDPR becomes in-scope when fixtures carry real personal data — mitigated by Tier-1 operation (Ollama local, data never leaves the host) or Tier-2 (manual prepare/consume). The relevant "locations" for this scope are therefore the distribution channel (GitHub), the scan host, and the external-provider region — not any single customer estate, which is deliberately out of scope.

Basis: stated · Source: 00-sources/00-engagement-brief.md#library-parameters, 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/01-product-overview.md#audience--market

When — Time

When: which business cycles, deadlines and time dependencies constrain security?

The binding time dependencies are: the per-change / per-build cycle, where every commit must pass the enforced gates before it is accepted; the per-release cycle, where checksums, attestation manifests and reproducibility receipts are produced for the shipped distribution; and the coordinated-disclosure clock, with published response SLAs of acknowledge within 2 business days, triage within 5, and a fix or mitigation plan within 30 days (critical/high) or 90 days (lower). Downstream, the product's output feeds customers' periodic audit and resilience-testing cycles (for example DORA's regularly-repeated testing, with coverage not regressed between periods), so reproducibility must hold across those intervals. There is no fixed calendar release cadence in the material; releases are event-driven — triggered by change and by disclosure.

Basis: stated · Source: 00-sources/02-security-policy.md#vulnerability-handling, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/03-compliance-context.md#implication-for-development-this-librarys-scope

5. Conceptual layer — Architect's view

This layer describes what security must achieve, expressed as attributes, objectives, strategies and domains.

What — Assets

What does 'secure' mean for this business — its attribute profile?

"Secure" for MethodAtlas is expressed as a profile of fourteen measurable business attributes, each with a definition, a metric, a measurement method and a target: Authentic (BA-001), Reproducible (BA-002), Bounded (BA-003), Taxonomy-Stable (BA-004), Schema-Stable (BA-005), Supply-Chain-Intact (BA-006), Data-Minimising (BA-007), Confidential (BA-008), Verifiably-Tested (BA-009), Supportable (BA-010), Credible (BA-011), Transparent (BA-012), Audit-Trail-Intact (BA-013) and AI-Result-Reproducible (BA-014). Together they translate the stated trust assets — result authenticity, audit-trail integrity, override confidentiality, determinism, closed taxonomy, and schema and supply-chain stability — into properties the project can observe on its own builds rather than aspirations. The attribute profile BA-001..BA-014 carries each definition, metric and target.

Basis: inferred · Source: 00-sources/02-security-policy.md#key-trust-assets-implied-for-driver-derivation, 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected, 00-sources/04-development-invariants.md#overall-posture

ID	Element	Description	Basis
BA-001	Authentic	Every discovered test method and emitted record reflects unmodified, peer-reviewed scanner logic — the output is what the published code genuinely produced, not something a tampered helper script fabricated or suppressed.	stated
BA-002	Reproducible	The deterministic structural layer (AST-based discovery — FQCN, method, line count, source tags, content hash) produces identical output for the same source revision, independent of provider, model or time, so a result can be regenerated and checked later.	stated
BA-003	Bounded	The AI classifier is constrained to a closed, versioned security taxonomy and to the explicit list of method names discovered by the deterministic layer, so it can neither invent nor omit methods nor apply a label outside the taxonomy.	stated
BA-004	Taxonomy-Stable	The closed security taxonomy the classifier uses is versioned and changes only through a controlled, version-bumped revision with same-PR documentation, and the effective taxonomy is fingerprinted (via the per-template prompt checksum) into the reproducibility receipt, so a historical classification run can be tied back to the taxonomy that produced it and keeps a stable, re-interpretable meaning.	stated
BA-005	Schema-Stable	The audit and evidence schemas — DeltaReport CSV columns and ClassificationOverride YAML fields consumed by downstream compliance tooling and the GUI audit trail — change only through a versioned, documented revision, never a silent rename, reorder or retype.	stated
BA-006	Supply-Chain-Intact	The build and the shipped distribution are integrity-assured end to end — dependencies are gated on known vulnerabilities and licences, an SBOM is produced, the distribution invariant holds, and GitHub provides a verifiable per-asset SHA-256 digest for every release artefact that consumers can verify against (the project does not ship a separate SHA256SUMS; per D-3).	stated
BA-007	Data-Minimising	When an external AI provider is used, only the minimum necessary leaves the host — the taxonomy text, the discovered method names and line numbers, and the one truncated test-class source file — and never production source, config, credentials, directory structure or other test files; local and manual tiers allow zero outbound data. With the opt-in -redact-comments control, comments are additionally redacted (blanked to spaces) from that one test-class source file before it is sent, so comment-borne personal data does not leave the host even within the permitted category — a further minimisation beyond the "only one class + method list + taxonomy" boundary.	stated
BA-008	Confidential	The override files and audit-trail artefacts that record human-review decisions are protected against unauthorised disclosure — they are never included in any outbound AI payload, and the credential values the product surfaces are masked by default — because these records reveal reviewer judgement about security-relevant tests.	stated
BA-009	Verifiably-Tested	A change that would break a trust property is caught before release, because the enforced per-module coverage and mutation gates hold the trust-critical surfaces — the audit-trail writer (AuditWriter / methodatlas-gui-core), the AI engine (methodatlas-ai) and the output emitters (methodatlas-emit) — to their module floors, the AuditWriter is additionally held to an enforced class-level >= 95% line-coverage gate, and named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism) guard the specific behaviours the product's trust claims rest on.	inferred
BA-010	Supportable	The project operates a published, coordinated vulnerability-disclosure process and responds to reports within stated service levels, so that security issues in the product are received, triaged and remediated predictably.	stated
BA-011	Credible	The product is credibly adoptable in regulated and air-gapped environments — it can run with full structural function and a usable classification path (Tier 1 Ollama local or Tier 2 manual) that makes no outbound connection, so a strict-DLP or air-gapped buyer can use it at all.	stated
BA-012	Transparent	What the product's trustworthiness rests on, and the limits of that trust, are stated explicitly and kept current — specifically that trust rests on published artefact hashes, deterministic reproducible evidence and enforced gates, and that managed-key signing (non-repudiable proof of origin) is deliberately out of scope.	stated
BA-013	Audit-Trail-Intact	The audit-trail artefacts the product emits fall in two groups. The artefacts that carry a cryptographic binding — the attestation manifest (each security test bound by content hash + commit SHA), the reproducibility receipts (SHA-256 of every input, incl. per-template prompt checksums) and the scanner-script MANIFEST.MF hash check — are cryptographically tamper-evident. The GUI .methodatlas/ artefacts — the timestamped evidence CSV (DeltaReport, never overwritten, accumulates per save operation) and the cumulative overrides.yaml (ClassificationOverride) — are append/accumulate and timestamped but are not themselves hash-bound or signed (a known limitation, recorded below).	inferred
BA-014	AI-Result-Reproducible	The AI-influenced classification record can be regenerated despite the AI layer being non-deterministic by nature — re-running on the same commit with the same -ai-cache reproduces the reviewed classified output for unchanged classes, human overrides are applied deterministically, and overridden confidence is pinned to 1.0/0.0 — so the reviewed classified record is a stable authoritative record, not a one-off sample.	stated

Why — Motivation

Why: which control objectives follow from the risks and attributes?

Fourteen control objectives state what must hold, each tracing to the attributes it protects and the risks it addresses: scanner-script integrity verified before execution (CO-001, for BA-001 against RO-001); structural results deterministic and reproducible (CO-002, BA-002 against RO-002); AI confined to the closed taxonomy and the discovered method set (CO-003, BA-003 against RO-003); taxonomy changes versioned and traceable (CO-004, BA-004 against RO-009); audit/evidence schema changes versioned and documented (CO-005, BA-005 against RO-006); build and distribution integrity assured and verifiable (CO-006, BA-006 against RO-005/RO-013); data minimisation enforced for external AI (CO-007, BA-007 against RO-004); override/review-decision confidentiality protected (CO-008, BA-008 against RO-007); product quality proven by enforced test gates (CO-009, BA-009 against RO-008); coordinated disclosure operated to published SLAs (CO-010, BA-010 against RO-014); trust basis and its limits stated transparently (CO-011, BA-011/BA-012 against RO-011/RO-008); credible offline and air-gapped operation maintained (CO-012, BA-011 for RO-010); audit-trail artefacts carry their cryptographic binding while GUI audit files stay append-only (CO-013, BA-013 against RO-012); and reproducibility of AI-influenced output preserved (CO-014, BA-014 against RO-002). CO-001..CO-014 carry the detail.

Basis: inferred · Source: 00-sources/02-security-policy.md#regulatory-context-and-critical-categories, 00-sources/05-research-build-trust-context.md#standards-that-most-directly-bind-this-products-development

ID	Element	Description	Basis
AD-001	Hashes yes, managed-key signing no (D-1)	MethodAtlas relies on published SHA-256 hashes (GitHub's automatic per-asset digest) and keyless build provenance for release integrity, and deliberately does NOT use managed-key cryptographic signing of release packages. Scope boundary: this governs the project's own releases only; the product's -attest and -evidence-pack features let consumers sign their own evidence and are unaffected.	stated
AD-002	Deterministic structural layer, bounded AI layer	AST-based discovery is fully deterministic and never depends on AI; the AI layer is confined to a closed, versioned taxonomy and an explicit list of discovered methods, so it can neither invent nor omit a method. The two layers are kept strictly separate.	stated
AD-003	ServiceLoader plugin-seam boundary	Language support is provided by independent discovery plugins resolved at runtime through ServiceLoader. The core holds no language parsing and no provider code; plugins depend only on the API module; plugins do not depend on each other. Provider order is sorted by plugin id.	stated
AD-004	The human-reviewed decision is the authoritative record	The authoritative classification of record is the human-reviewed result — the content-hash-keyed AI cache plus the override file — not the raw AI output. Overrides are applied deterministically with confidence pinned to 1.0/0.0 and take precedence over AI output.	stated
AD-005	Frozen-contract versioning for audit and taxonomy artefacts	The DeltaReport CSV columns, the ClassificationOverride YAML fields and the closed taxonomy are treated as frozen contracts. Changing one is a versioned, documented change — bump the schema/taxonomy version and update the README, CLI reference and audit-format docs in the same PR; columns are appended, never reordered or retyped.	stated
AD-006	Grammar-compiler JARs are excluded from the distribution	The ANTLR grammar-compiler JARs (antlr4, ST4, icu4j, antlr-runtime, treelayout) must not ship in lib/; only the antlr4-runtime is distributed. The exclusion is wired on both runtimeClasspath and guiRuntime and is re-verified after any ANTLR version bump.	stated
AD-007	Three-tier data-residency model	AI enrichment is offered in three residency tiers — Tier 1 local Ollama (no egress), Tier 2 operator-controlled manual prepare/consume (no egress from the scan host), and Tier 3 hosted provider over HTTPS (minimal payload) — so the adopter chooses what, if anything, leaves the host.	stated
AD-008	Keyless SLSA build provenance adopted (D-4)	The release workflow attaches SLSA build provenance to the release artefacts using keyless attestation (GitHub OIDC + Sigstore), and the project publishes an OpenSSF Scorecard. No managed keys are used.	stated
AD-009	Per-module risk-proportionate quality floors	Coverage and mutation floors are set per module rather than as a single global bar, sized to each module's measured state and risk. Floors are normally raised as test strength improves, but they are not strictly one-way: a floor may be deliberately reduced by owner decision when reality requires it — the root PIT mutation standard was lowered to 55% (owner decision 2026-10-15) when new compliance/evidence feature code brought the measured score below the earlier 60%.	inferred
AD-010	SABSA library version unified onto the product version (6.1.0)	The SABSA library, which had been numbered separately from the product and started later with its own lower sequence (last 0.3.0), is re-baselined to the product release number 6.1.0 so that the library and the product share a single version line from now on.	stated
AD-011	Build supports JDK 21+ (dev JDK 27, CI/CD JDK 21); Error Prone disabled on JDK 25+	The project supports JDK 21 or later (baseline enforced at Gradle configuration time). From the 6.1.0 release two build JDKs are in routine use: the development machine builds on JDK 27, while CI/CD builds on JDK 21 (every .github/workflows and .gitea/workflows job sets java-version '21', Temurin). To run the quality gates on JDK 27 as well as JDK 21 the build toolchain was bumped (Gradle 9.4.0 -> 9.8.1, PMD 7.24.0 -> 7.28.0, SpotBugs 4.9.8 -> 4.10.5, SpotBugs plugin 6.5.4 -> 6.5.13, and PIT core pinned to 1.30.1 with the junit5 plugin at 1.2.3, required for the JDK-27 build). Because no Error Prone release supports JDK 27 (it crashes inside the compiler), Error Prone is disabled on JDK 25 and above via a committed build guard, so it does not run on the JDK-27 dev build; PMD and SpotBugs run on both JDKs and are the active static-analysis gates on the JDK-27 build, while Error Prone still runs on the JDK-21 CI/CD build (JDK <= 24), which is the enforced static-analysis path for every merge and release.	stated
CO-001	Scanner-script integrity verified before execution	Every helper scanner script must be integrity-verified against its build-time reference before it is allowed to run, the reference hash must be build-generated and not hand-editable, and a mismatch must stop discovery before any method is produced, so that output always reflects the peer-reviewed scanner logic.	stated
CO-002	Structural results are deterministic and reproducible	The structural discovery layer must produce identical output for the same source revision regardless of provider, model or time, and the non-deterministic AI layer must be prevented from influencing structural fields.	stated
CO-003	AI classification is confined to a closed taxonomy and the discovered method set	The AI classifier must only apply labels from the loaded, versioned taxonomy and must operate against the explicit list of methods discovered by the deterministic layer, so it cannot invent, omit or re-scope results even under a prompt-injection attempt.	stated
CO-004	Taxonomy changes are versioned and traceable	Any change to the closed security taxonomy must carry a version increment and the required same-PR documentation, and the effective taxonomy must be fingerprinted (via the per-template prompt checksum) into the reproducibility receipt, so a classification run can be tied back to the taxonomy that produced it and historical evidence keeps a stable, re-interpretable meaning.	stated
CO-005	Audit and evidence schema changes are versioned and documented	Any breaking change to the DeltaReport or ClassificationOverride schemas must carry a schema version bump and the corresponding documentation update in the same change, so downstream compliance tooling and the GUI audit trail are never silently desynchronised.	stated
CO-006	Build and distribution integrity are assured and verifiable	The build must enforce dependency-vulnerability, licence and SBOM gates and the distribution invariant, and every release artefact must be covered by GitHub's verifiable per-asset SHA-256 digest (plus keyless build provenance, D-4), so a poisoned dependency or tampered build cannot silently reach customers' evidence.	stated
CO-007	Data minimisation enforced for external AI providers	When a non-local AI provider is used, only the permitted minimum may leave the host and the enumerated never-transmit categories must never be sent, and local and manual tiers must be available so an operator can keep all data on the host.	stated
CO-008	Override and review-decision confidentiality protected	The override files and audit-trail artefacts that record human-review decisions must never be included in any outbound AI payload, credential values must be masked by default, and any report touching their confidentiality must be handled as critical regardless of CVSS.	stated
CO-009	Product quality proven by enforced test gates	The build must enforce the per-module coverage and mutation floors and fail below any of them — root 70%/55%, methodatlas-ai 80%/70%, methodatlas-emit 65%/45%, methodatlas-gui-core 75%/50%, methodatlas-discovery-jvm 85%/60% (JaCoCo instruction / PIT mutation) as enforced in build.gradle; the root mutation standard is 55% (owner decision 2026-10-15), deliberately reduced from the earlier 60% — the floors are risk-proportionate, not strictly one-way — and (6.1.0) enforce a class-level JaCoCo >= 0.95 LINE gate on AuditWriter (measured 97.4%, RM-004), and keep named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism) passing as a chosen (inferred) addition, so a regression that would break authenticity or determinism is caught before release.	inferred
CO-010	Coordinated vulnerability disclosure operated to published SLAs	The project must operate a published, private coordinated-disclosure channel and meet its stated acknowledge, triage and remediation service levels, so that vulnerabilities in the product are handled predictably and visibly.	stated
CO-011	Trust basis and its limits stated transparently	The product must publish and keep current a statement of what its trustworthiness rests on — GitHub's per-asset SHA-256 digests, deterministic reproducible evidence and enforced gates — and of its deliberate limit, that managed-key signing (non-repudiable proof of origin) is out of scope, so no trust claim is left unqualified.	stated
CO-012	Credible offline and air-gapped operation maintained	The product must preserve full structural discovery plus a usable classification path that makes zero outbound connections, verified each release, so it remains adoptable in regulated and air-gapped environments.	stated
CO-013	Audit-trail artefacts carry their cryptographic binding; GUI audit files are append-only	The audit-trail artefacts that can carry a cryptographic binding must do so — the attestation manifest bound to content hash and commit SHA, reproducibility receipts bound to SHA-256 of every input, and the scanner scripts bound to the build-time MANIFEST.MF hash — each verifiable in CI; and the GUI overrides.yaml / evidence CSV must be written append-only (accumulate, never rewrite). The objective does not assert cryptographic tamper-evidence for the GUI CSV/YAML, which carry no hash binding (a recorded limitation and open owner question).	inferred
CO-014	Reproducibility of AI-influenced output is preserved	The product must preserve reproducibility of AI-influenced output — a re-run on the same commit with the same -ai-cache must reproduce the reviewed classified record for unchanged classes, and human overrides must be applied deterministically with confidence pinned to 1.0/0.0 — so the reviewed classified record is a stable authoritative record despite the AI layer being non-deterministic by nature.	stated

How — Process

How: which security strategies and architectural layering will meet the objectives?

The strategy is assurance by construction rather than by perimeter, resting on four load-bearing ideas. (1) A determinism contract that cleanly separates deterministic AST discovery from non-deterministic AI, and constrains the AI to a closed, versioned taxonomy and an explicit method list so it can neither invent nor omit methods. (2) Frozen, versioned contracts for the taxonomy and the audit/evidence schemas, so that any change is deliberate and visible. (3) Mechanically enforced quality and supply-chain gates on every build, which turn trust properties into testable facts rather than claims. (4) A deliberately proportionate trust basis — GitHub's per-asset SHA-256 digests, content hashes, reproducibility receipts and the scanner-script integrity check give tamper-evidence and verifiability, but per owner decision D-1 the project does not adopt managed-key release signing, and states that boundary (integrity, not proof of origin) explicitly. No separate strategy (SG) elements are built; this approach is synthesised from the drivers and attributes and realised through the logical services.

Basis: stated · Source: 00-sources/04-development-invariants.md#determinism-contract, 00-sources/07-client-decisions.md#d-1--no-automatic-signing-of-release-packages-resolves-bd-011, 00-sources/05-research-build-trust-context.md#standards-that-most-directly-bind-this-products-development

Who — People

Who: which entities are trusted, by whom, and on what basis?

The trust relationships are now typed as TR-001..TR-008 over the domains DM-001..DM-008. The entities relied upon, and the basis of each, are: the build pipeline, trusted because its plugin-seam and GUI-boundary invariants are ArchUnit-enforced on every build and its quality gates must pass; the helper scanner scripts, trusted only after the startup SHA-256 check against the build-time MANIFEST.MF hash passes — trust verified, not assumed; the AI classifier, trusted only within bounds, confined to the closed taxonomy and the discovered method set and never allowed to invent or omit methods; and the human reviewer, whose override decisions are authoritative (confidence pinned to 1.0/0.0) and whose confidentiality is protected. The external AI providers are explicitly not trusted with more than the minimised payload, and their model behaviour is out of scope. The through-line is that trust is earned by a verifiable check, not conferred by assumption.

Basis: inferred · Source: 00-sources/06-architecture-and-data-governance.md#plugin-seam-invariants-archunit-enforced-at-build-time, 00-sources/02-security-policy.md#scanner-script-integrity-result-authenticity, 00-sources/06-architecture-and-data-governance.md#data-governance--what-is-and-is-not-transmitted

ID	Element	Description	Basis
TR-001	Scan host trusts its discovery-plugin classpath	The scan host loads and runs whatever discovery-plugin JARs are on its classpath via ServiceLoader, trusting them to emit only genuine discovered methods.	inferred
TR-002	Scan host trusts the hosted AI provider for bounded classification only	When Tier-3 AI is configured, the scan host trusts the hosted provider to return a classification — but only within a closed vocabulary and only for the methods the parser already found.	stated
TR-003	Hosted AI provider is entrusted with the minimal payload only	The scan host entrusts the hosted provider with exactly one test class's source plus method names and the taxonomy — and withholds everything else.	stated
TR-004	Consumer trusts the release by hash and provenance, not signature	A consumer or auditor trusts that a downloaded release artefact is the genuine one by checking its SHA-256 digest and its build provenance.	stated
TR-005	Build domain trusts the dependency supply conditionally	The build consumes third-party libraries and vulnerability data from upstream registries, trusting them only after gates have passed.	stated
TR-006	Distribution trusts the build pipeline to produce the release	The published release is trusted to be the output of the project's own build pipeline, not a substitute.	stated
TR-007	Auditor trusts the on-host audit artefacts as tamper-evident	An auditor relies on the audit-trail artefacts the scan host writes — evidence CSV, overrides YAML, attestation manifest, receipts — as a faithful, tamper-evident record.	stated
TR-008	Maintainer trusts researchers through the mediated disclosure channel	Security researchers are trusted to report vulnerabilities responsibly through a controlled channel that reaches the maintainer for triage and fix.	stated

Where — Location

Where: which security domains exist, and how do they relate?

The security domains are now typed as DM-001..DM-008 (scan host, build/CI, distribution, hosted AI, local/air-gapped AI, dependency supply, consumer/auditor, disclosure). Four domains of authority are implied by the material: the scan host (where traversal, parsing, discovery, hashing and all output happen locally, under no network by default); the CI/build domain (where gates and supply-chain invariants are enforced and release artefacts, checksums, attestations and receipts are produced); the external-AI-provider domain (reached only with -ai plus a non-local provider, trusted with the minimised payload only, model behaviour out of scope); and the distribution channel (GitHub, where artefact-plus-checksum substitution is the residual threat). The sharpest boundary is between the scan host and the provider domain, governed by the data-governance rules; the data-residency tiers (local / manual / hosted) are how a deployer chooses which boundary, if any, to cross.

Basis: inferred · Source: 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/06-architecture-and-data-governance.md#data-governance--what-is-and-is-not-transmitted, 00-sources/04-development-invariants.md#distribution-invariant-supply-chain

ID	Element	Description	Basis
DM-001	Scan-host domain		stated
DM-002	Build and CI domain		stated
DM-003	Distribution-channel domain		stated
DM-004	Hosted AI-provider domain (Tier 3)		stated
DM-005	Local and air-gapped AI domain (Tier 1/2)		stated
DM-006	Dependency-supply domain		stated
DM-007	Consumer and auditor verification domain		stated
DM-008	Vulnerability-disclosure domain		stated

When — Time

When: which security lifetimes, deadlines and time limits apply?

The security lifetimes that matter are contract and evidence lifetimes, not cryptographic key lifetimes — owner decision D-1 removes managed signing keys and therefore any key-rotation interval. The closed taxonomy and the audit/evidence schemas each live under a version identity: a version holds until a deliberate, documented bump, and historical classifications must remain valid under the version that produced them (the concern CO-004 and CO-009 answer). The reproducibility contract requires that a re-run on the same commit with the same cache reproduces the reviewed result for unchanged classes, so a classification's validity is bound to its content hash and taxonomy version rather than to wall-clock time. Evidence artefacts accumulate rather than expire: the GUI evidence CSV is "never overwritten", and attestation manifests and receipts are retained per release. No fixed retention period is stated in the material.

Basis: inferred · Source: 00-sources/04-development-invariants.md#audit--schema-stability, 00-sources/03-compliance-context.md#reproducibility-contract-core-promise, 00-sources/06-architecture-and-data-governance.md#audit-trail-artefact-binding-what-is-and-is-not-hash-bound

6. Logical layer — Designer's view

This layer describes the security services, policies, information and entities that deliver the concept.

What — Assets

What information needs protecting, and how is it classified?

The information to protect, and the one boundary that classifies it, is the data-governance rule on what may leave the scan host. Everything structural is always local — no network under any configuration: source traversal, parsing, method discovery, content-hash computation, CSV/SARIF output, cache read/write, override-file read and delta compare. When, and only when, -ai is used with a non-local provider, exactly three things are submitted per test class: (1) the taxonomy text (configuration, no project content); (2) the discovered test-method names and line numbers, which prevent invent/omit; and (3) the single test-class source file, truncated to -ai-max-class-chars. Never submitted: production source, build scripts, config files, credentials or secrets, DB schemas, infra definitions, other test files, or file paths and directory structure. This minimal egress set is the classified information flow the architecture governs; everything outside it is classified as never-transmitted.

Basis: stated · Source: 00-sources/06-architecture-and-data-governance.md#data-governance--what-is-and-is-not-transmitted

Why — Motivation

Why: which security policies govern the information and services?

The governing policy is the frozen-contract versioning discipline (PL-001): the taxonomy and the audit/evidence schemas (DeltaReport CSV columns, ClassificationOverride YAML fields) are frozen contracts — renaming, reordering or retyping a field is a breaking change that requires a schema-version bump and synchronized documentation in the same change, so downstream compliance tooling never desynchronises silently. Two further policy stances are implied by the sources and enforced by the services: a data-minimisation policy (only the three governed items ever leave the host; everything else never does) and a determinism policy (deterministic AST discovery is never allowed to depend on AI, and AI is kept bounded to the taxonomy and method set). These policies trace to control objectives CO-004/CO-005 (versioning), CO-007 (minimisation) and CO-002/CO-003/CO-014 (determinism and bounding). PL-001 carries the detail; the other two are stated here from the sources pending their own typed policy elements.

Basis: stated · Source: 00-sources/04-development-invariants.md#audit--schema-stability, 00-sources/06-architecture-and-data-governance.md#data-governance--what-is-and-is-not-transmitted, 00-sources/04-development-invariants.md#determinism-contract

ID	Element	Description	Basis
PL-001	Frozen-contract versioning discipline	Any change to a frozen product contract — the closed security taxonomy, or the DeltaReport / ClassificationOverride audit-and-evidence schemas — is permitted only with a version increment and the required documentation update made in the same change; silent renames, reorders, retypes or content changes to a frozen contract are prohibited.	stated
PL-002	Evidence-retention and release-cadence policy	Evidence and audit artefacts produced by the product (evidence CSVs, override YAML, attestation manifests, reproducibility receipts, SBOMs, gate reports) are retained at least as long as the consuming downstream audit cycle. Releases — hashed, not managed-key signed (D-1) — are produced on an event-driven / as-needed basis rather than on a fixed calendar. There is no shorter retention that would discard an artefact an auditor may still need.	stated

How — Process

How: which logical security services deliver the objectives?

Thirteen logical security services deliver the control objectives: scanner-script integrity verification (SS-001), structural-determinism guard (SS-002), AI output-bounding (SS-003), taxonomy version-control (SS-004), build and distribution integrity assurance (SS-005), data-minimisation enforcement (SS-006), override and review-decision confidentiality (SS-007), enforced test-quality gate (SS-008), coordinated vulnerability disclosure operation (SS-009), trust-basis-and-limits transparency (SS-010), audit and evidence-schema version-control (SS-012), audit-trail integrity (SS-013) and AI-result reproducibility (SS-014). These are the integrity, confidentiality, authenticity and audit services for this product; each states a capability independent of the mechanism that realises it, owns one or more attributes and is monitored by a measure. SS-001..SS-014 (SS-011 not used) carry the detail.

Basis: inferred · Source: 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected, 00-sources/06-architecture-and-data-governance.md#data-governance--what-is-and-is-not-transmitted, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced

ID	Element	Description	Basis
SS-001	Scanner-script integrity verification service	Provides assurance that every helper scanner script is integrity-verified against its build-time reference before it is allowed to run, and that discovery is aborted before any method is produced when the check fails, so output always reflects the peer-reviewed scanner logic.	stated
SS-002	Structural-determinism guard service	Keeps the structural discovery layer fully deterministic and strictly isolated from the probabilistic AI layer, so the same source revision always yields identical structural output that can be regenerated and compared, and the AI layer can never influence a structural field.	stated
SS-003	AI output-bounding service	Confines the AI classifier to the loaded, versioned taxonomy and to the explicit method set produced by the deterministic layer, validating every response so the model may change a label but can never invent, omit or re-scope methods or apply a label outside the taxonomy, even under prompt injection.	stated
SS-004	Taxonomy version-control service	Governs controlled, version-bumped evolution of the closed security taxonomy the classifier binds to, so every taxonomy change carries a version increment and the required same-PR documentation, and the effective taxonomy is fingerprinted (via the per-template prompt checksum) into the reproducibility receipt.	stated
SS-005	Build and distribution integrity assurance service	Enforces the supply-chain gates (dependency-vulnerability, licence allowlist, SBOM) and the distribution invariant on every build; consumers verify each release artefact against GitHub's automatic per-asset SHA-256 digest and the keyless build-provenance attestation (D-4). Managed-key signing is deliberately out of scope per decision D-1.	stated
SS-006	Data-minimisation enforcement service	Ensures that when a non-local AI provider is used only the permitted minimum leaves the host and the enumerated never-transmit categories never do, and that fully local and manual tiers remain available so an operator can keep all data on the host.	stated
SS-007	Override and review-decision confidentiality service	Keeps the override files and audit-trail artefacts that record human-review decisions out of every outbound AI payload, masks credential values by default, and ensures any confidentiality report against them is routed to critical triage.	stated
SS-008	Enforced test-quality gate service	Enforces the per-module coverage and mutation floors as failing build gates (root 70%/55%, methodatlas-ai 80%/70%, methodatlas-emit 65%/45%, methodatlas-gui-core 75%/50%, methodatlas-discovery-jvm 85%/60% — JaCoCo instruction / PIT mutation, as enforced in build.gradle; the root mutation standard is 55% per owner decision 2026-10-15, deliberately reduced from the earlier 60%, so the floors are risk-proportionate not strictly one-way), and (6.1.0) an enforced class-level JaCoCo >= 0.95 LINE gate on AuditWriter (measured 97.4%, RM-004), and keeps named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism) passing as a chosen (inferred) addition, so a regression in the authenticity, determinism or schema-stability controls is caught before release.	inferred
SS-009	Coordinated vulnerability disclosure operation	Operates a published, private coordinated-disclosure channel and tracks every received report against the stated acknowledge, triage and remediation service levels, so vulnerabilities in the product are handled predictably and visibly.	stated
SS-010	Trust-basis-and-limits transparency service	Publishes and keeps current a statement of what the product's trustworthiness rests on — GitHub's per-asset SHA-256 digests, deterministic reproducible evidence and enforced gates — and of its deliberate limit, that managed-key signing (non-repudiable proof of origin) is out of scope, so no trust claim is left unqualified.	stated
SS-012	Audit and evidence-schema version-control service	Governs controlled, version-bumped evolution of the DeltaReport and ClassificationOverride audit-and-evidence schemas consumed by downstream compliance tooling and the GUI audit trail, so every breaking change carries a schema version increment and the required same-PR documentation update and no consumer is ever silently desynchronised.	stated
SS-013	Audit-trail integrity service	Provides the audit-trail integrity bindings that the product can carry — the attestation manifest bound to content hash + commit SHA, reproducibility receipts bound to SHA-256 of every input, and the scanner-script MANIFEST.MF hash check — and keeps the GUI AuditWriter appending to the cumulative overrides.yaml and timestamped evidence CSVs rather than rewriting them. The GUI CSV/YAML carry no cryptographic binding (a recorded limitation); this service does not claim to make them tamper-evident.	inferred
SS-014	AI-result reproducibility service	Preserves reproducibility of AI-influenced output by reusing cached classifications keyed by content hash, applying human overrides deterministically with overridden confidence pinned to 1.0/0.0, and treating the reviewed classified record as the authoritative output that a same-commit, same-cache re-run reproduces for unchanged classes.	stated

Who — People

Who: which entities, roles and privilege profiles exist?

Entities and privilege profiles are not separately typed; the actors (CLI operator, GUI reviewer, CI runner, release owner) are captured via the domains DM-001..DM-008 and the trust relationships TR-001..TR-008. Four roles act on the product and its evidence: the CLI operator, who runs scans and chooses the AI provider and data-residency tier — and whether any data leaves the host at all; the GUI reviewer, whose override and "Save All Changes" decisions become the authoritative, confidentiality-protected audit trail written to .methodatlas/; the CI runner, a non-interactive identity that executes the enforced gates and reads any AI key from a named environment variable; and the release owner / maintainer, who publishes artefacts and keyless build-provenance attestations (GitHub exposes each asset's SHA-256 digest) and operates coordinated disclosure. Separation of duties is light because the product is maintained by a single owner — a concentration recorded as a support-model limitation at the service-management layer rather than resolved by distinct privilege profiles here.

Basis: inferred · Source: 00-sources/01-product-overview.md#audit-trail-artefacts-gui, 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/00-engagement-brief.md#library-parameters

Where — Location

Where: how are the security domains defined and associated with each other?

Domain associations are captured through the typed domains DM-001..DM-008 and the trust relationships TR-001..TR-008; no separate domain-association (DA) elements are needed at this layer. The scan-host domain is self-contained by default — the structural pipeline never associates with any external domain. The only outbound association is scan host → external-AI-provider domain, and it is a tightly specified interface: it opens only under -ai with a non-local provider, carries just the three governed payload items over HTTPS, and is the single place project data crosses a trust boundary. Internally, the plugin seam is an enforced association boundary — non-plugin code must not depend on a discovery plugin (plugins resolve only via ServiceLoader), plugins depend only on methodatlas-api, and the GUI reaches the AI engine only through its factory, all ArchUnit-verified. The CI/build domain associates with the distribution channel at release, bound by GitHub's per-asset SHA-256 digests. The data-residency tiers are the configurable form of the scan-host-to-provider association.

Basis: inferred · Source: 00-sources/06-architecture-and-data-governance.md#data-governance--what-is-and-is-not-transmitted, 00-sources/06-architecture-and-data-governance.md#plugin-seam-invariants-archunit-enforced-at-build-time, 00-sources/06-architecture-and-data-governance.md#data-residency-tiers

When — Time

When: what is the security processing cycle?

Security processing is tied to three cycles. Per-change: every commit updates README, docs and Javadoc with the code and must satisfy the static-analysis and schema-stability rules. Per-build: the enforced gates run every build — unit tests, PMD and SpotBugs (on every build JDK), Error Prone on JDK ≤ 24 only (the JDK-21 CI/CD path; on the JDK-25+ development build Error Prone is disabled and PMD + SpotBugs are the active static analyzers — AD-011), JaCoCo instruction-coverage floors and PIT mutation floors (per-module and risk-proportionate; the root mutation standard is 55% per owner decision 2026-10-15, deliberately reduced from the earlier 60% — floors are not strictly one-way), dependency-check (CVSS≥7.0 fails), the license allowlist, SBOM generation and the ArchUnit invariants — and the scanner-script hash check runs at the start of every scan execution. Per-release: checksums, attestation manifests and reproducibility receipts are produced and published. Re-certification of a classification is content-driven: a class is re-classified only when its content hash changes, otherwise the cached or overridden result stands.

Basis: stated · Source: 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/04-development-invariants.md#deliverables-on-every-change, 00-sources/06-architecture-and-data-governance.md#per-module-quality-floors-enforced-gates, 00-sources/09-release-6.1.0.md#error-prone-disabled-on-jdk-25-documented-limitation, 00-sources/09-release-6.1.0.md#owner-release-gate-decisions-2026-10-14

7. Physical layer — Builder's view

This layer describes the mechanisms, rules, infrastructure and data structures that implement the design.

What — Assets

What data structures and stores hold the information?

The built stores that hold trust-relevant information are: the AI result cache (keyed by SHA-256 content hash, giving reproducibility for unchanged classes); the classification-override store (ClassificationOverride YAML, human-reviewed corrections persisted with confidence pinned to 1.0/0.0); the reproducibility receipts (schema v2, recording SHA-256 of every input including per-template prompt checksums); the attestation manifest (each security test with its content hash and the commit SHA); and the GUI .methodatlas/ audit trail — a timestamped evidence CSV (DeltaReport schema, never overwritten, accumulating per save) plus the cumulative overrides.yaml. The material is explicit that the attestation, the receipts and the scanner-script check carry cryptographic binding, whereas the GUI evidence CSV/YAML are append-only and timestamped but not themselves hash-bound — a distinction the architecture must state and not overstate.

Basis: stated · Source: 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected, 00-sources/01-product-overview.md#audit-trail-artefacts-gui, 00-sources/06-architecture-and-data-governance.md#audit-trail-artefact-binding-what-is-and-is-not-hash-bound

Why — Motivation

Why: which security rules, practices and procedures apply?

The concrete procedures that implement the policies are the enforced build gates and the disclosure process. The gate procedure: ./gradlew build must pass compile, unit tests, PMD and SpotBugs (on every build JDK), Error Prone on JDK ≤ 24 only (the JDK-21 CI/CD path; on the JDK-25+ development build Error Prone is disabled and PMD + SpotBugs are the active static analyzers — AD-011), JaCoCo coverage verification and PIT mutation at risk-proportionate per-module floors (the root mutation standard is 55% per owner decision 2026-10-15, deliberately reduced from the earlier 60% — floors are not strictly one-way), dependency-check failing on CVSS≥7.0, the license allowlist and SBOM generation; the ArchUnit tests enforce the plugin-seam and GUI-boundary invariants; and the distribution invariant (ANTLR grammar-compiler JARs excluded from lib/) is re-verified after any ANTLR bump. The disclosure procedure: private coordinated disclosure via GitHub advisory or PGP email, with fixed acknowledge/triage/fix SLAs, and reports affecting audit-trail integrity, override confidentiality or scanner-script authenticity treated as critical regardless of CVSS. These procedures are how the control objectives become day-to-day practice.

Basis: stated · Source: 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/06-architecture-and-data-governance.md#per-module-quality-floors-enforced-gates, 00-sources/02-security-policy.md#vulnerability-handling, 00-sources/09-release-6.1.0.md#error-prone-disabled-on-jdk-25-documented-limitation, 00-sources/09-release-6.1.0.md#owner-release-gate-decisions-2026-10-14

How — Process

How: which security mechanisms implement the services?

The mechanisms are now typed as SM-001..SM-017, each realising a logical service and grounded in code (and implemented by the components SC-001..SC-019). The logical services are realised by: the Gradle build configuration (the quality-gate tasks and the lib/ exclusion of ANTLR grammar-compiler JARs); the ArchUnit tests ArchitectureTest / GuiBoundaryTest (the plugin-seam and GUI-boundary invariants); the ServiceLoader plugin seam (runtime resolution with no compile-time coupling); the scanner-script integrity check (runtime SHA-256 of each helper script compared to the MANIFEST.MF build-time hash, aborting before execution); the content-hash and receipt machinery (SHA-256 of inputs and prompts); and GitHub's automatic per-asset SHA-256 digest on the release assets plus keyless SLSA build provenance (D-4) — with managed-key signing deliberately excluded by decision D-1.

Basis: inferred · Source: 00-sources/06-architecture-and-data-governance.md#plugin-seam-invariants-archunit-enforced-at-build-time, 00-sources/02-security-policy.md#scanner-script-integrity-result-authenticity, 00-sources/07-client-decisions.md#d-1--no-automatic-signing-of-release-packages-resolves-bd-011

ID	Element	Description	Basis
SM-001	Scanner-script integrity verification mechanism	Realises SS-001 by comparing every bundled helper scanner script against a SHA-256 reference recorded as a JAR MANIFEST.MF attribute at build time, and hard-aborting discovery before any method is produced when the computed digest does not match, so no output can originate from tampered script bytes.	stated
SM-002	Deterministic AST-discovery boundary mechanism	Realises part of SS-002 by performing all structural discovery through the deterministic TestDiscovery SPI (AST parsing only, no AI call) and enforcing, with an ArchUnit architecture test, that no discovery or API module may reference the AI engine — so the structural layer is both deterministic and physically unable to be influenced by the probabilistic layer.	stated
SM-003	AI classifier output-bounding mechanism	Realises SS-003 by driving the classifier with an explicit, AST-derived method list and a loaded closed taxonomy, capping per-class source at maxClassChars, and reconciling every model response against that authoritative method set and label vocabulary so the model may change a label but can never invent, omit or re-scope a method or apply a label outside the taxonomy.	stated
SM-004	Taxonomy version-control mechanism	Realises SS-004 by resolving a single version identifier for the closed taxonomy the classifier binds to — a built-in revision string for the packaged taxonomies and a content fingerprint for a custom file — stamping it into each AI-classified record, folding it into the reproducibility receipt, and folding it into the AI cache key so a run is always tied to the taxonomy that produced it.	stated
SM-005	Supply-chain build-gate mechanism	Realises the build-integrity side of SS-005 by gating the Gradle build on a dependency-vulnerability scan that fails on CVSS 7.0 or above, a runtime-licence allowlist, and generation of a CycloneDX 1.5 SBOM, and by enforcing the distribution invariant that ANTLR grammar-compiler JARs never ship in the runtime image.	stated
SM-006	Data-minimisation and residency-tier mechanism	Realises SS-006 by building the outbound AI payload from only the taxonomy, the method list and one class at a time (capped by maxClassChars), offering a fully local Tier-1 provider and an offline manual Tier-2 path that transmit nothing, with all network access code-confined to the AI package by an ArchUnit rule. As of 6.1.0 a dedicated ZeroEgressTest (RM-007) asserts zero non-loopback egress under Tier 1/2, realised by this mechanism.	stated
SM-007	Review-decision confidentiality mechanism	Realises SS-007 by keeping the override files and audit-trail artefacts that record human-review decisions entirely out of the outbound AI payload, and by masking detected credential values by default through the catalog-based credential detector so secret material is not echoed into prompts or output.	stated
SM-008	Enforced quality-gate mechanism	Realises SS-008 by wiring the per-module JaCoCo coverage floors (and, as of 6.1.0, the class-level AuditWriter >= 0.95 LINE rule — RM-004) and PIT mutation thresholds, plus PMD and SpotBugs (which run on both JDKs), the ArchUnit structural tests, and — on JDK <= 24, which includes the JDK-21 CI/CD build — Error Prone, into the Gradle check task and CI, so a regression that drops coverage or mutation score, trips static analysis or breaks an architecture rule fails the build before release. Error Prone runs on JDK <= 24 (the JDK-21 CI/CD path that gates every merge and release); on the JDK-25+ development build it is disabled (no release supports JDK 27) and PMD + SpotBugs are the active static-analysis gates — see AD-011.	stated
SM-009	Coordinated vulnerability disclosure channel mechanism	Realises SS-009 by operating a published private reporting channel — a GitHub private security advisory plus a PGP-protected e-mail address — and tracking each received report against the stated acknowledge, triage and remediation service levels, consistent with the ISO/IEC 29147 and 30111 disclosure and handling practices.	stated
SM-010	Trust-basis-and-limits statement mechanism	Realises SS-010 by publishing and keeping current a documented statement of what the product's trustworthiness rests on — GitHub's per-asset SHA-256 digests, deterministic reproducible evidence and enforced gates — and of its deliberate limit that managed-key signing is out of scope, across the README and docs set, with the strict-mode docs build failing on a broken or missing page.	stated
SM-012	Audit and evidence-schema version-control mechanism	Realises SS-012 by parsing the DeltaReport and ClassificationOverride audit-and-evidence schemas forward-compatibly against an explicit schema version constant, so a reader tolerates an added column while a breaking change is forced to bump the version and carry the same-PR documentation update required by policy PL-001.	stated
SM-013	Audit-trail integrity binding mechanism	Realises SS-013 by providing the hash bindings the product can carry — the GUI AuditWriter now populating the content_hash column and writing a manifest.sha256, the attestation manifest bound to content hash and commit SHA, the reproducibility receipt bound to SHA-256 of every input, and the scanner-script MANIFEST check — while recording honestly that this is hash-only integrity, with no managed-key signing (decision D-1).	inferred
SM-014	AI-result reproducibility mechanism	Realises SS-014 by reusing cached AI classifications keyed by per-class content hash (with the taxonomy version folded into the key so a hit was produced under the current taxonomy), applying human overrides deterministically with overridden confidence pinned to 1.0/0.0, and fingerprinting the inputs in the reproducibility receipt, so a same-commit, same-cache re-run reproduces the reviewed record for unchanged classes.	stated
SM-015	Byte-level output-determinism guard mechanism	Realises the reproducibility side of SS-002 by removing the environmental sources of output divergence — line endings, locale-sensitive path ordering and content hashing across operating systems — and proving byte-identical regeneration locally with a dedicated determinism test, with a cross-OS CI matrix defined to confirm it on real runners (pending its first run, RM-001), so the same source revision yields an identical structural artefact on any host.	inferred
SM-016	Classification-accuracy evaluation mechanism	Realises the assurance side of SS-003 by measuring how well the bounded classifier labels against a known-answer set — precision, recall and agreement computed by a dedicated command — so the quality of the AI layer is an observable, regenerable number rather than an assumption.	inferred
SM-017	Release provenance and digest mechanism	Realises the distribution-integrity side of SS-005 by relying on the per-asset SHA-256 digest GitHub Releases records for every artefact as the authoritative digest consumers verify against (decision D-3 — no separate SHA256SUMS is shipped), and by generating a keyless SLSA build-provenance attestation for the release artefacts and running OpenSSF Scorecard (decision D-4 — keyless, no managed keys).	inferred
SM-018	Comment-redaction mechanism	Realises the data-minimisation service SS-006 by stripping every comment from a source file to spaces before the outbound AI payload is built, fail-closed per language — if a to-be-sent file's language cannot be fully redacted the run aborts before anything is sent. Grounded in the CommentRedactor SPI, the CommentRedaction fail-closed service, the per-language redactors and the shared CommentBlanker.	stated

Who — People

Who: which users, applications and interfaces interact with the system?

The system's external interaction endpoints are: the hosted AI providers' HTTPS APIs (OpenAI, Anthropic, Azure OpenAI, Groq, xAI, GitHub Models, Mistral, OpenRouter), reached only with -ai and a non-local provider and trusted with the minimised payload only; the local Ollama endpoint on the scan host (Tier-1, no API key, no outbound connection); and GitHub, as both the distribution channel for the shipped artefacts and checksums and the coordinated-disclosure intake (private advisory). The human endpoints are the CLI operator and the GUI reviewer at the workstation. Secret delivery at these endpoints uses a named environment variable (-ai-api-key-env) for CI, or no key at all for Ollama and the manual workflow.

Basis: stated · Source: 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected

Where — Location

Where: which platforms and network infrastructure carry the system?

Four platform zones carry the system. The scan host (analyst workstation or build agent) runs all structural processing locally. The CI/build zone runs the enforced gates and produces the release artefacts, checksums, SBOM, attestations and receipts. The external-provider zone is off-host and reached only over HTTPS. The distribution channel is GitHub. The AI boundary is expressed as three data-residency tiers: Tier 1 — Ollama local (data never leaves the host; air-gapped and strict-DLP); Tier 2 — manual prepare/consume (the operator physically carries prompt files to an authorised workstation and decides exactly what is submitted); Tier 3 — hosted provider over HTTPS (provider policy governs retention; EU-region options azure_openai and mistral). Issues needing physical access to the analyst workstation are explicitly out of the product's security scope.

Basis: stated · Source: 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/04-development-invariants.md#distribution-invariant-supply-chain

When — Time

When: in what order and at what times do the controls execute?

The control sequence at run time is: at startup each discovery plugin computes the SHA-256 of its helper scanner script and compares it to the MANIFEST.MF build-time hash, aborting before any method is produced on a mismatch; only then does structural discovery run (traverse, parse, discover, content-hash, emit); optional AI classification follows, bounded to the taxonomy and the discovered method set, with cache and override consulted first so unchanged classes are not re-sent. In the build/release sequence, the enforced gates run on every build and must all pass before an artefact exists, and only then are checksums, attestation manifests and reproducibility receipts produced and published. The ordering is load-bearing: integrity is verified before execution, and quality is proven before release.

Basis: inferred · Source: 00-sources/02-security-policy.md#scanner-script-integrity-result-authenticity, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/06-architecture-and-data-governance.md#per-module-quality-floors-enforced-gates

8. Component layer — Tradesman's view

This layer describes the products, standards, identities and protocols that make up the mechanisms.

What — Assets

What detailed data structures and formats are used?

The detailed, security-relevant data formats are: the DeltaReport CSV columns and the ClassificationOverride YAML fields (the frozen audit-schema surface consumed by downstream compliance tooling, versioned and never silently retyped); the reproducibility-receipt schema v2 (SHA-256 of every input plus per-template prompt checksums); the attestation manifest (each security test bound to its content hash and the commit SHA); SARIF 2.1.0 (for SAST-pipeline integration); the CycloneDX 1.5 SBOM; and SHA-256 as the single hashing format throughout (content fingerprints, receipts, scanner-script check, GitHub's per-asset release digest). These formats are now typed as standards ST-001..ST-012 and realised by components SC-001..SC-019.

Basis: stated · Source: 00-sources/04-development-invariants.md#audit--schema-stability, 00-sources/06-architecture-and-data-governance.md#audit-trail-artefact-binding-what-is-and-is-not-hash-bound, 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected

Why — Motivation

Why: which security standards apply to the components?

The external standards that apply are named in the sources, in two groups. Binding the product's own build and output: NIST SP 800-218 (SSDF — PS.2, PS.3.2, PW.4), SLSA v1.2 (build-provenance, target L3), CISA/NSA Secure by Design, OWASP Top 10 for LLM Applications 2025 (LLM01/02/05/07/09), CycloneDX/ECMA-424 and Sigstore/cosign+Rekor norms, Reproducible Builds, ISO/IEC 29147+30111 (vulnerability disclosure and handling) and OpenSSF Scorecard. Realised through enforced gates and formats: JaCoCo, PIT, PMD, SpotBugs, OWASP dependency-check (CVSS≥7.0), the license allowlist, SARIF 2.1.0 and SHA-256 checksums. Note the deliberate boundary (decision D-1): the product adopts GitHub's per-asset hashes but not managed-key signing, so cosign/GPG-style managed-key release signing and the Scorecard Signed-Releases check are deliberately not met. Keyless SLSA build provenance IS adopted (decision D-4) — it needs no managed keys — so SLSA provenance is in scope, not excluded. These standards are now typed as ST-001..ST-012 (realised by SC-001..SC-019).

Basis: stated · Source: 00-sources/05-research-build-trust-context.md#standards-that-most-directly-bind-this-products-development, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected

ID	Element	Description	Basis
ST-001	SHA-256 secure hash (FIPS 180-4)	Integrity digests and content fingerprints across the product are computed with SHA-256 as specified in FIPS 180-4; no weaker digest is used where a tamper-evident binding is claimed.	stated
ST-002	JAR manifest SHA-256 digest attributes	The build-time reference digest of each bundled helper scanner script is recorded as a SHA-256 attribute in the plugin JAR MANIFEST.MF and generated during the build, not hand-committed.	stated
ST-003	Java 21 platform baseline	The product builds and runs on Java 21 or later, enforced at Gradle configuration time, so the toolchain underpinning deterministic discovery and the quality gates is a fixed, known baseline.	stated
ST-004	SARIF 2.1.0 static-analysis result format	The SARIF output emitter conforms to SARIF 2.1.0; a change to the emitted structure is a versioned, documented change under the frozen-contract discipline.	stated
ST-005	CycloneDX 1.5 software bill of materials	The build emits a CycloneDX 1.5 SBOM for the distributed artefacts; the SBOM schema version is pinned (VERSION_15) and changed only deliberately.	stated
ST-006	CVSS v3 vulnerability severity scoring	Dependency vulnerabilities are scored with CVSS v3; the build fails when any runtime dependency carries a vulnerability scored 7.0 or above.	stated
ST-007	SPDX licence identifiers	Runtime-dependency licences are expressed as SPDX short-form identifiers and checked against the allowlist at config/allowed-licenses.json; a non-allowlisted licence fails the build.	stated
ST-008	CSV and YAML audit-schema formats	The DeltaReport (CSV) and ClassificationOverride and overrides.yaml (YAML) audit-and-evidence artefacts use the standard CSV and YAML encodings with a declared schema version, so a breaking field change is a versioned, documented change.	stated
ST-009	Coordinated vulnerability disclosure and handling (ISO/IEC 29147 + 30111)	The disclosure channel and internal handling process follow the external-reporting and triage/remediation practices described by ISO/IEC 29147 and 30111.	stated
ST-010	OpenPGP message and signature format	The published vulnerability-reporting contact supports OpenPGP-encrypted e-mail so a reporter can transmit sensitive details confidentially.	stated
ST-011	SLSA build provenance (in-toto / Sigstore keyless)	Release artefacts carry an in-toto build-provenance attestation produced by keyless Sigstore signing (no managed keys), consistent with decision D-4 and the D-1 no-managed-key boundary.	stated
ST-012	OpenSSF Scorecard security health checks	The repository runs the OpenSSF Scorecard checks in CI so its security-health posture is measured against a recognised open-source baseline, consistent with decision D-4.	stated

How — Process

How: which security products and tools are used?

The concrete products and tools are: Java 21+ (required and enforced at configuration time) and Node.js 18+ (only for the TypeScript discovery plugin, self-disabling when absent); JavaParser and an ANTLR4 grammar and runtime for deterministic AST discovery (with the ANTLR grammar-compiler JARs excluded from the shipped lib/); Gradle as the build system driving the quality-gate plugins — PMD and SpotBugs (on every build JDK), Error Prone on JDK ≤ 24 only (the JDK-21 CI/CD path; disabled on the JDK-25+ development build, where PMD + SpotBugs are the active static analyzers — AD-011), JaCoCo, PIT, OWASP dependency-check, the license check and CycloneDX (SBOM); a deterministic Aho-Corasick engine for credential detection; and the AI provider clients (Ollama local plus the OpenAI-compatible, Anthropic and Azure OpenAI vendors). These tool and version choices are now typed as components SC-001..SC-019.

Basis: stated · Source: 00-sources/04-development-invariants.md#build--platform-constraints, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected, 00-sources/09-release-6.1.0.md#error-prone-disabled-on-jdk-25-documented-limitation

ID	Element	Description	Basis
SC-001	JavaParser AST discovery component	Implements the deterministic AST-discovery mechanism for JVM test sources using the JavaParser library, producing a stable syntax model from which test methods, line numbers and content hashes are derived without any inference.	stated
SC-002	ANTLR4-runtime grammar discovery component	Implements grammar-based deterministic discovery for the non-JVM languages (C#, ABAP, COBOL, Go, PowerShell) using the ANTLR4 runtime, while the ANTLR grammar-compiler JARs are deliberately excluded from the shipped distribution.	stated
SC-003	ArchUnit architecture-boundary component	Enforces the plugin-seam, AI-out-of-discovery and network-confinement boundaries at build time using ArchUnit tests, so the determinism and data-minimisation mechanisms cannot be silently violated by a code change.	stated
SC-004	ServiceLoader plugin-registry component	Resolves discovery and patcher plugins purely from the classpath via the Java ServiceLoader, and now orders providers deterministically by plugin id so cross-language output order is independent of classpath order.	stated
SC-005	Determinism-guard component (ContentHasher, PortablePathOrder, LineEnding)	The concrete classes that make the structural scan output byte-identical across platforms — line-ending-normalised content hashing, a portable path ordering, and explicit newline emission in the output writers.	stated
SC-006	Determinism CI-matrix component	The cross-platform determinism test and the three-OS GitHub Actions matrix designed to prove structural output is byte-identical on Linux, Windows and macOS by comparing each leg against committed golden files and against each other — proven locally, pending the matrix's first run on GitHub (RM-001).	inferred
SC-007	AI suggestion engine and provider-client component	The AI engine and its sealed set of provider clients that confine classification to the closed taxonomy and the explicit discovered-method list, and that implement the local and hosted data-residency tiers.	stated
SC-008	Security-taxonomy and taxonomy-version component	The closed built-in security taxonomies and the taxonomy-version resolver that stamps each AI-classified record and is now folded into the AI cache key so a reused result can never carry a taxonomy version it was not classified under.	stated
SC-009	Classification-accuracy evaluation component	The offline evaluation command and pure metric engine that measure AI classification quality (precision, recall, F1 per taxonomy tag, plus the securityRelevant confusion matrix) against a human-reviewed ground-truth label set.	inferred
SC-010	Dependency-vulnerability and licence gate component	The OWASP dependency-check plugin and the licence-allowlist check that fail the build on a high-severity dependency CVE or a non-allowlisted licence, implementing the supply-chain arm of the build-gate mechanisms.	stated
SC-011	CycloneDX SBOM component	The CycloneDX Gradle plugin that produces a CycloneDX 1.5 software bill of materials for every build, published as a release asset so consumers can inspect the shipped dependency set.	stated
SC-012	Test-quality gate stack component	The JaCoCo coverage, PIT mutation, PMD, SpotBugs and Error Prone tooling, wired per-module into the Gradle build, that implements the enforced test-quality gate mechanism with risk-proportionate per-module floors (the root mutation standard is 55% per owner decision 2026-10-15 — floors are not strictly one-way). As of 6.1.0 the project supports JDK 21+ and builds on two JDKs — the development machine on JDK 27 and CI/CD on JDK 21 (every workflow sets java-version '21') — with the toolchain bumped (Gradle 9.8.1, PMD 7.28.0, SpotBugs 4.10.5 / plugin 6.5.13, PIT core 1.30.1 / junit5 plugin 1.2.3) so the gates run on both. PMD and SpotBugs run on every build JDK; Error Prone is disabled on JDK 25+ (no release supports JDK 27) so it does not run on the JDK-27 dev build, but it does run on the JDK-21 CI/CD build (JDK <= 24), which is the enforced static-analysis path — see AD-011.	stated
SC-013	Release provenance and Scorecard component	The GitHub Actions components that establish release trust without managed keys — keyless SLSA build provenance via artifact attestation, the OpenSSF Scorecard workflow, and GitHub's automatic per-asset SHA-256 digest.	inferred
SC-014	Audit-trail and evidence-schema component	The AuditWriter, attestation and receipt writers plus the versioned audit-schema types that produce the audit trail and bind its cryptographically-hashable artefacts, and that govern the stability of the evidence schema.	stated
SC-015	AI result-cache and override component	The content-hash-keyed AI result cache (now folding the taxonomy version into its key) and the deterministic override mechanism, which together make AI-influenced output reproducible for unchanged classes.	stated
SC-016	Credential-detection and masking component	The clean-room Aho-Corasick credential detector and default value masking that keep secrets in scanned source and review artefacts from being exposed, supporting the review-decision confidentiality mechanism.	stated
SC-017	Bundled scanner-script integrity component	The bundled TypeScript and Python scanner scripts and the integrity-check classes that verify their SHA-256 against a build-time manifest attribute before execution.	stated
SC-018	Vulnerability-disclosure channel component	The GitHub private vulnerability advisory channel and the PGP-encrypted security mailbox that implement the coordinated vulnerability disclosure mechanism.	stated
SC-019	Documentation publication component	The MkDocs and pandoc toolchain that publishes the trust-basis-and-limits statement and the rest of the documentation as a strict-built site and a release PDF.	stated
SC-020	Comment-redaction component	The MethodAtlas CommentRedactor SPI, its per-language redactor implementations, and the shared CommentBlanker and fail-closed CommentRedaction service that together implement the comment-redaction mechanism SM-018.	stated

Who — People

Who: which identities, functions and access rights are configured?

At component level the configured identity and access surface is deliberately small. The only credential the product itself handles is the AI provider API key, and the material prescribes how: -ai-api-key-env reads it from a named environment variable (recommended for CI), with documented file-based delivery (CyberArk Conjur, Kubernetes secrets) and Vault / Secrets-Manager retrieval patterns; Ollama and the manual workflow need no key at all. Detected third-party credentials in scanned code are masked by default and never live-verified. There are no product-managed user accounts, roles or ACLs in this scope — access control is the deployer's, and signing keys are deliberately absent by decision D-1. The credential-configuration surface is captured by component SC-016 (credential detection and masking) and the three data-residency tiers; no separate identity-entitlement elements are typed.

Basis: stated · Source: 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/06-architecture-and-data-governance.md#data-governance--what-is-and-is-not-transmitted

Where — Location

Where: which nodes, addresses, ports and protocols are involved?

Not applicable: No component-level node/address/port/protocol inventory exists for the product's own build and release in this scope. The relevant endpoints — the hosted providers' HTTPS APIs, the local Ollama endpoint and the GitHub distribution/disclosure channel — are addressed at the physical layer (Physical · Who and Physical · Where), and the typed components SC-001..SC-019 and standards ST-001..ST-012 name tools, products and formats, not network addresses or ports. There is no distinct component-level content to add without inventing it.

When — Time

When: what is the timing and sequencing of each security step?

Not applicable: No component-level timing, timeout, schedule or rotation parameters are in scope. Owner decision D-1 removes managed signing keys and therefore any key-rotation interval, and the material defines no component-level timeouts; control sequencing is captured at the physical layer (Physical · When) and gate/measurement cadence at the logical and service-management layers. The typed components SC-001..SC-019 and operations SO-001..SO-007 carry no component-level timing/rotation attributes; control sequencing is at the physical layer.

9. Service Management layer — Service manager's view

This layer describes how security is operated, measured, supported and kept current.

What — Assets

What assures operational continuity of security?

For an open-source tool there is no always-on runtime service to fail over; operational continuity of security means that every build and release reproduces the trust evidence intact. That continuity is assured by the evidence artefacts EV-001..EV-014: the scanner-script hash-check log and abort-on-mismatch test result (EV-001); the reproducibility receipt and determinism-test result (EV-002); the AI-bounding validation and method-set reconciliation report (EV-003); the taxonomy version history and receipt fingerprint (EV-004); the supply-chain gate reports, SBOM and per-asset digests (EV-005); the data-governance payload-test and zero-egress-test result (EV-006; the direct Tier 1/2 ZeroEgressTest landed in 6.1.0, RM-007 DONE); the override/credential-masking test result (EV-007); the JaCoCo and PIT reports (EV-008); the vulnerability-disclosure SLA record (EV-009); the published trust-basis-and-limits statement (EV-010); the audit/evidence-schema version history (EV-012); the audit-trail integrity test result (EV-013); and the AI-result reproducibility regression result (EV-014). Regenerating these on every build is what keeps the assurance continuous. EV-001..EV-014 (EV-011 not used) carry the detail.

Basis: inferred · Source: 00-sources/04-development-invariants.md#reproducibility--provenance-features-already-in-the-product, 00-sources/06-architecture-and-data-governance.md#audit-trail-artefact-binding-what-is-and-is-not-hash-bound, 00-sources/02-security-policy.md#key-trust-assets-implied-for-driver-derivation, 00-sources/09-release-6.1.0.md#rm-007--real-tier-12-zero-egress-test-done-in-610

ID	Element	Description	Basis
EV-001	Scanner-script hash-check log and abort-on-mismatch test result		stated
EV-002	Reproducibility receipt and determinism-test result		stated
EV-003	AI-bounding validation and method-set reconciliation report		stated
EV-004	Taxonomy version history and reproducibility-receipt fingerprint		stated
EV-005	Supply-chain gate reports, SBOM and per-asset digests		stated
EV-006	Data-governance payload and zero-egress tests		stated
EV-007	Override/audit payload-exclusion and credential-masking test result		stated
EV-008	JaCoCo coverage and PIT mutation reports		inferred
EV-009	Vulnerability-disclosure SLA tracking record		stated
EV-010	Published trust-basis-and-limits statement		stated
EV-012	Audit and evidence-schema version history		stated
EV-013	Audit-trail integrity test result		inferred
EV-014	AI-result reproducibility regression-test result		stated
EV-015	Comment-redaction conformance test result		stated

Why — Motivation

Why: how is operational security risk managed?

Operational security risk is managed primarily by closing it through the control objectives and their measures; where a risk is deliberately retained, it is governed by an explicit exception rather than left implicit. Eleven exceptions (EX-001..EX-011) are recorded, most an owner-accepted, time-boxed residual under decision D-2 (expiring 2026-12-31): EX-006 was resolved (D-3); EX-008 and EX-009 were resolved in 6.1.0 by remediation — the real Tier 1/2 zero-egress test (RM-007) and the class-level AuditWriter coverage gate (RM-004) shipped and verified green on JDK 27; at the 6.1.0 release gate (2026-10-14) EX-002 (GUI audit-trail hash-binding, RM-B) and EX-007 (per-record taxonomy-version field, RM-C) were closed on the owner's test-verification condition — the named JUnit tests exist and pass green — and are now retired by remediation; EX-010 remains open, its Scorecard/SLSA workflows implemented but awaiting the first green run (RM-003); the new EX-011 records the owner's interim, time-boxed acceptance (expiring 2026-12-31) of the Error-Prone-on-JDK-27 residual (Error Prone disabled on JDK 25+, AD-011), with PMD and SpotBugs on JDK 27 and Error Prone on the JDK-21 CI/CD path as compensating controls; and the rest remain interim. The principal standing residual is EX-001: the product relies on GitHub's per-asset SHA-256 digest (D-3) and keyless build provenance (D-4) but does not apply managed-key release signing (owner decision D-1), so a whole-JAR substitution at the distribution channel (RO-013), in which the artefact and its digest are replaced together, is not cryptographically defeated by a signature. EX-001 excepts the signing-related reach of CO-006 (build and distribution integrity) and CO-011 (trust basis and its limits). Each exception was accepted by the owner as an explicit authority act (D-2), not self-approved by the architecture.

Basis: stated · Source: 00-sources/07-client-decisions.md#d-1--no-automatic-signing-of-release-packages-resolves-bd-011, 00-sources/02-security-policy.md#scanner-script-integrity-result-authenticity, 00-sources/09-release-6.1.0.md#version-unification-030--610

ID	Element	Description	Basis
EX-001	Owner-accepted unsigned-release residual (interim, expires 2026-12-31)	Owner decision D-1 declines managed-key cryptographic signing of release packages (Sigstore/cosign, GPG or any long-lived signing keyring) because the key management, rotation and administration burden is not justified for an application of this size. Trust therefore rests on GitHub's verifiable per-asset SHA-256 digests (D-3), reproducibility receipts, the scanner-script manifest-hash check and the enforced gates. The consequence is that a whole-JAR repackaging (script and its MANIFEST.MF hash rewritten together) or a distribution-channel substitution (artefact and its digest replaced together) is not cryptographically defended by a managed-key signature, because a hash gives integrity and a reference to compare against but not non-repudiable proof of origin. OpenSSF Scorecard's Signed-Releases check is therefore deliberately not met. PARTIAL MITIGATION (D-4): the release now attaches keyless SLSA build provenance (no managed keys), which lets a consumer verify the artefact was produced by this repository's pipeline and makes tampering during the build detectable — so the residual is narrower than before, though the artefact itself is still not managed-key signed.	stated
EX-002	GUI audit artefacts hash-bound — RESOLVED in 6.1.0 (hash-binding verified by JUnit tests)	RESOLVED in 6.1.0. This exception recorded the residual against the audit-defensibility objective (CO-013) that arose from the BA-013 limitation: the GUI audit-trail artefacts under .methodatlas/ — the evidence CSV and overrides.yaml — were append/accumulate and timestamped but carried no cryptographic binding (no content hash chaining the records to the run that produced them), leaving GUI override/audit records open to undetected after-the-fact modification. Fix RM-B populates the content_hash column and writes a manifest.sha256 over the audit artefacts (mechanism SM-013 / component SC-014), making a rewrite detectable. At the 6.1.0 release gate the owner confirmed closure conditional on passing JUnit tests, and those tests exist and pass (verified green): methodatlas-gui-core/src/test/java/org/egothor/methodatlas/gui/service/AuditWriterTest.java — evidenceCsv_contentHashIsWrittenVerbatim (the content_hash column is written) and manifest_recordsCorrectSha256OfCsvAndOverrides / manifest_keepsOldCsvDigestAndRefreshesOverrides (the .methodatlas/manifest.sha256 SHA-256 manifest over the CSV and overrides). The gap is therefore fixed and verified, so this exception is resolved (closure by remediation and test verification, not by continued risk acceptance).	stated
EX-003	Owner-accepted absence of at-rest protection for override/audit files (interim, expires 2026-12-31)	The product applies no at-rest confidentiality or operating-system file-permission hardening to the override and audit files it writes (the .methodatlas/ overrides and evidence artefacts). They are written with whatever permissions the invoking environment's umask grants and are not encrypted at rest. This is the stated limitation behind BA-008 (protection of trust assets at rest): on a shared or weakly-permissioned host the override/audit files are readable and editable by any local principal, against the at-rest-protection objective (CO-008).	stated
EX-004	Owner-accepted unmeasured in-taxonomy classification accuracy (interim, expires 2026-12-31)	The AI engine constrains classification to a closed, versioned security taxonomy and an explicit method list, so it cannot invent or omit methods; but the accuracy of the classification WITHIN that closed taxonomy — whether a correctly-listed method is assigned the right category — is not measured against a labelled ground-truth set. BA-003 (classification trustworthiness) therefore has no quantified accuracy figure, only the structural guarantees of the closed taxonomy. The gap leaves the correctness objective (CO-003) asserted structurally but unverified empirically. STATUS: the MEANS to measure accuracy now exists (code fix RM-E: the -eval-accuracy command and AccuracyMetrics, component SC-009, scoring AI output against a human-reviewed ground-truth label set). What remains open — and keeps this interim acceptance in force — is an owner-set accuracy target and a maintained labelled set, tracked by roadmap RM-002. So accuracy is now measurable but not yet measured against a target.	stated
EX-005	Owner-accepted untested cross-machine determinism (interim, expires 2026-12-31)	The determinism contract (BA-002) — AST-based discovery is deterministic and reproducible — is exercised by ME-002, but ME-002 runs on a single machine. Cross-machine and cross-platform reproducibility (same inputs producing byte-identical output across different hosts, operating systems and JDK builds) is not tested. The gap leaves the reproducibility objective (CO-002) demonstrated on one environment but unverified as portable, which is precisely the property a regulated consumer needs when reproducing evidence on their own infrastructure. STATUS: the determinism bug this exposed (OS-dependent Java content_hash via platform line endings) is FIXED (code fix RM-D: ContentHasher now normalises line endings, plus PortablePathOrder, LineEnding, and a three-OS determinism.yml matrix), and it passes locally. What keeps this interim acceptance in force is a green run of that matrix on real GitHub runners, tracked by roadmap RM-001.	stated
EX-006	Evidence-retention and release cadence — RESOLVED (D-3)	RESOLVED by owner decision D-3. A retention and cadence policy is now defined: evidence and audit artefacts are retained at least as long as the consuming downstream audit cycle, and hashed releases (no managed-key signing, per D-1) are produced on an event-driven / as-needed basis rather than a fixed calendar. This is recorded as policy PL-002 and operation SO-007, giving CO-013 the temporal governance frame it previously lacked.	stated
EX-007	Per-record taxonomy-version field — RESOLVED in 6.1.0 (verified by JUnit tests)	RESOLVED in 6.1.0. This exception recorded the residual against the per-classification provenance objective (CO-004) that arose from the BA-004 limitation: emitted classification records did not carry a per-record taxonomy-version field — the taxonomy was fingerprinted only once, into the per-run reproducibility receipt — so a consumer reading a single emitted classification in isolation could not tell which taxonomy version produced it without also holding the matching run receipt. Fix RM-C stamps a per-record ai_taxonomy_version into the CSV/JSON/SARIF output and folds the taxonomy version into the AI cache key (components SC-008/SC-015), so each classification carries its own taxonomy version. At the 6.1.0 release gate the owner confirmed closure conditional on passing JUnit tests, and those tests exist and pass (verified green): methodatlas-ai/src/test/java/org/egothor/methodatlas/ai/TaxonomyVersionTest.java and methodatlas-emit/src/test/java/org/egothor/methodatlas/emit/TaxonomyVersionEmissionTest.java. The gap is therefore fixed and verified, so this exception is resolved (closure by remediation and test verification, not by continued risk acceptance).	stated
EX-008	Offline-operation operationalisation — RESOLVED in 6.1.0 (zero-egress test shipped)	RESOLVED in 6.1.0. This exception recorded the residual against the offline-operation objective (CO-012): the per-release zero-outbound-read posture was stated with basis inferred because the only evidence — the HTTP_SUPPORT_CONFINED_TO_AI_PACKAGE ArchUnit rule — confined which package may use HttpSupport but did NOT prove zero non-loopback egress. Roadmap RM-007 is now DONE: the new ZeroEgressTest (realised via SM-006) asserts zero non-loopback connections under a structural scan and the manual Tier-2 path, with a Tier-1 loopback sentinel, verified green on JDK 27. That hard egress evidence closes the gap, so CO-012 moves to stated and this exception is resolved (the fix shipped — closure by remediation, not by continued risk acceptance).	stated
EX-009	AuditWriter coverage bar — RESOLVED in 6.1.0 (class-level gate enforced)	RESOLVED in 6.1.0. This exception recorded the residual against the assurance-coverage objective (CO-009). The BA-009 trust-critical surface list had already been confirmed by the owner under decision D-3, so the only item still accepted on an interim basis was the >=95% AuditWriter coverage bar, which was not an enforced gate (only the per-module floors were). Roadmap RM-004 is now DONE: a class-level JaCoCo violationRule enforces >= 0.95 LINE coverage on org.egothor.methodatlas.gui.service.AuditWriter (measured 97.4%), wired into check, so the bar fails the build if it regresses — verified green on JDK 27. The bar is now an enforced gate, closing the only remaining item, so this exception is resolved (closure by remediation, not by continued risk acceptance).	stated
EX-010	OpenSSF Scorecard / SLSA provenance — implemented, pending first run	Decision D-1 left as a secondary open question whether the project would publish an OpenSSF Scorecard or SLSA provenance — neither of which requires the managed signing keys D-1 declined. Neither is currently published. For an OSS security tool, a published Scorecard and provenance are part of the consumer-facing trust signal that lets downstream users assess the project's own supply-chain posture; their absence leaves the transparency objective (CO-011) and the build-and-distribution-integrity objective (CO-006) short of the fuller external-attestation signal a consumer might expect, over and above the published hashes and reproducibility receipts. STATUS: IMPLEMENTED (pending first run). Code fix RM-F adds the OpenSSF Scorecard workflow and keyless SLSA build provenance (decision D-4, no managed keys; component SC-013). What keeps this interim acceptance in force is a first green Scorecard run and a verified provenance attestation on a real release, tracked by roadmap RM-003. Scorecard's Signed-Releases check stays unmet by design (D-1).	stated
EX-011	Owner-accepted Error-Prone-on-JDK-27 residual (interim, expires 2026-12-31)	Error Prone is disabled on JDK 25 and above via a committed build guard because no Error Prone release supports JDK 27 (it crashes inside the compiler), so Error Prone does NOT run on the JDK-27 development build (AD-011). On that build PMD and SpotBugs are the active static-analysis gates, but the loss of Error Prone narrows static-analysis coverage on the local JDK-27 build against the enforced-test-gate objective (CO-009) and the Verifiably-Tested posture (BA-009). AD-011 records this as a transparent, documented limitation; what this exception adds is the owner's formal acceptance of the residual risk it leaves, which is an owner authority act that AD-011 itself does not perform.	stated

How — Process

How are security services managed and supported?

The services are managed and supported through measurement on the CI cadence rather than a staffed operations desk. Each control objective has a measure (ME-001..ME-014) that defines what is observed and the threshold response: scanner-script hash-check conformance (ME-001), structural-output determinism (ME-002), AI-output bounding conformance (ME-003), taxonomy version-control conformance (ME-004), schema version-control conformance (ME-005), build and distribution integrity (ME-006), outbound data-minimisation conformance (ME-007), override-confidentiality conformance (ME-008), enforced test-quality gates (ME-009), vulnerability-disclosure SLA adherence (ME-010), trust-basis-statement currency (ME-012), audit-trail integrity conformance (ME-013) and AI-result reproducibility conformance (ME-014). Most are evaluated automatically on every build — a failing gate stops the pipeline — while the disclosure and statement-currency measures are evaluated on the disclosure clock. The ongoing operations are now typed as SO-001..SO-007, alongside the measures ME-001..ME-014 and the per-build CI cadence.

Basis: inferred · Source: 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/06-architecture-and-data-governance.md#per-module-quality-floors-enforced-gates

ID	Element	Description	Basis
ME-001	Scanner-script hash-check conformance	Whether the CI abort-on-mismatch test passes (a deliberately mutated scanner script aborts before execution) and whether the MANIFEST.MF script hash is build-generated (not a hand-editable committed value), per build; count of builds that ship with the abort-on-mismatch test failing or absent.	stated
ME-002	Structural-output determinism	Byte-level difference between structural outputs of repeated discovery runs on the same commit; number of structural fields whose value varies across runs on an unchanged revision.	stated
ME-003	AI-output bounding conformance	Whether the CI bounding tests pass — AI responses validated against the versioned taxonomy (out-of-taxonomy labels rejected) and reconciled against the AST method set (invented/omitted methods caught), exercising injected and malformed provider content; count of builds that ship with a bounding test failing.	stated
ME-004	Taxonomy version-control conformance	Number of changes to the taxonomy content shipped without a version increment and same-PR documentation; whether the effective taxonomy/prompt is fingerprinted into the reproducibility receipt for a classification run.	stated
ME-005	Audit and evidence schema version-control conformance	Number of breaking changes to DeltaReport columns or ClassificationOverride fields (rename, reorder, retype, remove) shipped without a schema version bump and the required documentation update.	stated
ME-006	Build and distribution integrity	dependency-check highest CVSS permitted to ship; number of non-allowlisted licences; SBOM produced per build (yes/no); count of prohibited ANTLR grammar-compiler JARs present in lib/; release artefacts covered by GitHub's automatic per-asset SHA-256 digest.	stated
ME-007	Outbound data-minimisation conformance	Whether the CI data-governance payload-builder tests prove the outbound payload carries only the three permitted categories and no never-transmit item (production source, build scripts, config, credentials, DB schemas, infra definitions, other test files, file paths), and whether the ZeroEgressTest records 0 non-loopback outbound connections under Tier 1/2; count of builds where a payload test or the zero-egress test fails.	stated
ME-008	Override-confidentiality control conformance	Whether the CI data-governance test proves override and audit-trail files are excluded from every outbound payload and that credential values are masked by default; count of builds where the exclusion or masking test fails.	stated
ME-009	Enforced test-quality gates	JaCoCo instruction coverage and PIT mutation score at build, project-wide and for the named trust-critical surfaces (AuditWriter / gui-core, methodatlas-ai, methodatlas-emit); build pass/fail against the enforced thresholds; presence and pass/fail of the named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism).	inferred
ME-010	Vulnerability-disclosure SLA adherence	Adherence to the published response SLAs — acknowledge within 2 business days, triage within 5 business days, fix or mitigation plan within 30 days (critical/high) or 90 days (lower) — and availability of the private disclosure channel.	stated
ME-012	Trust-basis-and-limits statement currency	Presence and currency of a documented trust-basis statement that (a) lists the evidence trust rests on and (b) states the limit — GitHub's per-asset SHA-256 digests give integrity, not signature-based non-repudiation; count of public trust claims, across the defined claim universe, not backed by a documented basis.	stated
ME-013	Audit-trail integrity conformance	Whether the CI tests prove the PRESENCE of the cryptographic binding on each artefact that carries one — the attestation manifest binds content hash + commit SHA, the reproducibility receipt binds SHA-256 of every input, the scanner-script MANIFEST.MF hash check is present — and whether the AuditWriter appends to and never rewrites the overrides.yaml / evidence CSV; count of builds where one of these conformance tests fails or is absent. No metric counts "silent modifications detected", which the GUI CSV/YAML cannot support.	inferred
ME-014	AI-result reproducibility conformance	For unchanged classes, number of fields in the AI-influenced classified output that differ between a reviewed record and a re-run on the same commit with the same populated -ai-cache; count of overridden records whose applied label or confidence differs from the deterministic override (confidence not pinned to 1.0/0.0); count of builds where the reproducibility regression test fails.	stated
ME-015	Comment-redaction no-leak conformance	Number of supported languages whose comments are not fully blanked by the redactor in test; count of runs on an unsupported language/file that do NOT abort fail-closed or that make any provider call before aborting; count of apply-tags/write-back runs under -redact-comments where the written-back source is not the original (unredacted) text; count of builds where the comment-redaction conformance tests fail.	stated
SO-001	Weekly dependency-vulnerability scan	Scheduled OWASP dependency-check run completing with zero dependencies at CVSS >= 7.0.	stated
SO-002	Weekly mutation-test run	Scheduled PIT mutation run meeting every module's configured mutation threshold.	stated
SO-003	Per-release gate and publication run	Every release passes the full gate chain (tests, coverage, mutation, PMD, SpotBugs) and publishes the archives, SBOM, PDF, per-asset SHA-256 digests and build-provenance attestation.	stated
SO-004	Automated dependency-update management	Open dependency-update PRs are triaged and merged so no high-severity dependency remains current for longer than the update cycle.	stated
SO-005	Coordinated vulnerability-disclosure triage	Reported vulnerabilities acknowledged within 2 business days, triaged within 5, with a fix/mitigation plan within 30 days (critical/high) or 90 (lower).	stated
SO-006	Per-release schema and taxonomy change review	Every change to a DeltaReport/ClassificationOverride field or to the taxonomy carries a version bump and same-PR documentation; zero unversioned contract changes ship.	stated
SO-007	Evidence retention and release-cadence operation	Audit and evidence artefacts are retained at least as long as the consuming downstream audit cycle; releases are produced on an event-driven basis.	stated

Who — People

Who is managed and supported, and how?

The support model is a published coordinated-disclosure channel operated by a single owner/maintainer. Consumers and researchers reach support through private disclosure — a GitHub private advisory or PGP-encrypted email to security@egothor.org — and receive acknowledge/triage/fix responses against the published SLAs. Internally the same named Architect-and-Programmer owns development, release and disclosure. That single-person concentration is the principal support-model limitation: it creates a bus-factor and separation-of-duties risk (the author also verifies and releases), which the enforced automated gates and the published CVD process partly compensate for but do not remove. This is the "who is supported, and by whom" picture for the product in scope; no distinct administrative identities exist.

Basis: inferred · Source: 00-sources/02-security-policy.md#vulnerability-handling, 00-sources/00-engagement-brief.md#library-parameters

Where — Location

Where: how are sites, networks and platforms kept secure in operation?

The operational locations kept secure are the GitHub repository (source, releases, per-asset digests and SBOM, and the private-advisory disclosure intake), the CI/build environment (where the enforced gates, dependency-check and SBOM run and where release provenance is produced), and the maintainer's own workstation. Operational security of these is sustained by keeping dependencies current (dependency-check fails the build on CVSS≥7.0; the license allowlist is enforced) and by the OSS-governance expectations a security tool is held to — a published security policy, SBOMs and honest vulnerability reporting, with OpenSSF Scorecard as the consumer's yardstick. There is no customer-site infrastructure in this scope.

Basis: stated · Source: 00-sources/00-engagement-brief.md#library-parameters, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/05-research-build-trust-context.md#4-oss-product-governance--consumer-expectations

When — Time

When: what is the security operations schedule?

The security-operations calendar is event-driven, not fixed-date: measurement happens per build (every commit re-runs the gates and regenerates the evidence) and per release (checksums, attestations and receipts are produced), while the disclosure SLAs (2/5/30/90 days) run from each report. The roadmap is typed as RM-001..RM-008. Three items are now DONE in 6.1.0: the class-level AuditWriter coverage gate (RM-004), the schema-compatibility golden test (RM-006) and the real Tier 1/2 zero-egress test (RM-007), each verified green on JDK 27 — closing exceptions EX-009 and EX-008. The forward items that remain are RM-001 (cross-platform determinism on real CI runners), RM-002 (accuracy target + labelled set), RM-003 (first Scorecard/provenance runs), RM-005 (at-rest audit-file protection) and RM-008 (ABAP/COBOL comment-redaction). The GUI .methodatlas/ audit CSV/YAML are hash-bound (a populated content_hash plus a manifest.sha256, per fix RM-B); OpenSSF Scorecard and keyless SLSA provenance are adopted (D-4) with their workflows in place, pending first execution (RM-003). The physical mechanism (SM) and component (ST/SC) layers are now built.

Basis: inferred · Source: 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/06-architecture-and-data-governance.md#audit-trail-artefact-binding-what-is-and-is-not-hash-bound, 00-sources/07-client-decisions.md#d-1--no-automatic-signing-of-release-packages-resolves-bd-011, 00-sources/09-release-6.1.0.md#version-unification-030--610

ID	Element	Description	Basis
RM-001	Prove cross-platform determinism on real CI runners	determinism.yml runs green on ubuntu-latest, windows-latest and macos-latest, with the leg-versus-leg comparison passing, so byte-for-byte cross-platform determinism is demonstrated, not just asserted.	inferred
RM-002	Establish an accuracy target and a maintained labelled set	An owner-set target precision/recall, a representative labelled set that is re-scored when the model, prompts or taxonomy change, and a CI accuracy gate.	inferred
RM-003	Prove Scorecard and provenance on GitHub	A first green Scorecard run publishing a score, and a release whose provenance verifies with gh attestation verify. Signed-Releases remains unmet by design (D-1).	inferred
RM-004	Enforce the AuditWriter coverage bar with a class-level gate	A class-level JaCoCo rule enforcing >= 95% line coverage on AuditWriter, so the bar cannot silently regress — realised in 6.1.0 (measured 97.4%).	stated
RM-005	At-rest protection for the on-host audit artefacts	Owner-only permissions (0600/0700 with a Windows ACL equivalent) on the .methodatlas/ artefacts, or a documented, accepted reliance on host controls.	inferred
RM-006	Schema-compatibility golden test for the audit contracts	A golden-file compatibility test that fails the build if a column/field is renamed, reordered or removed without a version bump (with retype of the consumed DeltaReport CSV columns caught via value round-trip) — realised in 6.1.0 as SchemaCompatibilityGoldenTest.	stated
RM-007	Add a real Tier 1/2 zero-egress test	An automated test asserting no non-loopback connection is opened under Tier 1 and Tier 2 — realised in 6.1.0 as ZeroEgressTest. On that evidence CO-012 moves to stated and EX-008 closes.	stated
RM-008	ABAP/COBOL comment-redaction support	Extend the ABAP and COBOL grammars so their comment forms are fully recognised, then add CommentRedactor implementations for both languages so -redact-comments blanks their comments to spaces instead of aborting. On that evidence the fail-closed abort for ABAP/COBOL is replaced by real redaction.	stated

10. Business attribute profile

ID	Attribute	Definition	Metric	Measurement	Target	Owner	Drivers
BA-001	Authentic	Every discovered test method and emitted record reflects unmodified, peer-reviewed scanner logic — the output is what the published code genuinely produced, not something a tampered helper script fabricated or suppressed.	Whether the design guarantee holds in the code — the scanner-script integrity check runs at startup and hard-aborts discovery on a hash mismatch — proven by a CI/unit test that a deliberately mutated script aborts before any method is produced; and whether the MANIFEST.MF script hash is generated at build time (proven by the build configuration, which shows the hash is produced during the build rather than committed as a hand-edited value).	CI/unit test asserting that a mutated script hard-aborts before execution (the abort-on-mismatch regression test); a build-configuration check that the MANIFEST.MF hash is generated during the build. These are what the project can observe; the per-execution check running on a deployer's machine is a design guarantee, not something the project measures in the field.	The abort-on-mismatch test is present and passes on every build (the check exists and hard-aborts), and the manifest hash is build-generated. No field per-run rate is targeted, because the project cannot observe executions on deployer workstations.	the Architect and Programmer	BD-001
BA-002	Reproducible	The deterministic structural layer (AST-based discovery — FQCN, method, line count, source tags, content hash) produces identical output for the same source revision, independent of provider, model or time, so a result can be regenerated and checked later.	Byte-level difference between structural outputs of repeated discovery runs on the same commit; number of structural fields whose value varies across runs on an unchanged revision.	Re-run discovery on a fixed commit and diff the structural output; a CI determinism test that scans a fixture twice and compares byte-for-byte.	Byte-identical structural output across runs on the same revision (0 differing bytes); 0 structural fields varying for an unchanged class.	the Architect and Programmer	BD-002
BA-003	Bounded	The AI classifier is constrained to a closed, versioned security taxonomy and to the explicit list of method names discovered by the deterministic layer, so it can neither invent nor omit methods nor apply a label outside the taxonomy.	Count of AI-emitted classifications that use a label outside the versioned taxonomy, and count of methods in the AI output that were invented (not in the supplied AST list) or omitted (present in the list, absent from output).	Validation of each AI response against the loaded taxonomy and the supplied method list; CI tests exercising the constraint path; reconciliation of AI output method set against the deterministic discovery set.	0 out-of-taxonomy labels and 0 invented or omitted methods — the AST-derived method set is authoritative and the taxonomy is closed.	the Architect and Programmer	BD-003
BA-004	Taxonomy-Stable	The closed security taxonomy the classifier uses is versioned and changes only through a controlled, version-bumped revision with same-PR documentation, and the effective taxonomy is fingerprinted (via the per-template prompt checksum) into the reproducibility receipt, so a historical classification run can be tied back to the taxonomy that produced it and keeps a stable, re-interpretable meaning.	Number of changes to the taxonomy content shipped without a version increment and same-PR documentation; whether the effective taxonomy (via the fingerprinted prompt) is recorded in the reproducibility receipt for a classification run.	Review of taxonomy changes at PR time for a version bump and documentation update; confirmation that the effective taxonomy/prompt is fingerprinted into the reproducibility receipt (receipt schema v2).	0 unversioned taxonomy changes; every taxonomy change carries a version bump and same-PR documentation; the effective taxonomy/prompt is fingerprinted into each reproducibility receipt.	the Architect and Programmer	BD-004
BA-005	Schema-Stable	The audit and evidence schemas — DeltaReport CSV columns and ClassificationOverride YAML fields consumed by downstream compliance tooling and the GUI audit trail — change only through a versioned, documented revision, never a silent rename, reorder or retype.	Number of breaking changes to DeltaReport columns or ClassificationOverride fields (rename, reorder, retype, remove) shipped without a schema version bump and the required documentation update; pass/fail of the schema-compatibility golden test that pins the exact ordered columns/fields.	As of 6.1.0, a schema-compatibility golden test (SchemaCompatibilityGoldenTest, methodatlas-emit) pins the exact ordered DeltaReport CSV columns and ClassificationOverride YAML fields and FAILS THE BUILD on any silent rename, reorder, retype or removal — an automated regression guard (RM-006); backed by PR review against the audit/schema-stability rule, diff of schema types between releases, and confirmation that README.md, docs/cli-reference.md and audit-format docs were updated in the same change.	0 unversioned breaking schema changes; every breaking change carries a schema version bump and same-PR documentation update; the schema-compatibility golden test passes on every build.	the Architect and Programmer	BD-005
BA-006	Supply-Chain-Intact	The build and the shipped distribution are integrity-assured end to end — dependencies are gated on known vulnerabilities and licences, an SBOM is produced, the distribution invariant holds, and GitHub provides a verifiable per-asset SHA-256 digest for every release artefact that consumers can verify against (the project does not ship a separate SHA256SUMS; per D-3).	dependency-check highest CVSS permitted to ship; number of non-allowlisted licences; SBOM produced per build (yes/no); count of prohibited ANTLR grammar-compiler JARs present in lib/; release artefacts covered by GitHub's automatic per-asset SHA-256 digest.	dependencyCheckAnalyze, checkLicense, cyclonedxBom (aliased :cyclonedxDirectBom) and lib/ content inspection run in CI; GitHub exposes each release asset's SHA-256 digest automatically.	Build fails on any dependency CVSS >= 7.0; 0 non-allowlisted licences; SBOM generated every build; 0 prohibited grammar-compiler JARs in lib/; every release artefact is covered by GitHub's per-asset SHA-256 digest. Managed-key signatures are deliberately out of scope (per D-1).	the Architect and Programmer	BD-006
BA-007	Data-Minimising	When an external AI provider is used, only the minimum necessary leaves the host — the taxonomy text, the discovered method names and line numbers, and the one truncated test-class source file — and never production source, config, credentials, directory structure or other test files; local and manual tiers allow zero outbound data. With the opt-in -redact-comments control, comments are additionally redacted (blanked to spaces) from that one test-class source file before it is sent, so comment-borne personal data does not leave the host even within the permitted category — a further minimisation beyond the "only one class + method list + taxonomy" boundary.	Categories of data transmitted to an external provider versus the permitted set; count of transmissions carrying any prohibited category (production source, build scripts, config, credentials, DB schemas, infra definitions, other test files, file paths); non-loopback outbound connections made under Tier 1 (Ollama local), where a loopback connection to a local Ollama is not egress; under -redact-comments, count of transmitted class sources whose comments were not fully blanked (target 0, fail-closed on any language that cannot be fully redacted).	Inspection/tests of the outbound request payload builder; data-governance tests asserting the payload contains only the three permitted categories; network check that Tier 1/manual make no non-loopback outbound AI calls.	Only the three permitted categories are transmitted; 0 transmissions carry any prohibited category; Tier 1 (local) and Tier 2 (manual) make 0 non-loopback outbound AI connections.	the Architect and Programmer	BD-007
BA-008	Confidential	The override files and audit-trail artefacts that record human-review decisions are protected against unauthorised disclosure — they are never included in any outbound AI payload, and the credential values the product surfaces are masked by default — because these records reveal reviewer judgement about security-relevant tests.	Count of transmissions in which an override file or audit-trail artefact appears in an outbound AI payload (must be zero); whether credential values are masked by default in emitted output; whether every report touching override-file confidentiality is routed to critical triage.	Data-governance test asserting override and audit-trail files are excluded from every outbound payload; test/inspection that credential values are masked by default; a routing check that any override-confidentiality report is handled as critical via the CVD process (SLA tracking itself lives in ME-010, not here).	0 transmissions carry an override/audit artefact; credential values masked by default in 100% of output; every override-confidentiality report routed to critical triage.	the Architect and Programmer	BD-008
BA-009	Verifiably-Tested	A change that would break a trust property is caught before release, because the enforced per-module coverage and mutation gates hold the trust-critical surfaces — the audit-trail writer (AuditWriter / methodatlas-gui-core), the AI engine (methodatlas-ai) and the output emitters (methodatlas-emit) — to their module floors, the AuditWriter is additionally held to an enforced class-level >= 95% line-coverage gate, and named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism) guard the specific behaviours the product's trust claims rest on.	JaCoCo instruction coverage and PIT mutation score at build, project-wide and per trust-critical module; the class-level JaCoCo line-coverage rule on AuditWriter; build pass/fail against the enforced per-module and class-level thresholds; presence and pass/fail of the named trust-property tests.	jacocoTestCoverageVerification (including the class-level AuditWriter rule) and pitest run as failing gates in ./gradlew check / build; per-release review of coverage for the named trust surfaces against their enforced floor and the enforced AuditWriter bar; confirmation the named trust-property tests exist and pass.	The enforced per-module floors (as set in build.gradle): root 70%/55%, methodatlas-ai 80%/70%, methodatlas-emit 65%/45%, methodatlas-gui-core 75%/50%, methodatlas-discovery-jvm 85%/60% (JaCoCo instruction / PIT mutation), build failing below any. The root mutation standard is 55% (owner decision 2026-10-15), deliberately reduced from the earlier 60% because the new compliance/evidence feature code brought the measured root mutation score below 60%; the floors are risk-proportionate, not strictly one-way (the earlier "floors only go up" claim is withdrawn). As of 6.1.0 the AuditWriter audit-trail integrity surface is additionally held to an ENFORCED class-level JaCoCo >= 0.95 LINE-coverage gate (measured 97.4%), wired into check (stated — RM-004). Beyond those gates, this attribute keeps the named trust-property tests present and passing, which remains a chosen (inferred) operationalisation, not an enforced threshold in the source. Static-analysis caveat (6.1.0, stated): on the JDK-27 build Error Prone is disabled (no release supports JDK 27) so PMD and SpotBugs are the enforced static-analysis gates there, while Error Prone still runs on a supported JDK (<= 24) — see AD-011.	the Architect and Programmer	BD-009, BD-001, BD-002
BA-010	Supportable	The project operates a published, coordinated vulnerability-disclosure process and responds to reports within stated service levels, so that security issues in the product are received, triaged and remediated predictably.	Adherence to the published response SLAs — acknowledge within 2 business days, triage within 5 business days, fix or mitigation plan within 30 days (critical/high) or 90 days (lower) — and availability of the private disclosure channel.	Tracking of each received report against the SLA clock (acknowledge / triage / plan); confirmation that the private advisory channel and published PGP contact remain available.	100% of received reports acknowledged <= 2 business days and triaged <= 5 business days; fix/mitigation plan within 30 days (critical/high) or 90 days (lower); disclosure channel published and operational.	the Architect and Programmer	BD-009
BA-011	Credible	The product is credibly adoptable in regulated and air-gapped environments — it can run with full structural function and a usable classification path (Tier 1 Ollama local or Tier 2 manual) that makes no outbound connection, so a strict-DLP or air-gapped buyer can use it at all.	Whether full discovery plus a usable classification path (Tier 1 local or Tier 2 manual) operates with zero non-loopback outbound connections, verified each release.	The data-governance payload tests assert only permitted categories leave the host; and, as of 6.1.0, the ZeroEgressTest (RM-007, DONE) confirms 0 non-loopback outbound connections under a structural scan and the manual Tier-2 path with a Tier-1 loopback sentinel, tracked via ME-007 / EV-006.	Air-gapped operation (Tier 1/2, 0 non-loopback outbound connections) verified for each release.	the Architect and Programmer	BD-010
BA-012	Transparent	What the product's trustworthiness rests on, and the limits of that trust, are stated explicitly and kept current — specifically that trust rests on published artefact hashes, deterministic reproducible evidence and enforced gates, and that managed-key signing (non-repudiable proof of origin) is deliberately out of scope.	Presence and currency of a documented trust-basis statement that (a) lists the evidence trust rests on and (b) states the limit — GitHub's per-asset SHA-256 digests give integrity, not signature-based non-repudiation; count of published trust claims not backed by a documented basis.	Per-release review that the trust-basis-and-limits statement exists, matches the shipped controls, and is updated when they change; cross-check of public trust claims against that statement.	Trust-basis-and-limits statement published and current for each release; 0 undocumented or unqualified trust claims (every claim names its evidence and its limit).	the Architect and Programmer	BD-011, BD-010
BA-013	Audit-Trail-Intact	The audit-trail artefacts the product emits fall in two groups. The artefacts that carry a cryptographic binding — the attestation manifest (each security test bound by content hash + commit SHA), the reproducibility receipts (SHA-256 of every input, incl. per-template prompt checksums) and the scanner-script MANIFEST.MF hash check — are cryptographically tamper-evident. The GUI .methodatlas/ artefacts — the timestamped evidence CSV (DeltaReport, never overwritten, accumulates per save operation) and the cumulative overrides.yaml (ClassificationOverride) — are append/accumulate and timestamped but are not themselves hash-bound or signed (a known limitation, recorded below).	Presence of the cryptographic binding on the artefacts that carry one — content-hash + commit-SHA on the attestation manifest, SHA-256-of-every-input on the reproducibility receipts, the MANIFEST.MF hash check on the scanner scripts — each verifiable in CI; and the append-not-overwrite (accumulate) property of the GUI evidence CSV and overrides.yaml (the AuditWriter appends rather than rewrites). No metric claims post-emission tamper-detection of the unbound GUI CSV/YAML, which have no such property.	CI tests asserting the attestation manifest binds content hash + commit SHA, the reproducibility receipt binds SHA-256 of every input, and the scanner-script MANIFEST.MF hash check is present; a CI test asserting the AuditWriter appends to and never rewrites the overrides.yaml / evidence CSV.	The attestation manifest, reproducibility receipts and scanner-script check each carry their cryptographic binding, verifiable in CI; the GUI evidence CSV and overrides.yaml are written append-only (accumulate, never overwrite). Known limitation: the GUI CSV/YAML carry no hash binding or signature (see notes); the target does not assert tamper-evidence for them.	the Architect and Programmer	BD-001, BD-008
BA-014	AI-Result-Reproducible	The AI-influenced classification record can be regenerated despite the AI layer being non-deterministic by nature — re-running on the same commit with the same -ai-cache reproduces the reviewed classified output for unchanged classes, human overrides are applied deterministically, and overridden confidence is pinned to 1.0/0.0 — so the reviewed classified record is a stable authoritative record, not a one-off sample.	For unchanged classes, number of fields in the AI-influenced classified output that differ between a reviewed record and a re-run on the same commit with the same populated -ai-cache; count of overridden records whose applied label or confidence differs from the deterministic override (confidence not pinned to 1.0/0.0).	A CI/regression test that classifies a fixture with a populated -ai-cache, re-runs on the same commit and diffs the classified output for unchanged classes; a test that an override is applied deterministically with confidence pinned to 1.0/0.0.	0 differing fields in the AI-influenced classified output across re-runs on the same commit with the same cache for unchanged classes; 100% of overrides applied deterministically with confidence pinned to 1.0/0.0.	the Architect and Programmer	BD-003

11. Traceability — from component to business driver

Component	Mechanism	Service	Control objective	Attribute	Driver
SC-001	SM-002	SS-002	CO-002	BA-002	BD-002
SC-002	SM-002	SS-002	CO-002	BA-002	BD-002
SC-003	SM-002	SS-002	CO-002	BA-002	BD-002
SC-003	SM-006	SS-006	CO-007	BA-007	BD-007
SC-003	SM-006	SS-006	CO-012	BA-011	BD-010
SC-003	SM-008	SS-008	CO-009	BA-009	BD-009
SC-003	SM-008	SS-008	CO-009	BA-009	BD-001
SC-003	SM-008	SS-008	CO-009	BA-009	BD-002
SC-004	SM-002	SS-002	CO-002	BA-002	BD-002
SC-005	SM-002	SS-002	CO-002	BA-002	BD-002
SC-005	SM-015	SS-002	CO-002	BA-002	BD-002
SC-006	SM-015	SS-002	CO-002	BA-002	BD-002
SC-007	SM-003	SS-003	CO-003	BA-003	BD-003
SC-007	SM-006	SS-006	CO-007	BA-007	BD-007
SC-007	SM-006	SS-006	CO-012	BA-011	BD-010
SC-008	SM-003	SS-003	CO-003	BA-003	BD-003
SC-008	SM-004	SS-004	CO-004	BA-004	BD-004
SC-009	SM-016	SS-003	CO-003	BA-003	BD-003
SC-010	SM-005	SS-005	CO-006	BA-006	BD-006
SC-010	SM-008	SS-008	CO-009	BA-009	BD-009
SC-010	SM-008	SS-008	CO-009	BA-009	BD-001
SC-010	SM-008	SS-008	CO-009	BA-009	BD-002
SC-011	SM-005	SS-005	CO-006	BA-006	BD-006
SC-012	SM-008	SS-008	CO-009	BA-009	BD-009
SC-012	SM-008	SS-008	CO-009	BA-009	BD-001
SC-012	SM-008	SS-008	CO-009	BA-009	BD-002
SC-013	SM-017	SS-005	CO-006	BA-006	BD-006
SC-014	SM-012	SS-012	CO-005	BA-005	BD-005
SC-014	SM-013	SS-013	CO-013	BA-013	BD-001
SC-014	SM-013	SS-013	CO-013	BA-013	BD-008
SC-015	SM-014	SS-014	CO-014	BA-014	BD-003
SC-016	SM-007	SS-007	CO-008	BA-008	BD-008
SC-017	SM-001	SS-001	CO-001	BA-001	BD-001
SC-018	SM-009	SS-009	CO-010	BA-010	BD-009
SC-019	SM-010	SS-010	CO-011	BA-012	BD-011
SC-019	SM-010	SS-010	CO-011	BA-012	BD-010
SC-020	SM-018	SS-006	CO-007	BA-007	BD-007
SC-020	SM-018	SS-006	CO-012	BA-011	BD-010

12. The SABSA matrix at a glance

✓ answered · n/a not applicable · · open — the number is how many elements sit in the cell.

Layer	What	Why	How	Who	Where	When
Contextual	✓ 11	✓ 15	✓	✓	✓	✓
Conceptual	✓ 14	✓ 25	✓	✓ 8	✓ 8	✓
Logical	✓	✓ 2	✓ 13	✓	✓	✓
Physical	✓	✓	✓ 17	✓	✓	✓
Component	✓	✓ 12	✓ 20	✓	n/a	n/a
Service Management	✓ 14	✓ 11	✓ 21	✓	✓	✓ 8

13. Open assumptions — questions for MethodAtlas project

None: every element is stated by MethodAtlas project or inferred from cited material.

Annex A. Element register

• BD-001 Output trustworthy enough to serve as audit evidence (driver) — MethodAtlas output must be trustworthy enough to stand as audit evidence before auditors, regulators and security review boards. [stated; 00-sources/01-product-overview.md#purpose, 00-sources/02-security-policy.md#key-trust-assets-implied, 00-sources/02-security-policy.md#regulatory-context-and-critical-categories]
• BD-002 Deterministic, reproducible structural results (driver) — The same source revision must always produce the same deterministic structural record, independent of AI provider, model or wall-clock time. [stated; 00-sources/03-compliance-context.md#reproducibility-contract-core-promise, 00-sources/04-development-invariants.md#determinism-contract, 00-sources/04-development-invariants.md#overall-posture]
• BD-003 AI-assisted classification kept bounded and auditable (driver) — AI-assisted classification must stay bounded to a closed, versioned taxonomy and an explicit method list so it can neither invent nor omit findings and its influence on the evidence remains auditable and reproducible. [stated; 00-sources/04-development-invariants.md#determinism-contract, 00-sources/03-compliance-context.md#reproducibility-contract-core-promise, 00-sources/05-research-build-trust-context.md#3-ai-assisted-code-analysis-threats]
• BD-004 Stability of the closed security taxonomy (driver) — The closed, versioned security taxonomy must remain stable and explicitly versioned so classifications stay comparable over time and coverage is not silently regressed between assessment periods. [stated; 00-sources/04-development-invariants.md#overall-posture, 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected]
• BD-005 Stability of the audit and evidence schemas (driver) — The audit and evidence schemas must remain stable, with any breaking change governed by an explicit version bump, so downstream compliance tooling and audit trails do not break. [stated; 00-sources/04-development-invariants.md#audit-schema-stability, 00-sources/06-architecture-and-data-governance.md#module-topology-trust-relevant-structure]
• BD-006 Integrity and provenance of the build and shipped distribution (driver) — The integrity and provenance of the shipped distribution and the build that produces it must be assured, so that a tampered build or poisoned dependency cannot silently corrupt the evidence the tool emits. [stated; 00-sources/04-development-invariants.md#distribution-invariant-supply-chain, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/05-research-build-trust-context.md#1-supply-chain-build-integrity-for-a-security-tool-itself]
• BD-007 Data minimisation when using external AI providers (driver) — When external AI providers are used, MethodAtlas must transmit only the minimum necessary and never production source, configuration, credentials or directory structure, preserving its data-governance boundary and its air-gapped operating mode. [stated; 00-sources/06-architecture-and-data-governance.md#data-governance-what-is-and-is-not-transmitted, 00-sources/06-architecture-and-data-governance.md#data-residency-tiers, 00-sources/01-product-overview.md#capabilities-relevant-to-trustassurance-selected, 00-sources/05-research-build-trust-context.md#3-ai-assisted-code-analysis-threats]
• BD-008 Confidentiality and integrity of human-review and override decisions (driver) — The confidentiality and integrity of human-review and override decisions must be protected, because these records carry reviewer judgement and are treated as critical regardless of CVSS. [stated; 00-sources/02-security-policy.md#regulatory-context-and-critical-categories, 00-sources/02-security-policy.md#key-trust-assets-implied, 00-sources/01-product-overview.md#audit-trail-artefacts-gui]
• BD-009 Secure-development discipline and coordinated vulnerability disclosure (driver) — As a security tool, MethodAtlas must hold its own development to the secure-development discipline it expects of others, backed by enforced quality gates and a published coordinated vulnerability-disclosure process. [stated; 00-sources/02-security-policy.md#vulnerability-handling, 00-sources/04-development-invariants.md#quality-gates-each-must-pass-thresholds-enforced, 00-sources/05-research-build-trust-context.md#4-oss-product-governance-consumer-expectations]
• BD-010 Credibility for adoption in regulated and air-gapped environments (driver) — MethodAtlas must earn and sustain the credibility required for adoption by security teams in regulated and air-gapped environments, because that credibility is the precondition for the product to be used at all. [inferred; 00-sources/00-engagement-brief.md#what-this-library-is-for, 00-sources/03-compliance-context.md#frameworks-methodatlas-is-designed-to-support-customer-facing, 00-sources/01-product-overview.md#audience-market, 00-sources/06-architecture-and-data-governance.md#data-residency-tiers]
• BD-011 Proportionate, self-asserted trust without managed-key release signing (driver) — MethodAtlas's own trustworthiness rests on GitHub's verifiable per-asset SHA-256 digests of its release artefacts plus deterministic, reproducible, hash-based evidence and enforced quality/supply-chain gates, rather than on managed-key cryptographic signatures of the release package, and the boundary of this self-asserted trust is to be stated explicitly. [stated; 00-sources/07-client-decisions.md#d-1-no-automatic-signing-of-release-packages-resolves-bd-011, 00-sources/05-research-build-trust-context.md#1-supply-chain-build-integrity-for-a-security-tool-itself]
• RO-001 Tampered scanner script fabricates or suppresses findings (threat) — A helper scanner script (ts-scanner.bundle.js or py-scanner.py) is substituted or modified so it selectively fabricates or suppresses discovered test methods, producing a falsified audit report that still looks valid — including the case where the whole JAR is repackaged so the script and its MANIFEST.MF hash are rewritten together, defeating the hash-match check. [stated]
• RO-002 Non-deterministic output breaks the audit trail (threat) — Structural discovery output varies between runs on the same source revision, so a result cannot be regenerated and matched later, destroying its value as an auditable record. [stated]
• RO-003 Prompt injection via scanned source skews classification (threat) — Untrusted test source fed to the AI classifier carries an indirect prompt-injection payload that manipulates the model into mis-classifying, inventing or omitting results. [stated]
• RO-004 Source exfiltration to a hosted AI provider (threat) — Code under analysis, or data beyond the permitted minimum, is transmitted to a hosted AI provider and disclosed or retained outside the organisation's control. [stated]
• RO-005 Poisoned dependency or compromised build propagates into customers' evidence (threat) — A poisoned third-party dependency or a compromised build silently alters scanner logic so emitted attestations look valid while findings are wrong, and because the output is trusted downstream the compromise propagates into many customers' compliance packages. [stated]
• RO-006 Unversioned schema break desynchronises downstream tooling (threat) — A DeltaReport column or ClassificationOverride field is renamed, reordered or retyped without a schema version bump, silently breaking downstream compliance tooling and the GUI audit trail that consume it. [stated]
• RO-007 Override-file disclosure exposes reviewer decisions (threat) — The override files and audit-trail artefacts that record human-review decisions are disclosed to an unauthorised party, exposing reviewer judgement about security-relevant tests and the organisation's security posture. [stated]
• RO-008 Weak OSS security posture undermines credibility (threat) — A weak or opaque open-source security posture — low automated supply-chain score, unclear vulnerability-handling, undocumented trust claims — leads regulated buyers to reject the tool as not credible for their environment. [stated]
• RO-009 Unversioned taxonomy change invalidates historical classifications (threat) — The closed security taxonomy is changed without a version increment, so a label emitted by an earlier release can no longer be interpreted reliably and historical evidence loses its stable meaning. [inferred]
• RO-010 Air-gapped and local-only operation opens strict-DLP adoption (opportunity) — The fully local and manual operating tiers let MethodAtlas run with zero outbound data, opening adoption in air-gapped and strict-DLP environments that cannot use cloud-only tools. [inferred]
• RO-011 Published hash-based trust evidence differentiates without managed keys (opportunity) — Publishing deterministic, hash-based trust evidence — GitHub's per-asset SHA-256 digests, reproducibility receipts, enforced-gate reports and an explicit trust-basis statement — lets the product earn buyer confidence proportionately, without taking on the burden of managed signing keys. [inferred]
• RO-012 Audit-trail artefact tampered with or silently rewritten after emission (threat) — An emitted audit-trail artefact — the evidence CSV, the cumulative overrides.yaml, the attestation manifest or a reproducibility receipt — is modified or selectively rewritten after emission, so the recorded history no longer reflects what actually happened and the audit trail can no longer be relied upon. [stated]
• RO-013 Release artefact and its digest substituted together at the distribution channel (threat) — A release artefact and its per-asset SHA-256 digest are replaced together at the distribution channel — or the whole JAR is repackaged so a scanner script and its MANIFEST.MF hash are rewritten together — so every integrity check passes against a falsified artefact that the project does not cryptographically sign, and a buyer applying OpenSSF Signed-Releases rejects the unsigned release. [stated]
• RO-014 Reported product vulnerability not triaged or fixed within SLA (threat) — A vulnerability reported against MethodAtlas is not acknowledged, triaged or remediated within the published service levels, so a known weakness in a security-evidence tool stays exploitable and the project's credibility as a secure-development exemplar erodes. [inferred]
• RO-015 PII in source comments exfiltrated to an external AI provider (threat) — Personal data carried in source-code comments (for example Java Javadoc) is transmitted to a hosted AI provider inside the test-class source file and disclosed or retained outside the organisation's control. [stated]
• CO-001 Scanner-script integrity verified before execution (control objective) — Every helper scanner script must be integrity-verified against its build-time reference before it is allowed to run, the reference hash must be build-generated and not hand-editable, and a mismatch must stop discovery before any method is produced, so that output always reflects the peer-reviewed scanner logic.
• CO-002 Structural results are deterministic and reproducible (control objective) — The structural discovery layer must produce identical output for the same source revision regardless of provider, model or time, and the non-deterministic AI layer must be prevented from influencing structural fields.
• CO-003 AI classification is confined to a closed taxonomy and the discovered method set (control objective) — The AI classifier must only apply labels from the loaded, versioned taxonomy and must operate against the explicit list of methods discovered by the deterministic layer, so it cannot invent, omit or re-scope results even under a prompt-injection attempt.
• CO-004 Taxonomy changes are versioned and traceable (control objective) — Any change to the closed security taxonomy must carry a version increment and the required same-PR documentation, and the effective taxonomy must be fingerprinted (via the per-template prompt checksum) into the reproducibility receipt, so a classification run can be tied back to the taxonomy that produced it and historical evidence keeps a stable, re-interpretable meaning.
• CO-005 Audit and evidence schema changes are versioned and documented (control objective) — Any breaking change to the DeltaReport or ClassificationOverride schemas must carry a schema version bump and the corresponding documentation update in the same change, so downstream compliance tooling and the GUI audit trail are never silently desynchronised.
• CO-006 Build and distribution integrity are assured and verifiable (control objective) — The build must enforce dependency-vulnerability, licence and SBOM gates and the distribution invariant, and every release artefact must be covered by GitHub's verifiable per-asset SHA-256 digest (plus keyless build provenance, D-4), so a poisoned dependency or tampered build cannot silently reach customers' evidence.
• CO-007 Data minimisation enforced for external AI providers (control objective) — When a non-local AI provider is used, only the permitted minimum may leave the host and the enumerated never-transmit categories must never be sent, and local and manual tiers must be available so an operator can keep all data on the host.
• CO-008 Override and review-decision confidentiality protected (control objective) — The override files and audit-trail artefacts that record human-review decisions must never be included in any outbound AI payload, credential values must be masked by default, and any report touching their confidentiality must be handled as critical regardless of CVSS.
• CO-009 Product quality proven by enforced test gates (control objective) — The build must enforce the per-module coverage and mutation floors and fail below any of them — root 70%/55%, methodatlas-ai 80%/70%, methodatlas-emit 65%/45%, methodatlas-gui-core 75%/50%, methodatlas-discovery-jvm 85%/60% (JaCoCo instruction / PIT mutation) as enforced in build.gradle; the root mutation standard is 55% (owner decision 2026-10-15), deliberately reduced from the earlier 60% — the floors are risk-proportionate, not strictly one-way — and (6.1.0) enforce a class-level JaCoCo >= 0.95 LINE gate on AuditWriter (measured 97.4%, RM-004), and keep named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism) passing as a chosen (inferred) addition, so a regression that would break authenticity or determinism is caught before release.
• CO-010 Coordinated vulnerability disclosure operated to published SLAs (control objective) — The project must operate a published, private coordinated-disclosure channel and meet its stated acknowledge, triage and remediation service levels, so that vulnerabilities in the product are handled predictably and visibly.
• CO-011 Trust basis and its limits stated transparently (control objective) — The product must publish and keep current a statement of what its trustworthiness rests on — GitHub's per-asset SHA-256 digests, deterministic reproducible evidence and enforced gates — and of its deliberate limit, that managed-key signing (non-repudiable proof of origin) is out of scope, so no trust claim is left unqualified.
• CO-012 Credible offline and air-gapped operation maintained (control objective) — The product must preserve full structural discovery plus a usable classification path that makes zero outbound connections, verified each release, so it remains adoptable in regulated and air-gapped environments.
• CO-013 Audit-trail artefacts carry their cryptographic binding; GUI audit files are append-only (control objective) — The audit-trail artefacts that can carry a cryptographic binding must do so — the attestation manifest bound to content hash and commit SHA, reproducibility receipts bound to SHA-256 of every input, and the scanner scripts bound to the build-time MANIFEST.MF hash — each verifiable in CI; and the GUI overrides.yaml / evidence CSV must be written append-only (accumulate, never rewrite). The objective does not assert cryptographic tamper-evidence for the GUI CSV/YAML, which carry no hash binding (a recorded limitation and open owner question).
• CO-014 Reproducibility of AI-influenced output is preserved (control objective) — The product must preserve reproducibility of AI-influenced output — a re-run on the same commit with the same -ai-cache must reproduce the reviewed classified record for unchanged classes, and human overrides must be applied deterministically with confidence pinned to 1.0/0.0 — so the reviewed classified record is a stable authoritative record despite the AI layer being non-deterministic by nature.
• DM-001 Scan-host domain (domain) — The operator workstation or CI runner where MethodAtlas executes — the CLI, the Swing GUI, the discovery plugins, the local caches and the .methodatlas/ audit artefacts. All structural discovery and all local-only operations happen here.; authority: The adopting team / CI owner; for this project, the maintainer running the tool.
• DM-002 Build and CI domain (domain) — The Gradle build and the GitHub Actions workflows that compile, test, gate, scan and release MethodAtlas — the enforced quality gates, the dependency and licence checks, the SBOM, and the determinism/scorecard/provenance workflows.; authority: The project maintainer and the GitHub Actions configuration under version control.
• DM-003 Distribution-channel domain (domain) — GitHub Releases (the published archives, SBOM, PDF and their per-asset SHA-256 digests and provenance attestation) and the documentation site published via GitHub Pages.; authority: GitHub as the hosting platform; the maintainer as release author.
• DM-004 Hosted AI-provider domain (Tier 3) (domain) — A third-party hosted inference API (OpenAI-compatible, Anthropic, Azure OpenAI and the other OpenAI-compatible vendors) reached over HTTPS when Tier-3 AI enrichment is configured. Outside the product's control; governed by the provider's own data policy.; authority: The third-party provider; the adopting organisation's approval of that provider.
• DM-005 Local and air-gapped AI domain (Tier 1/2) (domain) — Local inference via Ollama (Tier 1) on the host or internal network, and the manual prepare/consume exchange (Tier 2) where an operator carries prompt files to an authorised workstation. Neither makes an outbound call from the scan host.; authority: The adopting organisation; fully within its own boundary.
• DM-006 Dependency-supply domain (domain) — The upstream supply of third-party components — Maven Central and npm for libraries, the NVD for vulnerability data — consumed by the build and gated before anything ships.; authority: External package registries and the NVD; the project's gate configuration decides what is accepted.
• DM-007 Consumer and auditor verification domain (domain) — The downstream party — a regulated adopter, an auditor or a security review board — that consumes MethodAtlas output and verifies the product's own integrity (checksums, provenance, receipts, evidence packs) before relying on it.; authority: The consuming organisation and its auditors.
• DM-008 Vulnerability-disclosure domain (domain) — Security researchers and the coordinated channel through which they report vulnerabilities — GitHub private advisories and the PGP-encrypted security mailbox — plus the maintainer's triage and remediation under the published SLAs.; authority: The maintainer (as responder) and the reporting researcher, under coordinated-disclosure norms.
• SS-001 Scanner-script integrity verification service (service) — Provides assurance that every helper scanner script is integrity-verified against its build-time reference before it is allowed to run, and that discovery is aborted before any method is produced when the check fails, so output always reflects the peer-reviewed scanner logic.
• SS-002 Structural-determinism guard service (service) — Keeps the structural discovery layer fully deterministic and strictly isolated from the probabilistic AI layer, so the same source revision always yields identical structural output that can be regenerated and compared, and the AI layer can never influence a structural field.
• SS-003 AI output-bounding service (service) — Confines the AI classifier to the loaded, versioned taxonomy and to the explicit method set produced by the deterministic layer, validating every response so the model may change a label but can never invent, omit or re-scope methods or apply a label outside the taxonomy, even under prompt injection.
• SS-004 Taxonomy version-control service (service) — Governs controlled, version-bumped evolution of the closed security taxonomy the classifier binds to, so every taxonomy change carries a version increment and the required same-PR documentation, and the effective taxonomy is fingerprinted (via the per-template prompt checksum) into the reproducibility receipt.
• SS-005 Build and distribution integrity assurance service (service) — Enforces the supply-chain gates (dependency-vulnerability, licence allowlist, SBOM) and the distribution invariant on every build; consumers verify each release artefact against GitHub's automatic per-asset SHA-256 digest and the keyless build-provenance attestation (D-4). Managed-key signing is deliberately out of scope per decision D-1.
• SS-006 Data-minimisation enforcement service (service) — Ensures that when a non-local AI provider is used only the permitted minimum leaves the host and the enumerated never-transmit categories never do, and that fully local and manual tiers remain available so an operator can keep all data on the host.
• SS-007 Override and review-decision confidentiality service (service) — Keeps the override files and audit-trail artefacts that record human-review decisions out of every outbound AI payload, masks credential values by default, and ensures any confidentiality report against them is routed to critical triage.
• SS-008 Enforced test-quality gate service (service) — Enforces the per-module coverage and mutation floors as failing build gates (root 70%/55%, methodatlas-ai 80%/70%, methodatlas-emit 65%/45%, methodatlas-gui-core 75%/50%, methodatlas-discovery-jvm 85%/60% — JaCoCo instruction / PIT mutation, as enforced in build.gradle; the root mutation standard is 55% per owner decision 2026-10-15, deliberately reduced from the earlier 60%, so the floors are risk-proportionate not strictly one-way), and (6.1.0) an enforced class-level JaCoCo >= 0.95 LINE gate on AuditWriter (measured 97.4%, RM-004), and keeps named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism) passing as a chosen (inferred) addition, so a regression in the authenticity, determinism or schema-stability controls is caught before release.
• SS-009 Coordinated vulnerability disclosure operation (service) — Operates a published, private coordinated-disclosure channel and tracks every received report against the stated acknowledge, triage and remediation service levels, so vulnerabilities in the product are handled predictably and visibly.
• SS-010 Trust-basis-and-limits transparency service (service) — Publishes and keeps current a statement of what the product's trustworthiness rests on — GitHub's per-asset SHA-256 digests, deterministic reproducible evidence and enforced gates — and of its deliberate limit, that managed-key signing (non-repudiable proof of origin) is out of scope, so no trust claim is left unqualified.
• SS-012 Audit and evidence-schema version-control service (service) — Governs controlled, version-bumped evolution of the DeltaReport and ClassificationOverride audit-and-evidence schemas consumed by downstream compliance tooling and the GUI audit trail, so every breaking change carries a schema version increment and the required same-PR documentation update and no consumer is ever silently desynchronised.
• SS-013 Audit-trail integrity service (service) — Provides the audit-trail integrity bindings that the product can carry — the attestation manifest bound to content hash + commit SHA, reproducibility receipts bound to SHA-256 of every input, and the scanner-script MANIFEST.MF hash check — and keeps the GUI AuditWriter appending to the cumulative overrides.yaml and timestamped evidence CSVs rather than rewriting them. The GUI CSV/YAML carry no cryptographic binding (a recorded limitation); this service does not claim to make them tamper-evident.
• SS-014 AI-result reproducibility service (service) — Preserves reproducibility of AI-influenced output by reusing cached classifications keyed by content hash, applying human overrides deterministically with overridden confidence pinned to 1.0/0.0, and treating the reviewed classified record as the authoritative output that a same-commit, same-cache re-run reproduces for unchanged classes.
• SM-001 Scanner-script integrity verification mechanism (mechanism) — Realises SS-001 by comparing every bundled helper scanner script against a SHA-256 reference recorded as a JAR MANIFEST.MF attribute at build time, and hard-aborting discovery before any method is produced when the computed digest does not match, so no output can originate from tampered script bytes.
• SM-002 Deterministic AST-discovery boundary mechanism (mechanism) — Realises part of SS-002 by performing all structural discovery through the deterministic TestDiscovery SPI (AST parsing only, no AI call) and enforcing, with an ArchUnit architecture test, that no discovery or API module may reference the AI engine — so the structural layer is both deterministic and physically unable to be influenced by the probabilistic layer.
• SM-003 AI classifier output-bounding mechanism (mechanism) — Realises SS-003 by driving the classifier with an explicit, AST-derived method list and a loaded closed taxonomy, capping per-class source at maxClassChars, and reconciling every model response against that authoritative method set and label vocabulary so the model may change a label but can never invent, omit or re-scope a method or apply a label outside the taxonomy.
• SM-004 Taxonomy version-control mechanism (mechanism) — Realises SS-004 by resolving a single version identifier for the closed taxonomy the classifier binds to — a built-in revision string for the packaged taxonomies and a content fingerprint for a custom file — stamping it into each AI-classified record, folding it into the reproducibility receipt, and folding it into the AI cache key so a run is always tied to the taxonomy that produced it.
• SM-005 Supply-chain build-gate mechanism (mechanism) — Realises the build-integrity side of SS-005 by gating the Gradle build on a dependency-vulnerability scan that fails on CVSS 7.0 or above, a runtime-licence allowlist, and generation of a CycloneDX 1.5 SBOM, and by enforcing the distribution invariant that ANTLR grammar-compiler JARs never ship in the runtime image.
• SM-006 Data-minimisation and residency-tier mechanism (mechanism) — Realises SS-006 by building the outbound AI payload from only the taxonomy, the method list and one class at a time (capped by maxClassChars), offering a fully local Tier-1 provider and an offline manual Tier-2 path that transmit nothing, with all network access code-confined to the AI package by an ArchUnit rule. As of 6.1.0 a dedicated ZeroEgressTest (RM-007) asserts zero non-loopback egress under Tier 1/2, realised by this mechanism.
• SM-007 Review-decision confidentiality mechanism (mechanism) — Realises SS-007 by keeping the override files and audit-trail artefacts that record human-review decisions entirely out of the outbound AI payload, and by masking detected credential values by default through the catalog-based credential detector so secret material is not echoed into prompts or output.
• SM-008 Enforced quality-gate mechanism (mechanism) — Realises SS-008 by wiring the per-module JaCoCo coverage floors (and, as of 6.1.0, the class-level AuditWriter >= 0.95 LINE rule — RM-004) and PIT mutation thresholds, plus PMD and SpotBugs (which run on both JDKs), the ArchUnit structural tests, and — on JDK <= 24, which includes the JDK-21 CI/CD build — Error Prone, into the Gradle check task and CI, so a regression that drops coverage or mutation score, trips static analysis or breaks an architecture rule fails the build before release. Error Prone runs on JDK <= 24 (the JDK-21 CI/CD path that gates every merge and release); on the JDK-25+ development build it is disabled (no release supports JDK 27) and PMD + SpotBugs are the active static-analysis gates — see AD-011.
• SM-009 Coordinated vulnerability disclosure channel mechanism (mechanism) — Realises SS-009 by operating a published private reporting channel — a GitHub private security advisory plus a PGP-protected e-mail address — and tracking each received report against the stated acknowledge, triage and remediation service levels, consistent with the ISO/IEC 29147 and 30111 disclosure and handling practices.
• SM-010 Trust-basis-and-limits statement mechanism (mechanism) — Realises SS-010 by publishing and keeping current a documented statement of what the product's trustworthiness rests on — GitHub's per-asset SHA-256 digests, deterministic reproducible evidence and enforced gates — and of its deliberate limit that managed-key signing is out of scope, across the README and docs set, with the strict-mode docs build failing on a broken or missing page.
• SM-012 Audit and evidence-schema version-control mechanism (mechanism) — Realises SS-012 by parsing the DeltaReport and ClassificationOverride audit-and-evidence schemas forward-compatibly against an explicit schema version constant, so a reader tolerates an added column while a breaking change is forced to bump the version and carry the same-PR documentation update required by policy PL-001.
• SM-013 Audit-trail integrity binding mechanism (mechanism) — Realises SS-013 by providing the hash bindings the product can carry — the GUI AuditWriter now populating the content_hash column and writing a manifest.sha256, the attestation manifest bound to content hash and commit SHA, the reproducibility receipt bound to SHA-256 of every input, and the scanner-script MANIFEST check — while recording honestly that this is hash-only integrity, with no managed-key signing (decision D-1).
• SM-014 AI-result reproducibility mechanism (mechanism) — Realises SS-014 by reusing cached AI classifications keyed by per-class content hash (with the taxonomy version folded into the key so a hit was produced under the current taxonomy), applying human overrides deterministically with overridden confidence pinned to 1.0/0.0, and fingerprinting the inputs in the reproducibility receipt, so a same-commit, same-cache re-run reproduces the reviewed record for unchanged classes.
• SM-015 Byte-level output-determinism guard mechanism (mechanism) — Realises the reproducibility side of SS-002 by removing the environmental sources of output divergence — line endings, locale-sensitive path ordering and content hashing across operating systems — and proving byte-identical regeneration locally with a dedicated determinism test, with a cross-OS CI matrix defined to confirm it on real runners (pending its first run, RM-001), so the same source revision yields an identical structural artefact on any host.
• SM-016 Classification-accuracy evaluation mechanism (mechanism) — Realises the assurance side of SS-003 by measuring how well the bounded classifier labels against a known-answer set — precision, recall and agreement computed by a dedicated command — so the quality of the AI layer is an observable, regenerable number rather than an assumption.
• SM-017 Release provenance and digest mechanism (mechanism) — Realises the distribution-integrity side of SS-005 by relying on the per-asset SHA-256 digest GitHub Releases records for every artefact as the authoritative digest consumers verify against (decision D-3 — no separate SHA256SUMS is shipped), and by generating a keyless SLSA build-provenance attestation for the release artefacts and running OpenSSF Scorecard (decision D-4 — keyless, no managed keys).
• SM-018 Comment-redaction mechanism (mechanism) — Realises the data-minimisation service SS-006 by stripping every comment from a source file to spaces before the outbound AI payload is built, fail-closed per language — if a to-be-sent file's language cannot be fully redacted the run aborts before anything is sent. Grounded in the CommentRedactor SPI, the CommentRedaction fail-closed service, the per-language redactors and the shared CommentBlanker.
• SC-001 JavaParser AST discovery component (component) — JavaParser 3.28.x
• SC-002 ANTLR4-runtime grammar discovery component (component) — ANTLR4 runtime 4.13.x
• SC-003 ArchUnit architecture-boundary component (component) — ArchUnit 1.4.x
• SC-004 ServiceLoader plugin-registry component (component) — Java ServiceLoader via PluginLoader
• SC-005 Determinism-guard component (ContentHasher, PortablePathOrder, LineEnding) (component) — MethodAtlas determinism guards (ContentHasher, PortablePathOrder, LineEnding)
• SC-006 Determinism CI-matrix component (component) — GitHub Actions determinism matrix (determinism.yml)
• SC-007 AI suggestion engine and provider-client component (component) — MethodAtlas AI engine and provider clients
• SC-008 Security-taxonomy and taxonomy-version component (component) — MethodAtlas security taxonomy and TaxonomyVersion
• SC-009 Classification-accuracy evaluation component (component) — MethodAtlas accuracy evaluator (EvalAccuracyCommand)
• SC-010 Dependency-vulnerability and licence gate component (component) — OWASP dependency-check and licence-report Gradle plugins
• SC-011 CycloneDX SBOM component (component) — CycloneDX Gradle plugin 3.3.x (CycloneDX 1.5)
• SC-012 Test-quality gate stack component (component) — JaCoCo, PIT (core 1.30.1 / junit5 plugin 1.2.3), PMD 7.28.0, SpotBugs 4.10.5 (plugin 6.5.13), Error Prone (JDK <= 24 only); Gradle 9.8.1
• SC-013 Release provenance and Scorecard component (component) — GitHub Actions attest-build-provenance and ossf/scorecard-action
• SC-014 Audit-trail and evidence-schema component (component) — MethodAtlas AuditWriter, AttestWriter and ReceiptBuilder
• SC-015 AI result-cache and override component (component) — MethodAtlas AiResultCache and ClassificationOverride
• SC-016 Credential-detection and masking component (component) — methodatlas-detect-secrets (CatalogCredentialDetector, Aho-Corasick)
• SC-017 Bundled scanner-script integrity component (component) — MethodAtlas scanner bundles with BundleIntegrity and PythonScriptIntegrity
• SC-018 Vulnerability-disclosure channel component (component) — GitHub Security Advisories and PGP security mailbox
• SC-019 Documentation publication component (component) — MkDocs Material and pandoc
• SC-020 Comment-redaction component (component) — MethodAtlas CommentRedactor SPI + per-language redactors (JavaParser / ANTLR / TS-estree / Python tokenize)
• SO-001 Weekly dependency-vulnerability scan (operation) — Scheduled OWASP dependency-check run completing with zero dependencies at CVSS >= 7.0., Weekly (security-scan.yml, Monday 03:00 UTC) and on every build.; owner the Architect and Programmer
• SO-002 Weekly mutation-test run (operation) — Scheduled PIT mutation run meeting every module's configured mutation threshold., Weekly (mutation-test.yml, Sunday 04:00 UTC) and within the per-build check.; owner the Architect and Programmer
• SO-003 Per-release gate and publication run (operation) — Every release passes the full gate chain (tests, coverage, mutation, PMD, SpotBugs) and publishes the archives, SBOM, PDF, per-asset SHA-256 digests and build-provenance attestation., Per release (release.yml, on release@* tags).; owner the Architect and Programmer
• SO-004 Automated dependency-update management (operation) — Open dependency-update PRs are triaged and merged so no high-severity dependency remains current for longer than the update cycle., Continuous (Renovate / Dependabot, grouped PRs with patch auto-merge).; owner the Architect and Programmer
• SO-005 Coordinated vulnerability-disclosure triage (operation) — Reported vulnerabilities acknowledged within 2 business days, triaged within 5, with a fix/mitigation plan within 30 days (critical/high) or 90 (lower)., Per report (continuous intake via the disclosure channel).; owner the Architect and Programmer
• SO-006 Per-release schema and taxonomy change review (operation) — Every change to a DeltaReport/ClassificationOverride field or to the taxonomy carries a version bump and same-PR documentation; zero unversioned contract changes ship., Per change / per release (review checklist, now backed by the schema-compatibility golden test on every build).; owner the Architect and Programmer
• SO-007 Evidence retention and release-cadence operation (operation) — Audit and evidence artefacts are retained at least as long as the consuming downstream audit cycle; releases are produced on an event-driven basis., Per release and per the adopter's retention cycle.; owner the Architect and Programmer

Annex B. Consistency check

0 errors and 0 warnings from the architecture consistency check.

Annex C. Governance, policy and trust register

Security strategies

Architecture decisions

• AD-001 Hashes yes, managed-key signing no (D-1) — MethodAtlas relies on published SHA-256 hashes (GitHub's automatic per-asset digest) and keyless build provenance for release integrity, and deliberately does NOT use managed-key cryptographic signing of release packages. Scope boundary: this governs the project's own releases only; the product's -attest and -evidence-pack features let consumers sign their own evidence and are unaffected.; rationale: Managed-key signing would require key management, rotation and administration not justified for an application of this size (owner decision D-1). Keyless SLSA provenance (D-4) was later admitted because it carries no long-lived keys. The residual — whole-JAR repackaging / channel substitution not cryptographically prevented, and OpenSSF Signed-Releases unmet — is accepted and documented (EX-001).; owner: the Architect and Programmer.
• AD-002 Deterministic structural layer, bounded AI layer — AST-based discovery is fully deterministic and never depends on AI; the AI layer is confined to a closed, versioned taxonomy and an explicit list of discovered methods, so it can neither invent nor omit a method. The two layers are kept strictly separate.; rationale: Regulated adopters need output that is traceable, repeatable and defensible. Determinism makes the structural record re-checkable; bounding the AI turns a non-deterministic component into an auditable one. The separation is enforced at build time by ArchUnit (SC-003).; owner: the Architect and Programmer.
• AD-003 ServiceLoader plugin-seam boundary — Language support is provided by independent discovery plugins resolved at runtime through ServiceLoader. The core holds no language parsing and no provider code; plugins depend only on the API module; plugins do not depend on each other. Provider order is sorted by plugin id.; rationale: The optional-plugin model keeps the core small and lets a language be added or omitted without touching it, which bounds the blast radius of a plugin change and keeps discovery deterministic regardless of which plugins are present. The three boundary rules are enforced by ArchUnit (SC-003) and the sorted order by PluginLoader (SC-004).; owner: the Architect and Programmer.
• AD-004 The human-reviewed decision is the authoritative record — The authoritative classification of record is the human-reviewed result — the content-hash-keyed AI cache plus the override file — not the raw AI output. Overrides are applied deterministically with confidence pinned to 1.0/0.0 and take precedence over AI output.; rationale: Because AI inference is non-deterministic, the reviewed artefact is what an evidence package should rest on; re-running on the same commit with the same cache reproduces it for unchanged classes. This makes AI-influenced output reproducible for audit (CO-014).; owner: the Architect and Programmer.
• AD-005 Frozen-contract versioning for audit and taxonomy artefacts — The DeltaReport CSV columns, the ClassificationOverride YAML fields and the closed taxonomy are treated as frozen contracts. Changing one is a versioned, documented change — bump the schema/taxonomy version and update the README, CLI reference and audit-format docs in the same PR; columns are appended, never reordered or retyped.; rationale: Downstream compliance tooling and the GUI audit trail consume these contracts; an unversioned break would silently desync them. This is the policy PL-001 and is the rationale behind the audit/evidence and taxonomy version-control services (CO-004, CO-005).; owner: the Architect and Programmer.
• AD-006 Grammar-compiler JARs are excluded from the distribution — The ANTLR grammar-compiler JARs (antlr4, ST4, icu4j, antlr-runtime, treelayout) must not ship in lib/; only the antlr4-runtime is distributed. The exclusion is wired on both runtimeClasspath and guiRuntime and is re-verified after any ANTLR version bump.; rationale: Only the runtime is needed at execution time; shipping the compiler toolchain would enlarge the attack surface of the distributed artefact for no functional gain. This is a distribution-integrity decision under build-and-distribution integrity (CO-006).; owner: the Architect and Programmer.
• AD-007 Three-tier data-residency model — AI enrichment is offered in three residency tiers — Tier 1 local Ollama (no egress), Tier 2 operator-controlled manual prepare/consume (no egress from the scan host), and Tier 3 hosted provider over HTTPS (minimal payload) — so the adopter chooses what, if anything, leaves the host.; rationale: Regulated and air-gapped adopters have different egress constraints; offering local and manual zero-egress paths alongside the hosted path lets the tool serve strict-DLP environments while still supporting hosted inference where permitted. This realises data minimisation (CO-007) and underpins credible offline operation (CO-012).; owner: the Architect and Programmer.
• AD-008 Keyless SLSA build provenance adopted (D-4) — The release workflow attaches SLSA build provenance to the release artefacts using keyless attestation (GitHub OIDC + Sigstore), and the project publishes an OpenSSF Scorecard. No managed keys are used.; rationale: Keyless provenance gives consumers a way to verify that an artefact was produced by this repository's pipeline, detecting tampering during the build, without the key-management burden that D-1 declined. It is technically a signed attestation, which the owner explicitly accepted (D-4) as consistent with D-1's rationale; it strengthens build-and-distribution integrity (CO-006) and the transparency posture (CO-011) and partially mitigates EX-001.; owner: the Architect and Programmer.
• AD-009 Per-module risk-proportionate quality floors — Coverage and mutation floors are set per module rather than as a single global bar, sized to each module's measured state and risk. Floors are normally raised as test strength improves, but they are not strictly one-way: a floor may be deliberately reduced by owner decision when reality requires it — the root PIT mutation standard was lowered to 55% (owner decision 2026-10-15) when new compliance/evidence feature code brought the measured score below the earlier 60%.; rationale: Different modules carry different risk (the audit-trail surface is held far higher than a Swing view layer), so per-module floors target assurance where it matters. Floors are kept honest against the measured reality: they are raised when test strength grows and reduced when an owner decides a lower but still-enforced standard reflects the real risk/measurement trade-off, rather than leaving an aspirational number that fails the build. This operationalises the enforced test-quality objective (CO-009).; owner: the Architect and Programmer.
• AD-010 SABSA library version unified onto the product version (6.1.0) — The SABSA library, which had been numbered separately from the product and started later with its own lower sequence (last 0.3.0), is re-baselined to the product release number 6.1.0 so that the library and the product share a single version line from now on.; rationale: A separate, lower library numbering made it harder for a reader to see which product release a given architecture snapshot describes. Aligning the library onto the product version removes that ambiguity and supports a transparent, single-version trust story (CO-011). This is a deliberate one-off re-numbering — a jump to match the product — not an increment of the library's own sequence, and it changes no architecture content by itself.; owner: the Architect and Programmer.
• AD-011 Build supports JDK 21+ (dev JDK 27, CI/CD JDK 21); Error Prone disabled on JDK 25+ — The project supports JDK 21 or later (baseline enforced at Gradle configuration time). From the 6.1.0 release two build JDKs are in routine use: the development machine builds on JDK 27, while CI/CD builds on JDK 21 (every .github/workflows and .gitea/workflows job sets java-version '21', Temurin). To run the quality gates on JDK 27 as well as JDK 21 the build toolchain was bumped (Gradle 9.4.0 -> 9.8.1, PMD 7.24.0 -> 7.28.0, SpotBugs 4.9.8 -> 4.10.5, SpotBugs plugin 6.5.4 -> 6.5.13, and PIT core pinned to 1.30.1 with the junit5 plugin at 1.2.3, required for the JDK-27 build). Because no Error Prone release supports JDK 27 (it crashes inside the compiler), Error Prone is disabled on JDK 25 and above via a committed build guard, so it does not run on the JDK-27 dev build; PMD and SpotBugs run on both JDKs and are the active static-analysis gates on the JDK-27 build, while Error Prone still runs on the JDK-21 CI/CD build (JDK <= 24), which is the enforced static-analysis path for every merge and release.; rationale: Supporting JDK 21+ while developing on JDK 27 required current build tooling that runs on both, which is recorded transparently as a supply-chain fact (BA-006). The Error Prone limitation is a deliberate, documented trade-off: rather than pin development to an older JDK, the project accepts that on the local JDK-27 build Error Prone does not run and relies on PMD and SpotBugs there, while Error Prone coverage is retained on the JDK-21 CI/CD path that actually gates merges and releases. The "runs in CI" mitigation is therefore real, not assumed: CI is JDK 21. Recording the limit openly serves transparency (BA-012) and keeps the Verifiably-Tested posture (BA-009) honest about which static-analysis gates run on which JDK. The residual risk from the reduced static-analysis coverage on the local JDK-27 build has now, at the 6.1.0 release gate (2026-10-14), been formally ACCEPTED by the owner on an interim, time-boxed basis expiring 2026-12-31, recorded as exception EX-011; this decision continues to document the toolchain facts and the limitation, while EX-011 carries the owner's risk acceptance and the compensating controls (PMD and SpotBugs on JDK 27, Error Prone on the JDK-21 CI/CD path), to be revisited when an Error Prone release supports JDK 27.; owner: the Architect and Programmer.

Policies

• PL-001 Frozen-contract versioning discipline — Any change to a frozen product contract — the closed security taxonomy, or the DeltaReport / ClassificationOverride audit-and-evidence schemas — is permitted only with a version increment and the required documentation update made in the same change; silent renames, reorders, retypes or content changes to a frozen contract are prohibited.; owner: the Architect and Programmer; objectives: CO-004, CO-005.
• PL-002 Evidence-retention and release-cadence policy — Evidence and audit artefacts produced by the product (evidence CSVs, override YAML, attestation manifests, reproducibility receipts, SBOMs, gate reports) are retained at least as long as the consuming downstream audit cycle. Releases — hashed, not managed-key signed (D-1) — are produced on an event-driven / as-needed basis rather than on a fixed calendar. There is no shorter retention that would discard an artefact an auditor may still need.; owner: the Architect and Programmer; objectives: CO-013, CO-006.

Trust relationships

• TR-001 Scan host trusts its discovery-plugin classpath — DM-001 → DM-006; purpose: The scan host loads and runs whatever discovery-plugin JARs are on its classpath via ServiceLoader, trusting them to emit only genuine discovered methods.; basis: Conditional and partly assumed. The ServiceLoader seam is open — any JAR with a service registration loads — so trust in the classpath contents is an assumption the adopter must manage. It is cryptographically assured only for the two scripted plugins, whose TypeScript/Python scanner bytes are verified against a build-time MANIFEST SHA-256 (SM-001/SC-017) and fail closed on mismatch. Recorded as a known limitation.; assurance: .
• TR-002 Scan host trusts the hosted AI provider for bounded classification only — DM-001 → DM-004; purpose: When Tier-3 AI is configured, the scan host trusts the hosted provider to return a classification — but only within a closed vocabulary and only for the methods the parser already found.; basis: Tightly bounded. The provider cannot invent or omit methods: it receives the explicit discovered-method list and the closed, versioned taxonomy, and its output is constrained to that vocabulary (SM-003). The correctness of the label within the taxonomy is not independently measured (EX-004), and the AI layer is non-deterministic by nature, which is why it is kept out of the deterministic structural layer (AD-002).; assurance: .
• TR-003 Hosted AI provider is entrusted with the minimal payload only — DM-001 → DM-004; purpose: The scan host entrusts the hosted provider with exactly one test class's source plus method names and the taxonomy — and withholds everything else.; basis: Data-minimising by construction (SM-006/SC-007). Never transmitted: production source beyond the class, build scripts, configuration, credentials, database schemas, infrastructure definitions, other test files, or file paths. The provider's retention is governed by its own data policy, outside the product; EU-residency providers exist for organisations that require them. Tier 1/2 avoid the provider entirely.; assurance: .
• TR-004 Consumer trusts the release by hash and provenance, not signature — DM-007 → DM-003; purpose: A consumer or auditor trusts that a downloaded release artefact is the genuine one by checking its SHA-256 digest and its build provenance.; basis: Integrity, not non-repudiable origin. GitHub publishes an automatic per-asset SHA-256 digest (D-3) and the build attaches keyless SLSA provenance (D-4, verifiable with gh attestation verify). There is deliberately no managed-key release signature (D-1), so a hash confirms the artefact matches the reference and provenance records how it was built, but neither is a managed-key proof of origin — the accepted residual EX-001.; assurance: .
• TR-005 Build domain trusts the dependency supply conditionally — DM-002 → DM-006; purpose: The build consumes third-party libraries and vulnerability data from upstream registries, trusting them only after gates have passed.; basis: Gated, not blind. Every dependency is checked by the OWASP dependency-check (fail on CVSS≥7.0), the licence allowlist and the CycloneDX SBOM (SM-005/SC-010/SC-011); grammar-compiler JARs are excluded from the shipped artefact (AD-006); Renovate/Dependabot keep versions current. A poisoned dependency remains the residual supply-chain threat (RO-005).; assurance: .
• TR-006 Distribution trusts the build pipeline to produce the release — DM-003 → DM-002; purpose: The published release is trusted to be the output of the project's own build pipeline, not a substitute.; basis: Attested, keyless. The release workflow attaches SLSA build provenance via keyless attestation (D-4), so a consumer can verify the artefact was produced by this repository's pipeline. The build runs on a single GitHub-hosted runner with least-privilege, job-scoped write permissions; absent managed-key signing (D-1), provenance is the origin evidence, and a whole-build compromise is the residual the provenance is designed to make detectable.; assurance: .
• TR-007 Auditor trusts the on-host audit artefacts as tamper-evident — DM-007 → DM-001; purpose: An auditor relies on the audit-trail artefacts the scan host writes — evidence CSV, overrides YAML, attestation manifest, receipts — as a faithful, tamper-evident record.; basis: Hash-bound where it matters, with a stated residual. The attestation manifest (content hash + commit SHA), reproducibility receipts (SHA-256 of inputs) and the scanner-script check are cryptographically tamper-evident; the GUI evidence CSV and overrides YAML now carry a populated content_hash and a manifest.sha256 (SM-013/SC-014), so modification is detectable by comparison. The artefacts are not managed-key signed (D-1) and are not protected at rest on the host (EX-003), so the manifest should be anchored (committed or packed).; assurance: .
• TR-008 Maintainer trusts researchers through the mediated disclosure channel — DM-002 → DM-008; purpose: Security researchers are trusted to report vulnerabilities responsibly through a controlled channel that reaches the maintainer for triage and fix.; basis: Mediated and one-way. Reports arrive via GitHub private advisories or the PGP-encrypted security mailbox (SM-009/SC-018); the maintainer operates coordinated disclosure to published SLAs (acknowledge 2 business days, triage 5, fix 30/90) following ISO/IEC 29147 and 30111. Trust is in the process, not in any unauthenticated public channel — public issues are explicitly not used for vulnerabilities.; assurance: .

Exceptions

• EX-001 Owner-accepted unsigned-release residual (interim, expires 2026-12-31) — Owner decision D-1 declines managed-key cryptographic signing of release packages (Sigstore/cosign, GPG or any long-lived signing keyring) because the key management, rotation and administration burden is not justified for an application of this size. Trust therefore rests on GitHub's verifiable per-asset SHA-256 digests (D-3), reproducibility receipts, the scanner-script manifest-hash check and the enforced gates. The consequence is that a whole-JAR repackaging (script and its MANIFEST.MF hash rewritten together) or a distribution-channel substitution (artefact and its digest replaced together) is not cryptographically defended by a managed-key signature, because a hash gives integrity and a reference to compare against but not non-repudiable proof of origin. OpenSSF Scorecard's Signed-Releases check is therefore deliberately not met. PARTIAL MITIGATION (D-4): the release now attaches keyless SLSA build provenance (no managed keys), which lets a consumer verify the artefact was produced by this repository's pipeline and makes tampering during the build detectable — so the residual is narrower than before, though the artefact itself is still not managed-key signed.; risk acceptance: The owner (the Architect and Programmer) formally ACCEPTED this residual (RO-013) on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. Acceptance is INTERIM: at or before 2026-12-31 it must be re-evaluated — confirmed, fixed or renewed. Accepting the risk does not resolve the underlying gap: whole-JAR repackaging / distribution-channel substitution remains cryptographically undefended and OpenSSF Signed-Releases remains unmet for the duration of the acceptance. Provenance note (2026-10-14): this acceptance was given on 2026-10-13 under the project owner; on 2026-10-14 the owner identifier in this wording was generalised to the role "the Architect and Programmer" as part of a documentation privacy scrub — the substance of the acceptance is unchanged and awaits the owner's re-confirmation at re-approval.; owner: the Architect and Programmer; expires: 2026-12-31.
• EX-002 GUI audit artefacts hash-bound — RESOLVED in 6.1.0 (hash-binding verified by JUnit tests) — RESOLVED in 6.1.0. This exception recorded the residual against the audit-defensibility objective (CO-013) that arose from the BA-013 limitation: the GUI audit-trail artefacts under .methodatlas/ — the evidence CSV and overrides.yaml — were append/accumulate and timestamped but carried no cryptographic binding (no content hash chaining the records to the run that produced them), leaving GUI override/audit records open to undetected after-the-fact modification. Fix RM-B populates the content_hash column and writes a manifest.sha256 over the audit artefacts (mechanism SM-013 / component SC-014), making a rewrite detectable. At the 6.1.0 release gate the owner confirmed closure conditional on passing JUnit tests, and those tests exist and pass (verified green): methodatlas-gui-core/src/test/java/org/egothor/methodatlas/gui/service/AuditWriterTest.java — evidenceCsv_contentHashIsWrittenVerbatim (the content_hash column is written) and manifest_recordsCorrectSha256OfCsvAndOverrides / manifest_keepsOldCsvDigestAndRefreshesOverrides (the .methodatlas/manifest.sha256 SHA-256 manifest over the CSV and overrides). The gap is therefore fixed and verified, so this exception is resolved (closure by remediation and test verification, not by continued risk acceptance).; risk acceptance: The owner (the Architect and Programmer) had formally ACCEPTED this residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. That interim acceptance is now discharged because the underlying gap has been FIXED and VERIFIED, not merely accepted: at the 6.1.0 release gate (2026-10-14) the owner confirmed closure conditional on passing JUnit tests, and the named tests in AuditWriterTest pass green, proving the content_hash column and the manifest.sha256 SHA-256 manifest are written as designed. This closure rests on remediation-and-verification evidence; the owner confirms at re-approval. Provenance note (2026-10-14): the original acceptance was given on 2026-10-13 under the project owner and the owner identifier was later generalised to the role "the Architect and Programmer" in a documentation privacy scrub.; owner: the Architect and Programmer; expires: resolved 2026-10-14 by remediation (RM-B hash-binding) and verified by the named JUnit tests (AuditWriterTest.evidenceCsv_contentHashIsWrittenVerbatim, manifest_recordsCorrectSha256OfCsvAndOverrides, manifest_keepsOldCsvDigestAndRefreshesOverrides) — forward expiry no longer applies (was 2026-12-31, from the time-boxed D-2 interim acceptance now discharged).
• EX-003 Owner-accepted absence of at-rest protection for override/audit files (interim, expires 2026-12-31) — The product applies no at-rest confidentiality or operating-system file-permission hardening to the override and audit files it writes (the .methodatlas/ overrides and evidence artefacts). They are written with whatever permissions the invoking environment's umask grants and are not encrypted at rest. This is the stated limitation behind BA-008 (protection of trust assets at rest): on a shared or weakly-permissioned host the override/audit files are readable and editable by any local principal, against the at-rest-protection objective (CO-008).; risk acceptance: The owner (the Architect and Programmer) formally ACCEPTED this residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. Acceptance is INTERIM: at or before 2026-12-31 it must be re-evaluated — confirmed, fixed or renewed. Accepting the risk does not resolve the underlying gap: override/audit files remain without at-rest or file-permission protection for the duration of the acceptance. Provenance note (2026-10-14): this acceptance was given on 2026-10-13 under the project owner; on 2026-10-14 the owner identifier in this wording was generalised to the role "the Architect and Programmer" as part of a documentation privacy scrub — the substance of the acceptance is unchanged and awaits the owner's re-confirmation at re-approval.; owner: the Architect and Programmer; expires: 2026-12-31.
• EX-004 Owner-accepted unmeasured in-taxonomy classification accuracy (interim, expires 2026-12-31) — The AI engine constrains classification to a closed, versioned security taxonomy and an explicit method list, so it cannot invent or omit methods; but the accuracy of the classification WITHIN that closed taxonomy — whether a correctly-listed method is assigned the right category — is not measured against a labelled ground-truth set. BA-003 (classification trustworthiness) therefore has no quantified accuracy figure, only the structural guarantees of the closed taxonomy. The gap leaves the correctness objective (CO-003) asserted structurally but unverified empirically. STATUS: the MEANS to measure accuracy now exists (code fix RM-E: the -eval-accuracy command and AccuracyMetrics, component SC-009, scoring AI output against a human-reviewed ground-truth label set). What remains open — and keeps this interim acceptance in force — is an owner-set accuracy target and a maintained labelled set, tracked by roadmap RM-002. So accuracy is now measurable but not yet measured against a target.; risk acceptance: The owner (the Architect and Programmer) formally ACCEPTED this residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. Acceptance is INTERIM: at or before 2026-12-31 it must be re-evaluated — confirmed, fixed or renewed. Accepting the risk does not resolve the underlying gap: in-taxonomy classification accuracy remains unmeasured for the duration of the acceptance. Provenance note (2026-10-14): this acceptance was given on 2026-10-13 under the project owner; on 2026-10-14 the owner identifier in this wording was generalised to the role "the Architect and Programmer" as part of a documentation privacy scrub — the substance of the acceptance is unchanged and awaits the owner's re-confirmation at re-approval.; owner: the Architect and Programmer; expires: 2026-12-31.
• EX-005 Owner-accepted untested cross-machine determinism (interim, expires 2026-12-31) — The determinism contract (BA-002) — AST-based discovery is deterministic and reproducible — is exercised by ME-002, but ME-002 runs on a single machine. Cross-machine and cross-platform reproducibility (same inputs producing byte-identical output across different hosts, operating systems and JDK builds) is not tested. The gap leaves the reproducibility objective (CO-002) demonstrated on one environment but unverified as portable, which is precisely the property a regulated consumer needs when reproducing evidence on their own infrastructure. STATUS: the determinism bug this exposed (OS-dependent Java content_hash via platform line endings) is FIXED (code fix RM-D: ContentHasher now normalises line endings, plus PortablePathOrder, LineEnding, and a three-OS determinism.yml matrix), and it passes locally. What keeps this interim acceptance in force is a green run of that matrix on real GitHub runners, tracked by roadmap RM-001.; risk acceptance: The owner (the Architect and Programmer) formally ACCEPTED this residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. Acceptance is INTERIM: at or before 2026-12-31 it must be re-evaluated — confirmed, fixed or renewed. Accepting the risk does not resolve the underlying gap: cross-machine / cross-platform determinism remains untested for the duration of the acceptance. Provenance note (2026-10-14): this acceptance was given on 2026-10-13 under the project owner; on 2026-10-14 the owner identifier in this wording was generalised to the role "the Architect and Programmer" as part of a documentation privacy scrub — the substance of the acceptance is unchanged and awaits the owner's re-confirmation at re-approval.; owner: the Architect and Programmer; expires: 2026-12-31.
• EX-006 Evidence-retention and release cadence — RESOLVED (D-3) — RESOLVED by owner decision D-3. A retention and cadence policy is now defined: evidence and audit artefacts are retained at least as long as the consuming downstream audit cycle, and hashed releases (no managed-key signing, per D-1) are produced on an event-driven / as-needed basis rather than a fixed calendar. This is recorded as policy PL-002 and operation SO-007, giving CO-013 the temporal governance frame it previously lacked.; risk acceptance: CLOSED. This residual is no longer accepted as a gap — it is resolved by decision D-3, operation SO-007 and policy PL-002. The exception is retired; no interim acceptance remains to re-evaluate.; owner: the Architect and Programmer; expires: 2026-12-31.
• EX-007 Per-record taxonomy-version field — RESOLVED in 6.1.0 (verified by JUnit tests) — RESOLVED in 6.1.0. This exception recorded the residual against the per-classification provenance objective (CO-004) that arose from the BA-004 limitation: emitted classification records did not carry a per-record taxonomy-version field — the taxonomy was fingerprinted only once, into the per-run reproducibility receipt — so a consumer reading a single emitted classification in isolation could not tell which taxonomy version produced it without also holding the matching run receipt. Fix RM-C stamps a per-record ai_taxonomy_version into the CSV/JSON/SARIF output and folds the taxonomy version into the AI cache key (components SC-008/SC-015), so each classification carries its own taxonomy version. At the 6.1.0 release gate the owner confirmed closure conditional on passing JUnit tests, and those tests exist and pass (verified green): methodatlas-ai/src/test/java/org/egothor/methodatlas/ai/TaxonomyVersionTest.java and methodatlas-emit/src/test/java/org/egothor/methodatlas/emit/TaxonomyVersionEmissionTest.java. The gap is therefore fixed and verified, so this exception is resolved (closure by remediation and test verification, not by continued risk acceptance).; risk acceptance: The owner (the Architect and Programmer) had formally ACCEPTED this residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. That interim acceptance is now discharged because the underlying gap has been FIXED and VERIFIED, not merely accepted: at the 6.1.0 release gate (2026-10-14) the owner confirmed closure conditional on passing JUnit tests, and TaxonomyVersionTest (methodatlas-ai) and TaxonomyVersionEmissionTest (methodatlas-emit) pass green, proving the per-record ai_taxonomy_version is produced and emitted as designed. This closure rests on remediation-and-verification evidence; the owner confirms at re-approval. Provenance note (2026-10-14): the original acceptance was given on 2026-10-13 under the project owner and the owner identifier was later generalised to the role "the Architect and Programmer" in a documentation privacy scrub.; owner: the Architect and Programmer; expires: resolved 2026-10-14 by remediation (RM-C per-record taxonomy-version field) and verified by the named JUnit tests (TaxonomyVersionTest in methodatlas-ai, TaxonomyVersionEmissionTest in methodatlas-emit) — forward expiry no longer applies (was 2026-12-31, from the time-boxed D-2 interim acceptance now discharged).
• EX-008 Offline-operation operationalisation — RESOLVED in 6.1.0 (zero-egress test shipped) — RESOLVED in 6.1.0. This exception recorded the residual against the offline-operation objective (CO-012): the per-release zero-outbound-read posture was stated with basis inferred because the only evidence — the HTTP_SUPPORT_CONFINED_TO_AI_PACKAGE ArchUnit rule — confined which package may use HttpSupport but did NOT prove zero non-loopback egress. Roadmap RM-007 is now DONE: the new ZeroEgressTest (realised via SM-006) asserts zero non-loopback connections under a structural scan and the manual Tier-2 path, with a Tier-1 loopback sentinel, verified green on JDK 27. That hard egress evidence closes the gap, so CO-012 moves to stated and this exception is resolved (the fix shipped — closure by remediation, not by continued risk acceptance).; risk acceptance: The owner (the Architect and Programmer) had formally ACCEPTED this residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. That interim acceptance is now discharged because the underlying gap has been FIXED, not merely accepted: RM-007 / ZeroEgressTest provides the zero-egress evidence the acceptance was holding the place for. This closure rests on remediation evidence; the owner confirms at re-approval. Provenance note (2026-10-14): the original acceptance was given on 2026-10-13 under the project owner and the owner identifier was later generalised to the role "the Architect and Programmer" in a documentation privacy scrub.; owner: the Architect and Programmer; expires: resolved 2026-10-14 by remediation (RM-007 / ZeroEgressTest) — forward expiry no longer applies (was 2026-12-31, from the time-boxed D-2 interim acceptance now discharged).
• EX-009 AuditWriter coverage bar — RESOLVED in 6.1.0 (class-level gate enforced) — RESOLVED in 6.1.0. This exception recorded the residual against the assurance-coverage objective (CO-009). The BA-009 trust-critical surface list had already been confirmed by the owner under decision D-3, so the only item still accepted on an interim basis was the >=95% AuditWriter coverage bar, which was not an enforced gate (only the per-module floors were). Roadmap RM-004 is now DONE: a class-level JaCoCo violationRule enforces >= 0.95 LINE coverage on org.egothor.methodatlas.gui.service.AuditWriter (measured 97.4%), wired into check, so the bar fails the build if it regresses — verified green on JDK 27. The bar is now an enforced gate, closing the only remaining item, so this exception is resolved (closure by remediation, not by continued risk acceptance).; risk acceptance: The owner (the Architect and Programmer) had formally ACCEPTED this narrowed residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2. That interim acceptance is now discharged because the underlying gap has been FIXED, not merely accepted: RM-004 enforces the >=95% AuditWriter bar as a class-level JaCoCo gate. The trust-critical surface list itself was already confirmed under D-3. This closure rests on remediation evidence; the owner confirms at re-approval. Provenance note (2026-10-14): the original acceptance was given on 2026-10-13 under the project owner and the owner identifier was later generalised to the role "the Architect and Programmer" in a documentation privacy scrub.; owner: the Architect and Programmer; expires: resolved 2026-10-14 by remediation (RM-004 class-level AuditWriter gate) — forward expiry no longer applies (was 2026-12-31, from the time-boxed D-2 interim acceptance now discharged).
• EX-010 OpenSSF Scorecard / SLSA provenance — implemented, pending first run — Decision D-1 left as a secondary open question whether the project would publish an OpenSSF Scorecard or SLSA provenance — neither of which requires the managed signing keys D-1 declined. Neither is currently published. For an OSS security tool, a published Scorecard and provenance are part of the consumer-facing trust signal that lets downstream users assess the project's own supply-chain posture; their absence leaves the transparency objective (CO-011) and the build-and-distribution-integrity objective (CO-006) short of the fuller external-attestation signal a consumer might expect, over and above the published hashes and reproducibility receipts. STATUS: IMPLEMENTED (pending first run). Code fix RM-F adds the OpenSSF Scorecard workflow and keyless SLSA build provenance (decision D-4, no managed keys; component SC-013). What keeps this interim acceptance in force is a first green Scorecard run and a verified provenance attestation on a real release, tracked by roadmap RM-003. Scorecard's Signed-Releases check stays unmet by design (D-1).; risk acceptance: The owner (the Architect and Programmer) formally ACCEPTED this residual on 2026-10-13 as a time-boxed authority act expiring 2026-12-31, per decision D-2 (and deferring the secondary D-1 open item). Acceptance is INTERIM: at or before 2026-12-31 it must be re-evaluated — confirmed, fixed or renewed. The workflows are now implemented (fix RM-F / decision D-4; component SC-013) and committed; what keeps this interim acceptance in force is a first green Scorecard run and a verified provenance attestation on a real GitHub release, tracked by roadmap RM-003. Scorecard's Signed-Releases check stays unmet by design (D-1). Provenance note (2026-10-14): this acceptance was given on 2026-10-13 under the project owner; on 2026-10-14 the owner identifier in this wording was generalised to the role "the Architect and Programmer" as part of a documentation privacy scrub — the substance of the acceptance is unchanged and awaits the owner's re-confirmation at re-approval.; owner: the Architect and Programmer; expires: 2026-12-31.
• EX-011 Owner-accepted Error-Prone-on-JDK-27 residual (interim, expires 2026-12-31) — Error Prone is disabled on JDK 25 and above via a committed build guard because no Error Prone release supports JDK 27 (it crashes inside the compiler), so Error Prone does NOT run on the JDK-27 development build (AD-011). On that build PMD and SpotBugs are the active static-analysis gates, but the loss of Error Prone narrows static-analysis coverage on the local JDK-27 build against the enforced-test-gate objective (CO-009) and the Verifiably-Tested posture (BA-009). AD-011 records this as a transparent, documented limitation; what this exception adds is the owner's formal acceptance of the residual risk it leaves, which is an owner authority act that AD-011 itself does not perform.; risk acceptance: The owner (the Architect and Programmer) formally ACCEPTED this residual on 2026-10-14 as a time-boxed authority act expiring 2026-12-31, at the 6.1.0 release gate (00-sources/09-release-6.1.0.md). Acceptance is INTERIM: at or before 2026-12-31 it must be re-evaluated — confirmed, fixed or renewed — and in particular revisited when an Error Prone release supports JDK 27, at which point Error Prone can be re-enabled on the JDK-27 build and the residual closed. Compensating controls hold during the acceptance: PMD and SpotBugs remain enforced static-analysis gates on the JDK-27 build, and Error Prone remains enforced on the JDK-21 CI/CD path (JDK <= 24), which gates every merge and release (every workflow sets java-version '21'). Accepting the risk does not resolve the underlying gap: Error Prone still does not run on the JDK-27 dev build for the duration of the acceptance. This supersedes the earlier position recorded in AD-011 that no residual risk from the reduced JDK-27 static-analysis coverage had been formally accepted.; owner: the Architect and Programmer; expires: 2026-12-31.

Annex D. Logical information and access model

Annex E. Assurance evidence and transition

Measures and evidence

• ME-001 Scanner-script hash-check conformance — Whether the CI abort-on-mismatch test passes (a deliberately mutated scanner script aborts before execution) and whether the MANIFEST.MF script hash is build-generated (not a hand-editable committed value), per build; count of builds that ship with the abort-on-mismatch test failing or absent.; target The abort-on-mismatch test passes on every build and the manifest hash is build-generated; 0 builds ship with the test failing or absent.; source JUnit result of the CI test that mutates a scanner script and asserts abort-before-execution, and the build-configuration check that the manifest hash is generated at build time, with the recorded build pass/fail.; per-build; owner the Architect and Programmer; breach action: Fail the build and block the release if the abort-on-mismatch test fails or is absent, or if the manifest hash is not build-generated..
• ME-002 Structural-output determinism — Byte-level difference between structural outputs of repeated discovery runs on the same commit; number of structural fields whose value varies across runs on an unchanged revision.; target Byte-identical structural output across runs on the same revision (0 differing bytes); 0 structural fields varying for an unchanged class.; source CI determinism-test output (scans a fixture twice and diffs the structural output byte-for-byte) and the reproducibility receipt recording SHA-256 of every input.; per-build; owner the Architect and Programmer; breach action: On any structural byte difference, fail the build and block the release until the source of non-determinism is found and removed..
• ME-003 AI-output bounding conformance — Whether the CI bounding tests pass — AI responses validated against the versioned taxonomy (out-of-taxonomy labels rejected) and reconciled against the AST method set (invented/omitted methods caught), exercising injected and malformed provider content; count of builds that ship with a bounding test failing.; target All bounding/validation tests pass each build (out-of-taxonomy labels rejected; 0 invented or omitted methods accepted); 0 builds ship with a bounding test failing.; source JUnit results of the CI bounding/validation tests (injected and malformed provider content; taxonomy-label validation; AST/AI method-set reconciliation), with the recorded build pass/fail.; per-build; owner the Architect and Programmer; breach action: Fail the build and block the release if a bounding/validation test fails..
• ME-004 Taxonomy version-control conformance — Number of changes to the taxonomy content shipped without a version increment and same-PR documentation; whether the effective taxonomy/prompt is fingerprinted into the reproducibility receipt for a classification run.; target 0 unversioned taxonomy changes; every taxonomy change carries a version bump and same-PR documentation; the effective taxonomy/prompt is fingerprinted into each reproducibility receipt.; source Git history of the taxonomy version record and taxonomy source files; the per-template prompt checksum / effective-prompt fingerprint recorded in the reproducibility receipt (schema v2).; per-change (taxonomy-edit PR review) and per-release; owner the Architect and Programmer; breach action: Block merge of any taxonomy change lacking a version bump or documentation; block the release if a reproducibility receipt lacks the effective-prompt fingerprint..
• ME-005 Audit and evidence schema version-control conformance — Number of breaking changes to DeltaReport columns or ClassificationOverride fields (rename, reorder, retype, remove) shipped without a schema version bump and the required documentation update.; target 0 unversioned breaking schema changes; every breaking change carries a schema version bump and a same-PR documentation update.; source Git diff of the DeltaReport/ClassificationOverride schema types between releases; the PR review record against the audit/schema-stability rule and the same-PR updates to README.md, docs/cli-reference.md and the audit-format docs.; per-change (PR review) and per-release; owner the Architect and Programmer; breach action: Block merge of any breaking schema change that lacks a version bump or documentation; block the release if a silent schema break is detected..
• ME-006 Build and distribution integrity — dependency-check highest CVSS permitted to ship; number of non-allowlisted licences; SBOM produced per build (yes/no); count of prohibited ANTLR grammar-compiler JARs present in lib/; release artefacts covered by GitHub's automatic per-asset SHA-256 digest.; target Build fails on any dependency CVSS >= 7.0; 0 non-allowlisted licences; SBOM generated every build; 0 prohibited grammar-compiler JARs in lib/; every release artefact covered by GitHub's per-asset SHA-256 digest. Managed-key signatures are deliberately out of scope (D-1).; source dependency-check report, licence report and CycloneDX SBOM published from the CI build; the lib/ content-inspection result; GitHub's automatic per-asset SHA-256 digest on each release asset.; per-build (gates) and per-release (checksums); owner the Architect and Programmer; breach action: Fail the build on any gate breach (CVSS, licence, SBOM, prohibited JARs). GitHub's per-asset digest is generated automatically, so there is no separate "publish checksum" step to gate..
• ME-007 Outbound data-minimisation conformance — Whether the CI data-governance payload-builder tests prove the outbound payload carries only the three permitted categories and no never-transmit item (production source, build scripts, config, credentials, DB schemas, infra definitions, other test files, file paths), and whether the ZeroEgressTest records 0 non-loopback outbound connections under Tier 1/2; count of builds where a payload test or the zero-egress test fails.; target Payload tests pass each build (only the three permitted categories; 0 never-transmit items); and (6.1.0) the ZeroEgressTest records 0 non-loopback outbound connections under a structural scan and the manual Tier-2 path, with the Tier-1 loopback sentinel passing.; source JUnit results of the data-governance payload-builder tests and the ZeroEgressTest in CI.; per-build (payload tests and zero-egress test); owner the Architect and Programmer; breach action: Fail the build if the payload carries any prohibited category or a never-transmit item, or if the ZeroEgressTest observes any non-loopback connection under Tier 1/2..
• ME-008 Override-confidentiality control conformance — Whether the CI data-governance test proves override and audit-trail files are excluded from every outbound payload and that credential values are masked by default; count of builds where the exclusion or masking test fails.; target The exclusion and masking tests pass each build (0 override/audit artefacts in any outbound payload; credential values masked by default).; source JUnit results of the payload-exclusion test (override/audit artefacts never in an outbound payload) and the credential-value masking test in the CI build, with the recorded build pass/fail.; per-build; owner the Architect and Programmer; breach action: Fail the build and block the release if the exclusion or masking test fails. Any override-confidentiality report received is routed to the CVD process and its acknowledge/triage/closure SLA is tracked there under ME-010, not re-tracked by this measure..
• ME-009 Enforced test-quality gates — JaCoCo instruction coverage and PIT mutation score at build, project-wide and for the named trust-critical surfaces (AuditWriter / gui-core, methodatlas-ai, methodatlas-emit); build pass/fail against the enforced thresholds; presence and pass/fail of the named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism).; target The enforced per-module floors (as set in build.gradle): root 70%/55%, methodatlas-ai 80%/70%, methodatlas-emit 65%/45%, methodatlas-gui-core 75%/50%, methodatlas-discovery-jvm 85%/60% (JaCoCo instruction / PIT mutation), build failing below any; the root mutation standard is 55% (owner decision 2026-10-15), deliberately reduced from the earlier 60% — the floors are risk-proportionate, not strictly one-way; and (6.1.0, stated) an enforced class-level JaCoCo >= 0.95 LINE gate on the AuditWriter audit-trail writer (measured 97.4%), wired into check — RM-004. Chosen (inferred) beyond those gates: the named trust-property tests present and passing.; source The JaCoCo coverage report and PIT mutation report published from the CI build (per docs/reports.md), read project-wide and for the named trust-surface modules, with the recorded build pass/fail and the named property-test results.; per-build; owner the Architect and Programmer; breach action: Fail the build when a per-module floor is not met, or when AuditWriter falls below its enforced class-level >= 95% line-coverage gate; block the release if a named trust-property test fails or is absent..
• ME-010 Vulnerability-disclosure SLA adherence — Adherence to the published response SLAs — acknowledge within 2 business days, triage within 5 business days, fix or mitigation plan within 30 days (critical/high) or 90 days (lower) — and availability of the private disclosure channel.; target 100% of received reports acknowledged <= 2 business days and triaged <= 5 business days; fix or mitigation plan within 30 days (critical/high) or 90 days (lower); disclosure channel published and operational.; source The coordinated-disclosure tracking record (per-report acknowledge / triage / plan timestamps); confirmation that the private advisory channel and published PGP contact remain available.; per-report, reviewed per-release; owner the Architect and Programmer; breach action: Escalate any report that breaches an SLA stage to the owner and record the slip; open a critical issue if the disclosure channel becomes unavailable..
• ME-012 Trust-basis-and-limits statement currency — Presence and currency of a documented trust-basis statement that (a) lists the evidence trust rests on and (b) states the limit — GitHub's per-asset SHA-256 digests give integrity, not signature-based non-repudiation; count of public trust claims, across the defined claim universe, not backed by a documented basis.; target Trust-basis-and-limits statement published and current for each release; 0 undocumented or unqualified trust claims across the defined universe (every claim names its evidence and its limit).; source The published trust-basis-and-limits statement (SECURITY.md / release notes), reviewed each release against the shipped controls, and a cross-check against the defined universe of public trust claims — README.md, SECURITY.md, release notes and the trust statements in docs/ (the surfaces where the project makes trust claims to consumers).; per-release; owner the Architect and Programmer; breach action: Block the release if the statement is missing, stale or inconsistent with the shipped controls, or if any claim in the defined universe is found unqualified..
• ME-013 Audit-trail integrity conformance — Whether the CI tests prove the PRESENCE of the cryptographic binding on each artefact that carries one — the attestation manifest binds content hash + commit SHA, the reproducibility receipt binds SHA-256 of every input, the scanner-script MANIFEST.MF hash check is present — and whether the AuditWriter appends to and never rewrites the overrides.yaml / evidence CSV; count of builds where one of these conformance tests fails or is absent. No metric counts "silent modifications detected", which the GUI CSV/YAML cannot support.; target Each binding-presence test passes every build (attestation, receipt and scanner-script bindings present) and the AuditWriter append-not-overwrite test passes; 0 builds ship with one of these tests failing or absent. The target does not assert tamper-detection of the unbound GUI CSV/YAML.; source JUnit results of the audit-trail binding-presence tests in the CI build (attestation content-hash/commit-SHA binding present, reproducibility-receipt SHA-256-of-inputs binding present, scanner-script MANIFEST.MF hash check present) and the AuditWriter append-not-overwrite test, with the recorded build pass/fail.; per-build; owner the Architect and Programmer; breach action: Fail the build and block the release if a binding-presence test or the AuditWriter append-not-overwrite test fails or is absent..
• ME-014 AI-result reproducibility conformance — For unchanged classes, number of fields in the AI-influenced classified output that differ between a reviewed record and a re-run on the same commit with the same populated -ai-cache; count of overridden records whose applied label or confidence differs from the deterministic override (confidence not pinned to 1.0/0.0); count of builds where the reproducibility regression test fails.; target 0 differing fields in the AI-influenced output across re-runs on the same commit with the same cache for unchanged classes; 100% of overrides applied deterministically with confidence pinned to 1.0/0.0; the reproducibility regression test passes each build.; source JUnit result of the CI regression test that classifies a fixture with a populated -ai-cache, re-runs on the same commit and diffs the AI-influenced output for unchanged classes, plus the override-determinism test (confidence pinned to 1.0/0.0).; per-build; owner the Architect and Programmer; breach action: Fail the build and block the release if the reproducibility regression test or the override-determinism test fails..
• ME-015 Comment-redaction no-leak conformance — Number of supported languages whose comments are not fully blanked by the redactor in test; count of runs on an unsupported language/file that do NOT abort fail-closed or that make any provider call before aborting; count of apply-tags/write-back runs under -redact-comments where the written-back source is not the original (unredacted) text; count of builds where the comment-redaction conformance tests fail.; target Every supported language's comments are fully blanked; an unsupported language/file always aborts fail-closed with 0 provider calls; write-back always uses the original source; the conformance tests pass each build.; source JUnit results in CI of the per-language CommentRedactor tests, the fail-closed abort test (unsupported language -> zero provider calls), the write-back-uses-original test, and the CredentialDetectionRunner comment-redaction tests.; per-build; owner the Architect and Programmer; breach action: Fail the build and block the release if any comment-redaction conformance test fails..
• EV-001 Scanner-script hash-check log and abort-on-mismatch test result — Test report and build-configuration record; collected by CI pipeline (Gradle build and discovery plugins); location The JUnit result for the mutated-script abort-before-execution test, and the build-configuration record showing the MANIFEST.MF script hash is generated at build time; with the recorded build pass/fail.; measures ME-001.
• EV-002 Reproducibility receipt and determinism-test result — Reproducibility receipt and test report; collected by CI pipeline (determinism test and receipt generator); location CI determinism-test output (byte-for-byte diff of repeated structural scans) and the reproducibility receipt (schema v2, SHA-256 of every input incl. per-template prompt checksums) produced per build.; measures ME-002.
• EV-003 AI-bounding validation and method-set reconciliation report — Test report; collected by CI pipeline (AI-bounding tests); location CI build-log entries for AI-response taxonomy validation and AST/AI method-set reconciliation, plus the results of the injected/malformed-content constraint tests.; measures ME-003.
• EV-004 Taxonomy version history and reproducibility-receipt fingerprint — Version record and git history; collected by Version-control system and release process (reviewed by the Architect); location Git history of the taxonomy version record and taxonomy source files; the same-PR documentation updates; the per-template prompt checksum / effective-taxonomy fingerprint recorded in the reproducibility receipts (schema v2).; measures ME-004.
• EV-005 Supply-chain gate reports, SBOM and per-asset digests — Report and per-asset digests; collected by CI pipeline and release process; location The dependency-check report, licence report and CycloneDX SBOM published from CI (per docs/reports.md); the lib/ content-inspection result; and GitHub's automatic per-asset SHA-256 digest on each release asset (plus the keyless build-provenance attestation, D-4).; measures ME-006.
• EV-006 Data-governance payload and zero-egress tests — Test report and network-check record; collected by CI pipeline (data-governance payload tests and ZeroEgressTest); location CI results of the outbound-payload data-governance tests (asserting only the three permitted categories, no never-transmit item) and, as of 6.1.0, the ZeroEgressTest record (RM-007) showing 0 non-loopback connections under a structural scan and the manual Tier-2 path with a Tier-1 loopback sentinel.; measures ME-007.
• EV-007 Override/audit payload-exclusion and credential-masking test result — Test report; collected by CI pipeline (data-governance and masking tests); location CI results of the test asserting override and audit-trail artefacts are excluded from every outbound payload, and the test asserting credential values are masked by default; with the recorded build pass/fail.; measures ME-008.
• EV-008 JaCoCo coverage and PIT mutation reports — Quality-gate report; collected by CI pipeline (Gradle check); location The JaCoCo coverage report and PIT mutation report published from the CI build (per docs/reports.md), read project-wide, for the named trust-surface modules (AuditWriter / gui-core, methodatlas-ai, methodatlas-emit) and for the enforced class-level AuditWriter >= 0.95 LINE rule (RM-004); the results of the named trust-property tests (hash-abort, structural determinism, payload exclusion, override determinism); with the recorded build pass/fail.; measures ME-009.
• EV-009 Vulnerability-disclosure SLA tracking record — Operational record; collected by Security-response process (Architect); location The coordinated-disclosure tracking record (per-report acknowledge / triage / fix-or-plan timestamps against the SLA clock) and confirmation that the published private advisory channel and PGP contact remain available.; measures ME-010.
• EV-010 Published trust-basis-and-limits statement — Published document; collected by Release process (Architect); location The trust-basis-and-limits statement (SECURITY.md / release notes), reviewed each release against the shipped controls, together with the cross-check of public trust claims against it.; measures ME-012.
• EV-012 Audit and evidence-schema version history — Version record and git history; collected by CI pipeline (schema-compatibility golden test) plus version-control system and PR review (the Architect); location The CI result of the SchemaCompatibilityGoldenTest (methodatlas-emit) that pins the names and order of the DeltaReport CSV columns and the ClassificationOverride YAML fields (and the CSV column set) and fails the build on any silent rename/reorder/removal — retype of the consumed DeltaReport CSV columns is additionally caught via their value round-trip, but the test does not type-check the ClassificationOverride YAML fields (RM-006); git diff of the DeltaReport / ClassificationOverride schema definitions between releases; the schema-version record; the same-PR review record against the audit/schema-stability rule and the same-PR updates to README.md, docs/cli-reference.md and the audit-format docs.; measures ME-005.
• EV-013 Audit-trail integrity test result — Test report; collected by CI pipeline (Gradle check); location CI results of the audit-trail binding-presence tests — the attestation content-hash/commit-SHA binding test, the reproducibility-receipt SHA-256-of-inputs binding test, the scanner-script MANIFEST.MF hash-check-present test, and the AuditWriter append-not-overwrite test — with the recorded build pass/fail.; measures ME-013.
• EV-014 AI-result reproducibility regression-test result — Test report; collected by CI pipeline (Gradle check); location CI result of the reproducibility regression test (classify a fixture with a populated -ai-cache, re-run on the same commit, diff the AI-influenced output for unchanged classes) and the override-determinism test (confidence pinned to 1.0/0.0).; measures ME-014.
• EV-015 Comment-redaction conformance test result — Test report; collected by CI pipeline (Gradle check); location CI results of the per-language CommentRedactor tests (comments blanked), the fail-closed abort test (unsupported language/file aborts with zero provider calls), the write-back-uses-original test, and the CredentialDetectionRunner comment-redaction tests.; measures ME-015.

Evidence	Measure	Attribute	Driver
EV-001	ME-001	BA-001	BD-001
EV-002	ME-002	BA-002	BD-002
EV-003	ME-003	BA-003	BD-003
EV-004	ME-004	BA-004	BD-004
EV-005	ME-006	BA-006	BD-006
EV-006	ME-007	BA-007	BD-007
EV-006	ME-007	BA-011	BD-010
EV-007	ME-008	BA-008	BD-008
EV-008	ME-009	BA-009	BD-009
EV-008	ME-009	BA-009	BD-001
EV-008	ME-009	BA-009	BD-002
EV-009	ME-010	BA-010	BD-009
EV-010	ME-012	BA-012	BD-011
EV-010	ME-012	BA-012	BD-010
EV-012	ME-005	BA-005	BD-005
EV-013	ME-013	BA-013	BD-001
EV-013	ME-013	BA-013	BD-008
EV-014	ME-014	BA-014	BD-003
EV-015	ME-015	BA-007	BD-007

Standards

• ST-001 SHA-256 secure hash (FIPS 180-4) — NIST FIPS 180-4 (Secure Hash Standard) : Integrity digests and content fingerprints across the product are computed with SHA-256 as specified in FIPS 180-4; no weaker digest is used where a tamper-evident binding is claimed..
• ST-002 JAR manifest SHA-256 digest attributes — JAR File Specification (manifest and signed-JAR digest attributes) : The build-time reference digest of each bundled helper scanner script is recorded as a SHA-256 attribute in the plugin JAR MANIFEST.MF and generated during the build, not hand-committed..
• ST-003 Java 21 platform baseline — Java SE 21 (Java Language and Virtual Machine Specifications) : The product builds and runs on Java 21 or later, enforced at Gradle configuration time, so the toolchain underpinning deterministic discovery and the quality gates is a fixed, known baseline..
• ST-004 SARIF 2.1.0 static-analysis result format — OASIS SARIF 2.1.0 (Static Analysis Results Interchange Format) : The SARIF output emitter conforms to SARIF 2.1.0; a change to the emitted structure is a versioned, documented change under the frozen-contract discipline..
• ST-005 CycloneDX 1.5 software bill of materials — OWASP/Ecma CycloneDX 1.5 SBOM specification : The build emits a CycloneDX 1.5 SBOM for the distributed artefacts; the SBOM schema version is pinned (VERSION_15) and changed only deliberately..
• ST-006 CVSS v3 vulnerability severity scoring — FIRST Common Vulnerability Scoring System v3 : Dependency vulnerabilities are scored with CVSS v3; the build fails when any runtime dependency carries a vulnerability scored 7.0 or above..
• ST-007 SPDX licence identifiers — SPDX Licence List (short-form identifiers) : Runtime-dependency licences are expressed as SPDX short-form identifiers and checked against the allowlist at config/allowed-licenses.json; a non-allowlisted licence fails the build..
• ST-008 CSV and YAML audit-schema formats — RFC 4180 (CSV) and YAML 1.1/1.2 specifications : The DeltaReport (CSV) and ClassificationOverride and overrides.yaml (YAML) audit-and-evidence artefacts use the standard CSV and YAML encodings with a declared schema version, so a breaking field change is a versioned, documented change..
• ST-009 Coordinated vulnerability disclosure and handling (ISO/IEC 29147 + 30111) — ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling) : The disclosure channel and internal handling process follow the external-reporting and triage/remediation practices described by ISO/IEC 29147 and 30111..
• ST-010 OpenPGP message and signature format — OpenPGP (RFC 4880) : The published vulnerability-reporting contact supports OpenPGP-encrypted e-mail so a reporter can transmit sensitive details confidentially..
• ST-011 SLSA build provenance (in-toto / Sigstore keyless) — SLSA provenance, in-toto attestation format, Sigstore keyless signing : Release artefacts carry an in-toto build-provenance attestation produced by keyless Sigstore signing (no managed keys), consistent with decision D-4 and the D-1 no-managed-key boundary..
• ST-012 OpenSSF Scorecard security health checks — OpenSSF Scorecard : The repository runs the OpenSSF Scorecard checks in CI so its security-health posture is measured against a recognised open-source baseline, consistent with decision D-4..

Roadmap

• RM-001 Prove cross-platform determinism on real CI runners — Line-ending-normalised hashing, portable path ordering and explicit newline emission are implemented and pass locally; the three-OS determinism workflow is defined but has not yet run on GitHub. → determinism.yml runs green on ubuntu-latest, windows-latest and macos-latest, with the leg-versus-leg comparison passing, so byte-for-byte cross-platform determinism is demonstrated, not just asserted.; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: A green determinism.yml run across all three OS legs with the compare job passing..
• RM-002 Establish an accuracy target and a maintained labelled set — The accuracy-evaluation capability exists (precision/recall/F1 per tag against a ground-truth label set), but no accuracy target is set and no maintained labelled set is owned, so classification accuracy is not actually measured. → An owner-set target precision/recall, a representative labelled set that is re-scored when the model, prompts or taxonomy change, and a CI accuracy gate.; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: A committed labelled set, a recorded target, and an accuracy run meeting it..
• RM-003 Prove Scorecard and provenance on GitHub — The OpenSSF Scorecard workflow and the keyless SLSA provenance step are added and parse, but neither has run on GitHub; the posture score and a verified attestation do not yet exist. → A first green Scorecard run publishing a score, and a release whose provenance verifies with gh attestation verify. Signed-Releases remains unmet by design (D-1).; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: A published Scorecard result and a successful gh attestation verify against a release asset..
• RM-004 Enforce the AuditWriter coverage bar with a class-level gate — DONE in 6.1.0. A class-level JaCoCo violationRule now enforces >= 0.95 LINE coverage on org.egothor.methodatlas.gui.service.AuditWriter (measured 97.4%), wired into check, so the build fails if the AuditWriter bar regresses. Previously only the gui-core module floor (75%) was enforced and the >= 95% class-level bar was an aspirational target. → A class-level JaCoCo rule enforcing >= 95% line coverage on AuditWriter, so the bar cannot silently regress — realised in 6.1.0 (measured 97.4%).; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: Realised — the class-level JaCoCo violationRule on AuditWriter (>= 0.95 LINE) is wired into check and fails the build below the bar; verified by the 6.1.0 green check run on JDK 27..
• RM-005 At-rest protection for the on-host audit artefacts — The .methodatlas/ evidence CSV and overrides YAML are hash-bound (tamper-evident) but have no at-rest access control; AuditWriter sets no restrictive file permissions. → Owner-only permissions (0600/0700 with a Windows ACL equivalent) on the .methodatlas/ artefacts, or a documented, accepted reliance on host controls.; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: Audit artefacts created with owner-only permissions, covered by a test, or a recorded owner decision to rely on host controls..
• RM-006 Schema-compatibility golden test for the audit contracts — DONE in 6.1.0. A new SchemaCompatibilityGoldenTest (methodatlas-emit) pins the names and order of the DeltaReport CSV columns and the ClassificationOverride YAML fields (and the CSV column set); any silent rename, reorder or removal of a column/field now fails the build. It does not type-check the ClassificationOverride YAML fields, so a silent retype of those override fields is not caught by the golden test on its own; the consumed DeltaReport CSV columns additionally go through a value round-trip, which does catch a retype on those columns. Previously the contracts rested on the version-bump-and-same-PR-docs convention (PL-001) and forward-compatible parsing with no automatic breaking-change detection. → A golden-file compatibility test that fails the build if a column/field is renamed, reordered or removed without a version bump (with retype of the consumed DeltaReport CSV columns caught via value round-trip) — realised in 6.1.0 as SchemaCompatibilityGoldenTest.; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: Realised — SchemaCompatibilityGoldenTest fails the build on any incompatible change to the DeltaReport columns or ClassificationOverride fields; verified by the 6.1.0 green check run..
• RM-007 Add a real Tier 1/2 zero-egress test — DONE in 6.1.0. A new ZeroEgressTest (root module) installs a recording java.net.ProxySelector on the worker's HttpClient and asserts ZERO non-loopback connections at the HTTP-client layer. The structural-scan and manual-prepare cases exercise the full path; the Tier-1 case is a self-validating loopback-sentinel client test. This is a real egress assertion at the HTTP-client (ProxySelector) layer (not a payload re-assertion), realised via SM-006. It does NOT observe raw sockets, DNS lookups or the Node TypeScript worker's own connections. The earlier gap — that the HttpSupport package-confinement ArchUnit rule only bounds which package may use HttpSupport and does not prove zero egress — is now closed, within that HTTP-client scope, by egress evidence. → An automated test asserting no non-loopback connection is opened under Tier 1 and Tier 2 — realised in 6.1.0 as ZeroEgressTest. On that evidence CO-012 moves to stated and EX-008 closes.; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: Realised — ZeroEgressTest demonstrates 0 non-loopback connections under a structural scan and the manual Tier-2 path, with a Tier-1 loopback sentinel; verified by the 6.1.0 green check run..
• RM-008 ABAP/COBOL comment-redaction support — ABAP and COBOL have no comment redactor because their grammars do not fully model all of their comment forms. The comment-redaction mechanism (SM-018) is therefore fail-closed on them: a run with -redact-comments aborts before sending when a to-be-redacted file is ABAP or COBOL. Until then, ABAP/COBOL sources cannot be submitted to a hosted provider under -redact-comments at all. → Extend the ABAP and COBOL grammars so their comment forms are fully recognised, then add CommentRedactor implementations for both languages so -redact-comments blanks their comments to spaces instead of aborting. On that evidence the fail-closed abort for ABAP/COBOL is replaced by real redaction.; owner the Architect and Programmer; target 2026-12-31; acceptance evidence: Redaction unit tests and grammar-regression tests pass for ABAP and COBOL, demonstrating their comments are fully recognised and blanked..