Principle
Creator-owned relationship
Subscribers join a specific creator, not a generic Seamline marketing list. The list belongs to the creator — not to us.
Trust infrastructure
Audience trust is a product feature.
Seamline helps creators build a direct thread with their audience. That only works if visitors know what they are joining, who will email them, and where their data will not go.
Boundary promise
Creator content can power AI. Subscriber identity cannot.
This is enforced as a product design rule, not a marketing footnote.
Core principles
Principle
No subscriber PII in AI
Lead emails, names, and subscriber-identifying data stay out of model prompts. Only creator-authored project descriptions go to Claude.
Principle
Clear unsubscribe expectation
Capture surfaces and email flows must keep exit paths visible and honest. No buried opt-outs, no dark-pattern re-subscriptions.
Principle
No dark-pattern capture
Seamline optimizes for trust and clarity — not pressure mechanics, fake urgency, or hidden consent. We build trust infrastructure.
Data boundaries
Exactly what goes where.
Used for creator intelligence
- Project descriptions
- Creator-approved voice settings
- Aggregate capture counts
- Aggregate source quality
- Creator feedback on generated copy
Never sent to AI
- Lead email addresses
- Lead names
- Raw subscriber identity
- Private payment data
- Unapproved subscriber preference text
Used only after explicit setup
- Email dispatch via verified sender domain
- Stripe billing events
- Custom-domain routing
- Durable preference storage
Executable guardrails
Trust promises should fail closed.
Prompt boundary scanner
Build checks block subscriber identifiers, raw lead rows, and unsafe policy metadata from artificial intelligence (AI) prompt surfaces.
scripts/check-privacy-boundaries.mjs
Server-side tier gates
Quota and plan claims are checked in API routes from server-owned records. Client-side tier claims are never trusted.
lib/tiers.ts + authenticated API routes
Activation proof receipts
First-thread milestones write aggregate proof receipts without storing subscriber identity in the public progress ledger.
activation_proof_ledger
Published proof snapshot
Evidence is public, redacted, source-bound, and founder-gated.
The compiled snapshot is generated from committed proof artifacts only. It never includes subscriber personally identifiable information, secrets, or live billing actions. Current runtime source local/unattested is attested independently from the historical release receipt.
Rollup status
12/14
needs-attention
Generated Aug 13, 2026
Latest verified release receipt
pass
Receipt worker e04418e0-d942-48a3-85b9-e553059e7465
Verified commit 1c355053 · runtime source local/unattested · health pass · live proof pass
Generated Aug 12, 2026
First-thread proof
pass
Sequence dispatch proof
pass (stale)
Webhook replay proof
pass
Notification lifecycle proof
pass
Remote production proof
pass
Direct deploy receipt
pass
Live performance proof
pass
Local DB proof
pass
Worker heat-map regression guard
warn
OpenNext proxy canary
blocked-on-opennext-adapter (stale)
Release gate evidence
fail
Contact reachability proof
mailbox-proof-needed
Responsive readiness proof
pass
Doctor snapshot
pass
Refresh Sequence dispatch proof while it is stale: artifacts/sequence-dispatch-proof-latest.json · no-send · 5 payloads · unsubscribe+attribution proven · 2026-08-03T23:23:52.487Z · freshness stale (9d old)
Subscriber promise
What a visitor should understand before joining.
They are joining a creator-specific relationship, not a platform newsletter.
The creator controls the message and the list relationship; Seamline supplies infrastructure and measurement.
Preference signals are optional, consented, and aggregate-first — they help the creator improve the thread without turning the subscriber into a data product.