A framework for building compliance products under structural commitments.

A working document. It governs how every Startvest product is designed, built, and operated. It's also published openly so other operators can fork it for their own compliance and trust-adjacent products. The framework's value is in adoption; locking it down would defeat the purpose.

The framework has three operational layers (vetoes, architectural constraints, operational guardrails) plus an eight-layer moat model used as decision criteria for product portfolio fit. Each is documented below with pointers to the runbooks, inspection templates, and trust reports that operationalize them.

If you fork this for your own product, the only request is that you keep the version-and-changelog discipline. A framework that drifts silently is the failure mode the framework defends against.

Five recurring failure modes have destroyed compliance and trust-adjacent categories before. The framework names them so they can be defended against by name.

1. Trust-arbitrage failure. Selling certification artifacts as the product instead of underlying outcomes. Volume-based business models destroy rigor over time.
2. Theater versus substance failure. Outputs that look like compliance but don't verify the underlying state. Checklists checked without verification, evidence collected without inspection.
3. Conflict-of-interest failure. Verifier paid by the verified entity, with no structural independence. The Andersen / Enron pattern.
4. Black-box AI failure. AI producing compliance outputs without humans understanding what was done, why, or whether it's correct. Unique to current-generation compliance work.
5. Velocity-over-rigor failure. Business pressure to ship audits or certifications faster than they can be done well. Speed claims become trust claims become fraud.

Recent industry collapses (Theranos, FTX, Delve, others) all map to one or more of these. The framework is reverse-engineered from those failures.

Six questions evaluated before a product gets built or before a major scope expansion. Wrong answer kills the product, not delays it.

1. Artifact versus outcome. Is the value proposition selling an artifact (report, badge, score) or an outcome (actual compliance, security, audit-readiness)? Outcome passes. Artifact fails.
2. Independence. Who pays us, and does that conflict with what we verify? Customer pays for tooling that helps them prepare for verification by genuinely independent third parties: pass. Customer pays us to both prepare AND certify: fail. Hard rule, not negotiable.
3. Verifiability. Can we mechanically verify what we claim, or are we relying on customer attestation alone? Mechanical: pass. Attestation as proof: fail.
4. AI accountability. When AI gets it wrong, what's the human review layer and escalation path? AI outputs pass through documented review gates before becoming attestations: pass. AI directly to customer-facing claim: fail.
5. Pricing-rigor alignment. Does our pricing model create financial pressure to skip work? Pricing tied to actual work performed: pass. “Unlimited audits for $X/year”: fail.
6. The TechCrunch test. Imagine the worst-case headline about this product in 18 months. Can we defend every claim, methodology, and output? Defense is concrete and survives scrutiny: pass. Defense requires hand-waving: fail.

A product failing any veto either gets reframed before build OR gets passed on. The framework is more important than any single revenue line.

Seven constraints baked into every product, CI-enforced where possible.

1. Evidence chain integrity. Every compliance claim traceable to specific evidence the product collected and timestamped.
2. AI output review gates. Any AI-generated compliance output passes through human review before becoming an attestation, report, or customer-facing claim.
3. Customer self-attestation isolation. Customer-attested data visually and architecturally distinct from product-verified data.
4. Reproducibility. Every audit conclusion reproducible from underlying evidence by an independent reviewer. Internal review gates test reproducibility quarterly.
5. Evidence retention independence. Evidence supporting compliance claims retained per statutory requirements regardless of normal data lifecycle. Customer offboarding does NOT delete audit evidence.
6. Independent verification hooks. Every compliance product has a mode where an external auditor can verify product outputs without the product mediating.
7. Failure transparency. When the product can't verify something, it MUST say so. Never silently default to “compliant” when verification fails.

CI rules enforce these where the codebase shape allows. Evidence-chain integrity becomes a non-null foreign key. AI output review gates become required schema fields. Failure transparency becomes a forbidden-pattern check that blocks catch { return verified: true } regressions.

Seven business practices that prevent the model from turning sour over time.

1. Refund-on-failure. Every customer contract includes a refund clause if our certification or verification turns out wrong because of our error or oversight.
2. Public methodology documentation. Every product publishes the methodology by which it produces compliance outputs. Not the source code, the methodology.
3. Annual independent audit of our own product. Once per year, every Startvest compliance product reviewed by a real third-party CPA firm or security firm. They sample our outputs. We publish findings, whatever they find.
4. Customer-side compliance owner. Before selling to a company, identify who there is responsible for the compliance outcome. We don't sell to companies where compliance is “operations' problem.”
5. Internal whistleblower channel. Anonymous reporting channel monitored by independent counsel. Quarterly board-level review.
6. Community accountability pattern. Free tier or pack offered to a high-trust community that watches our work. Community will notice fakery.
7. Public kill criteria. Every compliance product publishes the criteria under which we'd shut it down. Inverse of growth-at-all-costs.

Operating decision criteria used when evaluating new products to commit engineering capacity to. The moat model and the integrity framework are complementary: the framework keeps us from shipping things that shouldn't ship; the moat model picks among the things that should.

A single-layer moat is a feature, not a moat. Wendy's matched McDonald's McFlurry with the Frosty Fusion and McDonald's lost the entire matchup because dessert was their only differentiator. Yahoo had directory; Google had better search; Yahoo died. BlackBerry had keyboard; iPhone matched it eventually; BlackBerry died. Single-feature moats are death traps in slow motion.

Real moats are stacked. A competitor has to defeat multiple layers simultaneously to break in.

Six yes/no questions. Score any compliance or trust-adjacent vendor (including products operating under this framework) against them. One point per yes. Score below 5 is information.

Each row maps to a Layer 1 veto, a Layer 2 constraint, or a Layer 3 guardrail. A vendor that ducks any row is operating outside the framework whether they claim it or not.

Run the scorecard on this product before trusting the framework. We score 6/6 only when the operationalizing artifacts (methodology, audit, INTEGRITY.md, kill criteria) are all live and linkable. Until they are, the score is partial. We say so on Trust Principles and on each per-product INTEGRITY.md.

The framework is worthless if the operators who publish it don't score themselves against it. These are the current self-grades for the three Startvest products operating under v1.0, captured the day the framework published.

Baseline published at 2 / 6 and 3 / 6 the day v1.0 shipped. Now at 4 / 6 across all three products. Closing the remaining gaps in public.

Each per-product INTEGRITY.md names the gaps with file paths and target close dates. The methodology and kill-criteria rows already moved YES. The MSA refund clause is drafted and pending finalization.

Row 3 (annual third-party audit) is honestly classified. The audit is required for the row to move YES, and the engagement cost is gated on external funding that Startvest does not currently have. We are not relabeling this as “in flight” or “scheduled” while the funding does not exist; the row stays NO with this disclosure attached. When funding is secured, the row moves to PARTIAL with the audit firm name and engagement date public. It moves to YES only when an audit cycle completes and the findings publish.

Hold us to this. If a score drops without a paired changelog entry on the framework page or the per-product INTEGRITY.md, that is the failure pattern itself.

Citation-stable URLs. The latest revision lives at claritylift.ai/framework. Frozen versions live at claritylift.ai/framework/v1, /v2, etc. Cite the frozen URL when the wording matters; cite the latest URL when the principle matters.

If you operate a product under the framework, link the frozen version you're operating against. When you upgrade, bump the link in your INTEGRITY.md and note the upgrade in your changelog. Silent drift is the failure mode the framework defends against.

Real, named compliance failures walked through the failure modes and the vendor scorecard. Sourced citations only; we're not investigating, we're mapping public reporting to the framework so the failure modes stay concrete instead of abstract.

Have a case we should write up? Email integrity@startvest.ai.