Audit Methodology

Provifact is an evidence-production system, not an auditor and not a certification authority. Its methodology makes provenance, calculation, exception, and interpretation boundaries explicit.

Evidence chain

1. Intent — identify the reviewed desired state and its Git commit.
2. Approval — retain pull-request review and the human decision.
3. Observation — collect source state through a documented read-only provider.
4. Normalization — map provider objects to a versioned vendor-neutral schema.
5. Evaluation — compare desired and observed values deterministically.
6. Fingerprint — hash the canonical inputs and algorithm version.
7. Mapping — associate a finding with a separately reviewed control mapping.
8. Exception — capture owner, rationale, approval, scope, and expiry where applicable.
9. Sanitization — create a public-safe derivative only when publication is intended.
10. Narrative — optionally generate labeled analysis grounded in evidence references.
11. Acceptance — require a human to approve the package and any conclusions.

Evidence classes

Class	Generated by	Authority
Desired configuration	Reviewed repository content	Approved intent
Observed configuration	Read-only provider adapter	Source observation at collection time
Drift finding	Deterministic engine	Reproducible calculation
Exception	Human workflow	Time-bounded risk decision
Compliance mapping	Reviewed mapping content	Interpretation, not certification
Narrative	Optional GPT-5.6 or offline fixture analysis	Non-authoritative explanation
Verification	Exact coverage and typed-claim verifier	Machine-checkable claims only; prose quarantined

Reproducibility

The same normalized desired and observed values, control reference, subject reference, provider, platform, and algorithm version produce the same fingerprint. A new algorithm version must not silently reuse the previous version's identity.

Mapping discipline

Provifact will link evidence to control statements without copying restricted standards text or claiming requirements not established by authoritative sources. A mapping records its source, version, reviewer, rationale, and known ambiguity. Passing a technical check does not by itself prove organizational compliance.

The Build Week demo pins the complete 98-rule macOS CIS Level 1 inventory from one mSCP revision. Only four rules currently have reviewed exact mappings from approved baseline metadata to Intune provider definitions. A fifth desired rule is explicitly marked mapping-not-reviewed; all other rules have no provider mapping. Their CIS, STIG, NIST SP 800-171, NIST SP 800-53, and CMMC identifiers are copied from the pinned source and tested; GPT does not create crosswalks. Unsupported rules remain visible and outside the score denominator. iOS/iPadOS has no approved baseline in this repository and is not scored against the macOS inventory.

Drift and severity methodology

Stable matching uses explicit rule mappings, payload/setting keys, safe normalized metadata, and reviewed aliases—not display names alone. The algorithm first detects missing observations and conflicting values, then evaluates exact or typed maximum values, and finally checks normalized assignment presence. An invalid or incomparable numeric value becomes human review, not a match.

Severity is baseline-mapping metadata, not model judgment. The demo marks encryption and firewall drift high, firewall stealth and password enforcement medium, and idle-timeout drift low. Severity prioritizes technical review; it does not estimate business risk, accept risk, or establish a compliance verdict. Every drift finding continues to require additional evidence and human review.

Evidence history

The smallest demo history mechanism is a pair of sanitized, fingerprinted snapshots embedded in the generated Mission package. It reports score change, changed requirements, new drift, resolved drift, and endpoint gaps. No Cloudflare database or raw tenant history was added. A future operational history store must accept sanitized packages only and receive its own retention and access-control review.

Narrative discipline

Generated analysis must:

• identify itself as generated;
• cite deterministic evidence references;
• distinguish fact, inference, limitation, and recommendation;
• avoid asserting remediation, approval, or certification;
• preserve contradictory or incomplete evidence; and
• remain reviewable by a human before use.

Phase 1 implements this contract with strict structured output and then treats the result as untrusted. The verifier requires unique, exact finding-ID coverage and accepts only the closed finding_status claim code when its typed value equals deterministic evidence. It also checks evidence references, unsupported framework/verdict language, required limitations, and human-review wording. Every unrestricted prose field is quarantined rather than semantically trusted. Human review remains required and is not a certification, exception, or risk-acceptance decision.