The Integrity Framework

Case study · v1.0 · published 2026-04-29

adacompliancedocs, the validation-gate axis.

Fifth internal audit under The Integrity Framework v1.0. ADAComplianceDocs introduced a structurally new Layer 2 shape: customer-attested status that cannot publish until a system-verified gate passes. The third C3 axis, codified in v1.9.0.

Source documents are public: adacompliancedocs' INTEGRITY.md and audits/tif-compliance.md.

What was audited

adacompliancedocs is a Startvest LLC product. ADA / WCAG compliance documentationtooling — not certifications. Court-ready good-faith effort record. Customer-published statements; customer-resolved audits. The platform never sells “your site is compliant.” Built on the inverse premise of overlay-vendor failures (accessiBe et al.).

ADA / WCAG is the most failure-prone trust category in the framework's design. That category pressure is also why ADAComplianceDocs has the strongest Layer 1 framing in the portfolio.

Headline result

20 dimensions · Layer 1 vetoes (6) + Layer 2 constraints (7) + Layer 3 guardrails (7)

14

Pass

5

Partial / Needs update

1

Out-of-segment

0

Fail

Mechanical: 14/14 integrity-cli rules passed after corrections (5 base-id collision renames, Outstanding Risks ticket-ref backfill, Recent Changes sidecar assertions for high-value claims). The most consequential structural element in the entire portfolio's compliance posture — the conformance-claim guard at src/lib/statements.ts — is mechanically validated.

The headline finding: customer-attestation-validation-gate

ADAComplianceDocs introduced a structurally new Layer 2 shape the framework hadn't previously modeled. The product's most consequential CI rule (CRIT-AD-CONFORMANCE-CLAIM-GUARD) blocks Platform_Statements.conformanceStatus = 'full' publishes when critical or serious axe-core findings remain open. Override permitted via an explicit acknowledgeOpenFindings=true parameter, but audit-logged.

Customer-attested status. But the publish path must reference a system-verified validation gate before it can persist.

This is structurally distinct from the existing two C3 axes:

v1.4.0

Output-attestation provenance

Says

this customer-facing attestation references customer-submitted evidence

Example

FieldLedger's RateSnapshotJson on persisted rate letters

v1.8.0

Input-data provenance

Says

this data is labeled as customer-attested vs system-derived

Example

Hireposture's customer_attested enum on Hireposture_AuditFindings.source

v1.9.0 (this audit)

Customer-attestation validation gate

Says

this customer-attested data cannot publish until system-verified evidence supports it

Example

adacompliancedocs's checkConformanceGuard at src/lib/statements.ts

Provenance markers say where customer-attested data came from. Validation gates say when it may publish. Different verbs, different runtime semantics. The principle is genuinely new, not a calibration of v1.8.0.

Framework revision: v1.9.0

Added CRIT-SV-CUSTOMER-ATTESTATION-VALIDATION-GATE to the base manifest. Co-occurrence rule:

  • Trigger. Persisted entity carrying a customer-attested status field — conformanceStatus, complianceStatus, attestationStatus, certificationStatus, wcagConformance, etc., declared on a Statement / Conformance / ComplianceClaim entity.
  • Required. A validation-gate function pattern (checkConformance, conformanceGuard, validateBeforePublish, acknowledgeOpenFindings, ConformanceGuardBlockedError, etc.) anywhere in the corpus.
  • Vacuous-passwhen no trigger fires. Most products don't have customer-attestation publish flows. Only compliance-category products activate this rule.

Validated backwards-compatible against FL/CL/IL/HP: no trigger fires (none of them have customer-attested status fields). ADA: trigger fires + gate present + passes. Trigger pattern was tightened during validation when an FL Zod schema definition (certificationStatus = z.enum(...)) accidentally activated the rule despite FL having no customer-attestation flow. Calibration-fragility lesson: the trigger pattern list will need ongoing widening as future audits surface edge cases.

Open items at audit close

Seven remediation tickets opened on the adacompliancedocs repo:

P0
Layer 3 G1

Finalize MSA refund-on-failure clause and roll into standard template

Same shape as FL/CL/HP P0. Counsel-blocked.

P1
Layer 2 C3

UI badging for customer-attested vs system-verified

Schema-layer isolation passes. The conformance guard ships. UI-layer visual distinction is the remaining gap.

P1
Layer 2 C5

Statutory retention floor for audit/remediation evidence

Currently soft-delete + 30-day post-cancellation. No N-year retention floor for audit-trail records that a court inquiry might reach.

P1
Layer 2 C6

auditor_readonly role for external accessibility consultants / counsel

DSAR export covers self-export. External CPA / counsel needs scoped read-only mode.

P1 (shared)
Layer 3 G5

integrity@startvest.ai mailbox + external counsel SLA

Same shared resolution as FL/CL/IL/HP.

P2
Layer 3 G6

Engage accountability community

Disability rights advocates, accessibility consultants, plaintiff attorneys representing accessibility complainants.

P2
CLI rule hygiene

Rename CRIT-SV-CONFORMANCE-CLAIM-GUARD → CRIT-AD-CONFORMANCE-CLAIM-GUARD

Per CRIT-SV-NO-BASE-ID-OVERRIDE, the SV namespace is reserved for the base manifest. The rule was renamed during this audit; ticket closes the change.

What this teaches

  1. Layer 2 Constraint 3 has at least three distinct axes. Provenance (where data came from), provenance (whether data is labeled customer-attested), and validation gate (whether customer-attested data may publish when system-verified evidence is missing). All three serve the same goal of keeping customer-attested data isolated from system-derived. They operate at different layers with different runtime semantics.
  2. Promotions to base happen only when a per-product rule reflects a portable principle. The conformance-claim guard had been a per-product rule on adacompliancedocs. Promoting it to base required confirming the principle generalizes (a customer-attested status field SHOULD have a publish-time validation gate, not just on this one product).
  3. Trigger calibration is fragile and ongoing. The first-cut v1.9.0 trigger pattern false-positived on FL's Zod schema definition. The fix tightened to require Zod-object-field syntax. Future products will surface more edge cases. Calibration is iterative — that is how the framework evolves under reality, not a sign of brittleness.

Reproducibility

# from a clone of the integrity-cli repo
node bin/integrity.mjs check ../adacompliancedocs --format=json \
  > ../adacompliancedocs/audits/tif-compliance.cli-output.json

Changelog

  • 2026-04-29 — v1.0. Initial publication. Drove base manifest v1.9.0 — third C3 axis added (CRIT-SV-CUSTOMER-ATTESTATION-VALIDATION-GATE).

Related