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

marketing-agent, the constraint-file pattern.

Sixth internal audit under The Integrity Framework v1.0. marketing-agent is internal Startvest tooling, not a customer-facing product. Most TIF dimensions are correctly N/A. Layer 1 Veto 6 applies sharply, and the defense is a different shape than the framework's code-pattern CI rules: a single explicit constraint file with kill-switch discipline applied to itself.

Source documents are public: marketing-agent's INTEGRITY.md, audits/tif-compliance.md, and the load-bearing artifact constraints.md.

What was audited

marketing-agent is internal Startvest LLC tooling. A context-layered marketing execution agent: validation reports → drafts → review queue → Buffer (LinkedIn) or CMS API (SEO blog). The agent uses Anthropic SDK for drafting. All AI output is draft-only and gated through manual review before any external surface receives it.

The audit was scoped specifically to verify that marketing automation's adjacent failure modes — auto-posting, cold email, scraping, strategy capture by AI, false urgency framing, fabricated citations — are avoided. They are.

Headline result

~21 dimensions · Layer 1 vetoes (6) + Layer 2 constraints (~8 incl. 4 N/A) + Layer 3 guardrails (7 incl. 3 N/A)

Pass

Partial

Out-of-segment

N/A

The N/A count is high because marketing-agent is internal tooling: no customers, no compliance-evidence chain, no public methodology, no annual independent audit. The N/As are honest — most TIF rows genuinely don't apply.

Mechanical: 9 of 11 integrity-cli rules passed. Two CRITICAL fails are both substantively PASS via structural gates (Buffer queue + manual click); mechanical marker fields (reviewedBy, citation provenance) are tracked tickets.

The headline finding: constraints.md as Veto 6 defense

The interesting finding is not in the code. It is in a single repo-root file — constraints.md— with 29 numbered “does NOT” items.

Layer 1 Veto 6 (TechCrunch Test) is structured around prohibiting every marketing-automation failure mode that has historically ended badly. constraints.md addresses them item-by-item.

Failure mode

Auto-posting / volume-spam

Defense in constraints.md

Items 1-2: agent does NOT post anywhere directly. Items 20-23: no auto-DMs, no LinkedIn scraping, no Sales Nav API integration. Buffer is the single allowed queueing surface; manual click only.

Failure mode

Cold email

Defense in constraints.md

Items 4-5: no contact with named accounts; outreach drafts only; agent never has send credentials.

Failure mode

Spend manipulation

Defense in constraints.md

Item 6: no money spent. No ad changes. No subscription changes. No SaaS purchases.

Failure mode

Strategy capture by AI

Defense in constraints.md

Items 7-9: no positioning decisions, no category-naming, no replacing strategic input from named humans.

Failure mode

False urgency framing

Defense in constraints.md

Item 15: '2027 standard in 2026' line is internal compass only — banned in public copy until earned by 3rd-party adoption.

Failure mode

Manifesto over-promise

Defense in constraints.md

Item 16: framework long-form pieces are "reasoning piece" or "the why doc," never "manifesto."

Failure mode

Voice / banned-term drift

Defense in constraints.md

Item 14: no banned voice terms (no em dashes, no exclamation points, no emojis).

Failure mode

Fabricated citations

Defense in constraints.md

Items 12-13: every factual claim requires a verifiable citation. Hallucinated citations are a hard fail with logged lesson. The agent flags uncertainty rather than fabricating.

constraints.md closes with kill-switch discipline applied to itself:

Edits to this file require a dated note. Removals require Tom's explicit sign-off — the file should grow over time, not shrink.

The constraint set governs itself. That self-reference is the point.

Why this is filed as a watch-for, not a v1.10.0 codification

The constraint-file pattern may generalize. Layer 1 vetoes and Layer 3 guardrails that are policy / process surfaces (not code patterns) might be best authored as a constraint file with kill-switch discipline, rather than expressed as code-level CI rules. The framework's existing rules don't model this shape — they're all code-pattern checks.

But: no codification on a single instance. The discipline that produced six clean revisions in this audit cycle was that each revision was driven by at least one real product surfacing the gap. The constraint-file pattern has only one product example so far.

The pattern is being watched for in future audits — PRAPI when it ships, external adopters, quarterly cross-product re-audits. If it repeats, it'll be codified as an optional new check kind. If it doesn't, it stays a per-product extension pattern.

Open items at audit close

Two remediation tickets opened on the marketing-agent repo:

Layer 2 C2

Add reviewedBy / published_by_user_id marker to draft entity

Substantive PASS via Buffer queue + manual click. Mechanical CRIT-SV-AI-REVIEW-GATE rule needs the marker on the persisted draft.

Layer 2 C2

Add citation provenance fields to draft entity

constraints.md items 12-13 enforce citation discipline by process. Structured fields make the verification step auditable.

The smallest backlog in the portfolio. marketing-agent's substantive posture is strong; the open items are mechanical-marker fields that turn structural gates into machine-verifiable assertions.

What this teaches

Internal tooling can produce strong Layer 1 / Layer 3 framing without the framework's code-pattern CI rules. An explicit constraint file with kill-switch discipline is a different but legitimate shape.
Marketing automation specifically demands explicit anti-pattern enumeration. The category sits adjacent to too many failure modes (auto-posting, cold email, strategy capture, false urgency, fabricated citations) for implicit defense to suffice. Naming each one in writing is the discipline.
N/A is the correct answer when the rule was written for a different category. marketing-agent is correctly outside the customer-facing-compliance-product scope that most TIF rules are calibrated against. The audit doesn't manufacture gaps.

Reproducibility

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

Changelog

2026-04-29 — v1.0. Initial publication. No framework revision triggered (v1.9.0 held up cleanly). Constraint-file pattern documented for future watch-for.