What is INTEGRITY.md?

INTEGRITY.md is a public, founder-authored markdown file at the root of an AI product’s repository or website that self-maps the product against The Integrity Framework. It addresses each of the six Layer 1 vetoes by name, names the product’s framework version, and is required for the Bronze tier in the directory at theintegrityframework.org.

Where should INTEGRITY.md live?

At the canonical product surface a buyer would find first. For open-source AI tools, that is the repo root next to README.md. For closed-source SaaS, that is the marketing site at /integrity.md or linked from the trust or security page. The file must be reachable without authentication.

Do I need to use Markdown?

Markdown is the conventional format and what the directory verifier expects. HTML or plaintext work if the headings and section labels match the template. The verifier reads the document structurally; format flexibility is OK as long as each Layer 1 veto is addressed under a clearly labeled section.

How long should INTEGRITY.md be?

Long enough to be honest about each veto, short enough to read in 10 minutes. TIF’s own INTEGRITY.md (for the directory itself) is roughly 100 lines of markdown. Listings on the directory range from 60 to 300 lines depending on how much disclosure the product surface area requires. Brevity that conceals trade-offs fails verification; verbosity that pads sections does too.

What if my product fails a veto?

Name the failure in the section, in plain language, with the trade-off you accept. The framework names “architectural honesty” as a passing condition for several vetoes — a disclosed failure beats a cosmetic pass. The directory will list a product with a disclosed failure at Bronze; it will reject a product that pretends to pass when it does not.

How does the directory verify INTEGRITY.md?

The Startvest team reads the file, checks the public artifacts it references (repo links, methodology page, integrity-cli output, etc.), and matches the self-mapping against the v1.0 spec at /framework/v1. Listings re-scan quarterly. A spec version bump triggers re-verification; a removed or hidden INTEGRITY.md downgrades or de-lists the product.

Is INTEGRITY.md a substitute for SOC 2?

No. SOC 2 is an audited control report for service organizations at enterprise spend levels. INTEGRITY.md is a self-mapped, publicly verifiable trust artifact for the sub-enterprise segment where SOC 2 is the wrong shape. Products that legitimately need SOC 2 should still pursue it. INTEGRITY.md addresses the segment SOC 2 prices out.

Can I fork the template?

Yes. The Integrity Framework spec is CC BY 4.0. The INTEGRITY.md template here is CC BY 4.0 as well. Fork for your own segment if the six Layer 1 vetoes do not fit your product shape; the directory at theintegrityframework.org indexes products that self-map against the canonical Startvest version.

Trust artifact \u00B7 CC BY 4.0

INTEGRITY.md

INTEGRITY.md is a public, founder-authored file at the root of an AI product\u2019s repository or website that self-maps the product against The Integrity Framework v1.0. It addresses each of the six Layer 1 vetoes by name, names the product\u2019s framework version, and is required for the Bronze tier in the directory at theintegrityframework.org. The format is plain Markdown. The license is CC BY 4.0. A worked example is the file at the root of this site\u2019s own repo.

The template

Copy this into INTEGRITY.md at your product\u2019s canonical surface (repo root for open source, marketing site for closed-source SaaS). Replace every angle-bracket placeholder. Do not delete sections \u2014 if a veto does not apply, name the trade-off in plain language.

INTEGRITY.mdDownload

# INTEGRITY.md — <Product name>

**Product:** <Product name> (<canonical-url>)
**Operator:** <Legal entity>
**Framework version evaluated against:** 1.0
**Self-evaluation tier:** Bronze | Silver
**Last updated:** YYYY-MM-DD

<One- or two-sentence honest description of what the product is and who it is for. The directory verifier reads this to confirm the product surface matches the rest of the file.>

---

## Layer 1 vetoes — self-mapping

### Veto 1 — Artifact versus outcome

**Pass | Fail with disclosed trade-off.**

<Explain whether the product sells the artifact (a certification, a badge, a report) or the outcome the artifact is supposed to indicate. Name any cases where the line is fuzzy. Disclosed fuzziness beats a cosmetic pass.>

### Veto 2 — Independence

**Pass | Pass with disclosed conflict | Fail with disclosed trade-off.**

<Disclose every relationship between the product, its operators, its listed customers, and any party that benefits from a favorable rating. Material conflicts must be named on the listing surface, not just here.>

### Veto 3 — Verifiability

**Pass | Fail with disclosed trade-off.**

<List the artifacts a third-party reader can verify mechanically: public repo, changelog with versioned methodology page, integrity-cli output, signed receipts, anything else. Anything not externally verifiable should be marked as such.>

### Veto 4 — AI accountability

**Pass | Fail with disclosed trade-off.**

<Describe what the product does and does not do with AI. Where AI generates artifacts (text, decisions, recommendations) the failure mode is hidden generation; pass requires labeling, audit trail, or a human-in-the-loop pattern surfaced to the buyer.>

### Veto 5 — Pricing-rigor alignment

**Pass | Fail with disclosed trade-off.**

<State whether the product’s pricing matches the rigor of the artifact it sells. Enterprise pricing on a self-attested artifact is a fail. Free or sub-enterprise pricing on artifacts that imply enterprise rigor is also a fail. Mismatch should be named.>

### Veto 6 — The TechCrunch test

**Pass | Fail with disclosed trade-off.**

<Imagine the headline if your worst failure mode were reported publicly tomorrow. If a journalist would describe the product as misleading, deceptive, or theatrical based on this INTEGRITY.md, it does not pass.>

---

## Layer 2 constraints (Silver tier only)

<Bronze listings can omit Layer 2. Silver listings address each of the seven architectural constraints in the v1.0 spec, briefly, with a link to the public artifact that demonstrates conformance.>

---

## Layer 3 guardrails (Silver tier only)

<Bronze listings can omit Layer 3. Silver listings address each of the seven operational guardrails in the v1.0 spec, briefly, with a link to the public artifact.>

---

## Changelog

- YYYY-MM-DD — Initial publication against v1.0.

---

*Published under CC BY 4.0. The Integrity Framework canonical spec is at https://theintegrityframework.org/framework/v1.*

Worked example

The Integrity Framework Directory is itself a product, evaluated against the framework it publishes. Its INTEGRITY.md is the canonical worked example. It is written from the operator\u2019s point of view, names a real conflict of interest under Veto 2, and discloses the path to lifting that conflict over time.

Read the directory\u2019s INTEGRITY.md on GitHub \u2192

Verification

When a listing is submitted, the directory verifier reads INTEGRITY.md and confirms:

The file is reachable at a stable, unauthenticated URL.
Each of the six Layer 1 vetoes is addressed under a clearly labeled section.
The product\u2019s framework version is named explicitly (e.g. 1.0).
The artifacts the file references (repo URLs, methodology pages, integrity-cli output) actually exist and resolve.
The self-mapping passes the TechCrunch test in Veto 6.

Silver listings additionally need either a passing integrity-cli run against the public repo, or a versioned public methodology page. A failing verification returns to the submitter with the specific veto or artifact at issue.

Common mistakes

Marking every veto Pass with no trade-off. Real products carry trade-offs. A spotless self-mapping is a TechCrunch-test fail by itself.
Linking artifacts that require auth. If a buyer cannot read the referenced doc without an NDA, the artifact does not count toward Verifiability.
Vague AI accountability copy.“We use AI responsibly” is not a pass. Name what the AI generates, what the audit trail is, and what the human checkpoint is.
Skipping Layer 2 / Layer 3 on a Silver submission. The directory cannot self-promote a listing past Bronze without those sections.
Forgetting to update on framework version bumps. If the spec moves to 1.1, the file must be re-mapped or downgraded to Bronze of the old spec version.

Frequently asked questions

What is INTEGRITY.md?: INTEGRITY.md is a public, founder-authored markdown file at the root of an AI product’s repository or website that self-maps the product against The Integrity Framework. It addresses each of the six Layer 1 vetoes by name, names the product’s framework version, and is required for the Bronze tier in the directory at theintegrityframework.org.
Where should INTEGRITY.md live?: At the canonical product surface a buyer would find first. For open-source AI tools, that is the repo root next to README.md. For closed-source SaaS, that is the marketing site at /integrity.md or linked from the trust or security page. The file must be reachable without authentication.
Do I need to use Markdown?: Markdown is the conventional format and what the directory verifier expects. HTML or plaintext work if the headings and section labels match the template. The verifier reads the document structurally; format flexibility is OK as long as each Layer 1 veto is addressed under a clearly labeled section.
How long should INTEGRITY.md be?: Long enough to be honest about each veto, short enough to read in 10 minutes. TIF’s own INTEGRITY.md (for the directory itself) is roughly 100 lines of markdown. Listings on the directory range from 60 to 300 lines depending on how much disclosure the product surface area requires. Brevity that conceals trade-offs fails verification; verbosity that pads sections does too.
What if my product fails a veto?: Name the failure in the section, in plain language, with the trade-off you accept. The framework names “architectural honesty” as a passing condition for several vetoes — a disclosed failure beats a cosmetic pass. The directory will list a product with a disclosed failure at Bronze; it will reject a product that pretends to pass when it does not.
How does the directory verify INTEGRITY.md?: The Startvest team reads the file, checks the public artifacts it references (repo links, methodology page, integrity-cli output, etc.), and matches the self-mapping against the v1.0 spec at /framework/v1. Listings re-scan quarterly. A spec version bump triggers re-verification; a removed or hidden INTEGRITY.md downgrades or de-lists the product.
Is INTEGRITY.md a substitute for SOC 2?: No. SOC 2 is an audited control report for service organizations at enterprise spend levels. INTEGRITY.md is a self-mapped, publicly verifiable trust artifact for the sub-enterprise segment where SOC 2 is the wrong shape. Products that legitimately need SOC 2 should still pursue it. INTEGRITY.md addresses the segment SOC 2 prices out.
Can I fork the template?: Yes. The Integrity Framework spec is CC BY 4.0. The INTEGRITY.md template here is CC BY 4.0 as well. Fork for your own segment if the six Layer 1 vetoes do not fit your product shape; the directory at theintegrityframework.org indexes products that self-map against the canonical Startvest version.

Read the framework spec Submit a listing Browse the directory