CLCKBL — Owner's Manual & Strategic Intelligence File

Canonical source of truth for the CLCKBL project. Change Order 001 applied: the detection path is now fully deterministic — zero external inference calls. Same code runs in the browser and on the server.

Third-party romance-scam detection. Forensic pipeline that fuses pattern, linguistic, temporal, and network signals — fully deterministic, zero external inference into an auditable verdict.

Author / Owner: Kenneth E. Sweet Jr. — Solo Founder, Infrastructure Architect Contact: PromptFluid@gmail.com · KESJR.com · Abilene, Texas 79605 Document Version: 2.1 · Generated 2026-07-05 · Change Order 001 applied (AI lane removed, enum drift resolved) Repository codename (internal): tanstack_start_ts (package.json) Public product name: CLCKBL Published URL: https://clckbl.com Repository status: Prototype / Pre-launch (Observed in code)

Truthfulness Legend

Every non-trivial claim in this document carries a status tag:

• Confirmed — verified against code, migration, or config in this repo
• Observed — visible in source, dev preview, or dependency manifest
• Inferred — reasonable interpretation of code intent
• Planned — present as scaffolding, TODO, or roadmap note
• Speculative — strategic hypothesis, not built
• Unknown — needs creator confirmation

If a tag is absent, treat the statement as Observed or Confirmed (structural facts from the codebase).

Table of Contents

1. Executive Summary
2. Canonical Identity
3. Project Classification
4. Core Concept
5. Full Feature Inventory
6. Architecture Analysis
7. Strategic Ecosystem Role
8. Development History
9. Current State Assessment
10. Monetization Analysis
11. Competitive Positioning
12. Future Vision
13. Priority Roadmap
14. Risk Analysis
15. Preservation & Continuity
16. Strategic Importance Ranking
17. Recommended Next Actions
18. Canonical Summary

1. Executive Summary

What it is (Confirmed). CLCKBL is a web application that lets a third party — a friend, adult child, sibling, or trusted advisor — paste a suspect romantic conversation and receive a forensic verdict. The verdict is produced by a multi-lane detection pipeline and rendered with citations back to the exact messages that raised each signal.

Why it exists (Inferred). Romance-scam victims almost never self-report while under active grooming. The people around them see the signs first and lack a defensible way to communicate what they see. CLCKBL is built to give that outside observer evidence — not an opinion — that can be handed back to the person being targeted.

Problem solved (Confirmed by product surface). Turns ambiguous "I have a bad feeling" into a citable, tamper-evident report: risk grade, top signals, exact message citations, and a SHA-256 chained audit trail.

Current maturity (Observed). Working end-to-end prototype. Auth, scan pipeline, cases, audit chain, share links, live guard, identity verification, and signed PDF export are all implemented and pass their unit tests. Not yet launched, not monetized, no known active users beyond the creator.

Strategic importance (Inferred). Occupies a defensible niche: third-party forensic tooling for interpersonal fraud. Most anti-scam tools target either (a) the platform (Tinder, Meta) or (b) the victim. Almost no consumer-grade product targets the concerned outsider. Combined with a citation-backed, auditable output format, CLCKBL is positioned somewhere between a consumer utility and a paralegal-grade evidence pack.

Short-term opportunity (Speculative). Ship a public beta targeted at adult children of aging parents (the most acute pain segment). Free tier for standalone scans, paid tier for case files, share links, and PDF exports.

Long-term vision (Speculative). A defensible reference platform for interpersonal-fraud forensics — extending from romance scams to pig-butchering (already scaffolded), sextortion (already scaffolded), rental fraud, elder-care fraud, and identity impersonation of family members via generative video.

2. Canonical Identity

Branding personality (Observed). Dark, technical, forensic. Monospace mono-tags, panel-grid backgrounds, signal-amber accents on near-black background. Deliberately un-consumery — reads like an internal instrumentation console rather than a lifestyle app. This is a deliberate positioning choice: the tone signals evidence, not dating advice.

3. Project Classification

Primary: Consumer SaaS (single-tenant per user) with a forensic/evidence-grade output layer.

Secondary classifications:

• Detection engine — pure-TS Bayesian classifier as a reusable core (src/detection-core/)
• Case-management platform — owner-scoped cases, claims, scans, audit chain
• Verification workflow — challenge-response identity verification with signed audit
• Evidence export tool — PDF report generation via pdf-lib
• Real-time monitoring — Live Guard rolling transcript watcher

What it is NOT:

• Not a dating app
• Not a background-check service (no PII lookups)
• Not a legal service
• Not a therapy or advice product
• Not an anti-fraud plugin for dating platforms

4. Core Concept

The idea

Take a conversation. Return a verdict. Cite the evidence. Chain it into an audit log. Give the third-party observer something they can hand to the person being targeted that survives the "why don't you trust me" pushback.

Unique innovation

Five distinct innovations, in composition:

1. Third-party framing. The subject is not the user. The user is scanning on behalf of someone else. Every UX affordance — subject alias, "hand it to them", non-contact policy — enforces this posture.
2. Multi-lane Bayesian fusion. Five deterministic rules lanes (pattern packs, linguistic, temporal, network, plus the financial-category signals fused across them) each emit signals with log-likelihood-ratio strengths; a naive-Bayes fusion with clamping produces a calibrated posterior. See src/detection-core/fusion.ts.
3. Citation-backed signals. Every signal points to the exact message indices that raised it. Hover-to-highlight in the UI, msg #N in exports.
4. SHA-256 audit chain. Every case event (scan, claim, verification outcome, guard alert) is chained: hash = sha256(prev_hash || '|' || event_type || '|' || case_id || '|' || timestamp || '|' || payload) (pipe-delimited; matches append_audit_event in migrations). Implemented as a Postgres SECURITY DEFINER function with per-case advisory-lock (append_audit_event). Tamper-evident by construction.
5. Live Guard rolling monitor. Paste-as-you-go rolling transcript; diffs newly raised signals against tracked set; emits guard.alert events. Includes a bounded-growth rebaseline (MAX_THREAD_CHARS = 120_000) to prevent unbounded storage.

Why it is difficult to replicate

• Detection craft — Pattern packs (romance-scams.ts 331 LOC, sextortion.ts 165 LOC, crypto-romance.ts 187 LOC) encode observed scam scripts. Building these requires deliberate corpus work.
• Calibration — Prior of 0.08, per-signal LLR clamp of ±3.5, positive-total cap 9, negative cap −5, confidence-downgrade rule (gradeFromPosterior). Tuning these is craft, not code.
• Evidence-grade output format — Citation bubbles + audit chain + signed PDF is a full-stack commitment, not a single feature.
• Third-party positioning — The framing itself is the moat; competitors chasing "help me trust my match" are targeting a different (and lower-intent) user.

Strategic moats

5. Full Feature Inventory

5.1 Detection Core (src/detection-core/) — Confirmed

Pure TypeScript, no I/O. Reusable in browser and server.

Pipeline version: clckbl-detect-1.2.0 (embedded in every verdict). Bumped from 1.1.0 in Change Order 001 when the AI reasoning lane was deleted and the pipeline became fully deterministic.

5.2 Routes (src/routes/) — Confirmed

Public:

• / — landing with rolling live-demo (landing-live-demo.tsx) that streams a fixture line-by-line and runs the client pattern lane
• /scan — anonymous pre-scan workbench; sign-in required for full pipeline
• /onboarding — three-step explainer (paste → verify → hand it to them)
• /auth — sign-in / sign-up
• /report/$shareToken — public read of a shared verdict (14-day TTL by default)
• /status — service status
• /privacy, /terms, /safety — legal + safety guidance
• /sitemap.xml — server route
• /api/* — reserved for public API endpoints (none exposed yet)

Authenticated (/_authenticated/*):

• /cases — list of user's cases
• /cases/$caseId — case detail: metrics, scans, claims, verification, live guard, audit chain, PDF export
• /account — profile / preferences

5.3 Server Functions (src/lib/*.functions.ts) — Confirmed

All use TanStack Start createServerFn with requireSupabaseAuth middleware unless noted.

5.4 Components (src/components/) — Confirmed

• landing-live-demo.tsx — the rolling client-side pattern-lane demo on /
• scan-workbench.tsx (449 LOC) — the main scanning surface
• conversation-view.tsx — parsed-message renderer with citation hover-linking
• verification-panel.tsx (316 LOC) — challenge issue / upload / review
• live-guard-panel.tsx (110 LOC) — rolling-monitor UI
• export-report-button.tsx — PDF export trigger
• page-shell.tsx, site-header.tsx, site-footer.tsx — chrome
• ui/* — shadcn primitives

5.5 Database (Supabase, public schema) — Confirmed

Enums: plan_tier, case_status, risk_grade, claim_category, claim_source, platform_met, signal_source, pattern_report_type.

RPC: append_audit_event(case_id, event_type, payload) — the only path that writes to audit_chain. Uses pg_advisory_xact_lock per case to serialize chain writes, then computes sha256(prev_hash || '|' || event_type || '|' || case_id::text || '|' || now::text || '|' || payload::text).

Storage buckets: evidence-uploads (private), verification-videos (private).

Secrets configured: SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_SERVICE_ROLE_KEY, SUPABASE_DB_URL. LOVABLE_API_KEY is no longer required by the detection path after Change Order 001.

5.7 Testing — Confirmed

vitest with 10 total specs (5 in sanitize.test.ts, 5 in pipeline.test.ts). Covers determinism of the sanitiser and grading behaviour of the fusion layer. No integration tests against Supabase, no E2E / Playwright suite yet (Planned).

6. Architecture Analysis

6.1 High-level topology

                        ┌───────────────────────────────────────┐
                        │           Browser (React 19)          │
                        │                                       │
                        │  ┌──────────────┐  ┌───────────────┐  │
                        │  │  Landing     │  │  Scan         │  │
                        │  │  live-demo   │  │  Workbench    │  │
                        │  │ (pattern)    │  │ (full UI)     │  │
                        │  └──────┬───────┘  └───────┬───────┘  │
                        │         │                  │          │
                        │         ▼                  ▼          │
                        │  ┌───────────────────────────────┐    │
                        │  │  detection-core (isomorphic)  │    │
                        │  │  runPreScan() — client-safe   │    │
                        │  └───────────────────────────────┘    │
                        └─────────────────┬─────────────────────┘
                                          │  useServerFn (bearer attached)
                                          ▼
             ┌───────────────────────────────────────────────────────┐
             │       TanStack Start server functions (Worker)        │
             │                                                       │
             │   scan · cases · verification · guard · report · share│
             │            │                                          │
             │            ▼                                          │
             │  detection-core/runFullPipeline(input) — pure, no I/O│
             │            │                                          │
             │            ▼                                          │
             │  five deterministic lanes (pattern ×3, linguistic,    │
             │  temporal, network) — zero external inference calls   │
             │            │                                          │
             │            ▼                                          │
             │       Supabase (Postgres + Storage + Auth + Realtime) │
             └───────────────────────────────────────────────────────┘

6.2 Execution flow — a full scan

User pastes conversation
      │
      ▼
scan-workbench renders live pre-scan (client, pattern-lane only)
      │
      ▼  (Click "Run full server scan")
scanConversation({ raw, subjectAlias, caseId? })
      │
      ├─► requireSupabaseAuth  → context.supabase, userId
      ├─► quota check (profiles.plan_tier + monthly count)
      ├─► sanitizeConversation(raw)  → messages[]
      ├─► parallel rules lanes: pattern × 3, linguistic, temporal, network
      ├─► fuseSignals()  → posteriorLogit, posteriorProbability
      ├─► gradeFromPosterior(prob, confidence)  → RiskGrade
      ├─► buildEarlyWarnings, buildRiskMatrix, buildExplainability
      ├─► hashVerdictShell()  → deterministic verdict hash
      ├─► INSERT scans (verdict jsonb + risk_grade + message_count)
      ├─► INSERT signals (denormalised)
      └─► RPC append_audit_event(case_id, 'scan.completed', {...})
             │
             ▼
      Client receives Verdict → renders SignalsList + Explainability

6.3 Audit chain integrity

event N-1:  prev = 000...0        payload = {…}   hash = H1
event N:    prev = H1              payload = {…}   hash = H2 = sha256(H1||type||caseId||ts||payload)
event N+1:  prev = H2              payload = {…}   hash = H3
                                          │
                                          ▼
                              Head hash printed on PDF report

Serialization: pg_advisory_xact_lock(hash(case_id)) inside the RPC → no interleaved writes even under concurrent requests. Verification is client-side or auditor-side by replaying the same pipe-delimited SHA-256 across the chain in row order.

6.4 Strengths

• Pure-TS detection core. Zero framework coupling. Portable to a CLI, Worker, or Node service without rewrite.
• Isomorphic pre-scan. Anonymous visitors get real value client-side; no server cost until they sign in.
• Deterministic verdicts. Same input → same verdict → same hash. Unit-tested.
• Tamper-evident audit chain enforced in the database, not the app layer. No app-layer bug can silently forge history.
• RLS-first data model. Every user-owned table has auth.uid() = user_id policies. Public share reads are scoped by unexpired token, not by disabling RLS.
• Explicit grants. Every CREATE TABLE public.* migration is followed by explicit GRANT statements — safe against PostgREST silent-403 class of bugs.

6.5 Weaknesses / technical debt

6.6 Scalability

Current architecture scales linearly with active users because Supabase Postgres, Cloudflare Workers, and Lovable AI Gateway are all horizontally scalable managed services. The bottleneck at growth is calibration and false-positive rate, not infra.

7. Strategic Ecosystem Role

Standalone product, currently. CLCKBL is not integrated with other Kenneth Sweet / KESJR properties in code as of this document.

Latent ecosystem hooks (Speculative / Planned):

• Detection core as a shared primitive. src/detection-core/ is deliberately pure-TS. It can be lifted verbatim into a sibling product (e.g. an interpersonal-fraud API, a Chrome extension, a Discord bot for family group chats).
• Audit-chain pattern as reusable trust primitive. The append_audit_event RPC + chain schema is generic — it could underwrite any evidence-grade workflow (rental disputes, custody-communication logging, etc.).
• Verification workflow as reusable component. The challenge-response verification with signed audit is domain-agnostic — could serve as an identity-proof primitive for other creator-owned products.
• Brand family. "CLCKBL" (clickable) reads as part of a potential brand family: CLCKBL-Romance, CLCKBL-Rentals, CLCKBL-Custody, CLCKBL-Elder.

8. Development History

Documented from git-visible artifacts and migration timestamps.

Key decisions (Observed / Inferred):

• Chose TanStack Start over Next.js. Rationale (Inferred): typed RPC via createServerFn, cleaner isomorphic story for the detection core.
• Chose Supabase over own Postgres. Rationale (Confirmed): built on Lovable Cloud, which uses Supabase as the managed backend.
• Chose Bayesian fusion over ML classifier. Rationale (Inferred from code comments): explainability > accuracy at this stage; every signal has a citable reason.
• Chose SHA-256 chain over ledger DB. Rationale (Inferred): keeps the whole system in one Postgres, no second infrastructure component.

Failed / abandoned approaches: None documented in code. Needs creator confirmation.

9. Current State Assessment

What works (Confirmed)

• Anonymous client-side pre-scan on landing + /scan
• Auth: email/password + Google OAuth via lovable.auth.signInWithOAuth("google", …) (src/routes/auth.tsx) — Confirmed
• Full server pipeline with all five deterministic rules lanes (zero external inference)
• Case CRUD + claims ledger + audit chain
• Verification challenges (issue → upload → review → sign)
• Live Guard rolling monitor (with bounded-growth safeguard)
• PDF export with verdict, signals, audit head hash
• 14-day share links to /report/$token
• Legal pages (privacy, terms, safety)
• Mobile-friendly across all surfaces (post Phase 14)
• Vitest coverage on core

What is incomplete or unshipped

Estimated scores (Owner's estimates — not measured)

10. Monetization Analysis

Note: Owner has explicitly de-prioritized monetization in current phase. This section is preserved as strategic analysis, not an action list.

Business models (ranked by fit)

Fastest path to revenue (Speculative)

1. Wire Stripe subscription behind the existing plan_tier = 'premium' gate.
2. Free tier: 5 scans / month, no case save, no share, no PDF.
3. Premium: $12–$20 / month or $99 / year. Cases, share links, PDF, Live Guard, verification.
4. Land page focused on "adult child concerned about aging parent" — most acute pain segment.

Highest-upside path (Speculative)

Enterprise / B2B2C licensing: - Adult Protective Services, area agencies on aging, elder-fraud non-profits. - Family-law firms and mediators. - Financial advisors managing older clients' assets. - Sell as "forensic evidence pack, on demand" not as "scam detector".

Valuation scenarios (Estimates — not guarantees)

All valuations are Speculative and dependent on execution, calibration accuracy, distribution, and market timing.

Lowest-effort monetization

Signed PDF report as a one-off purchase: $9.99 for a shareable, timestamped, chain-anchored report from a single scan. No subscription commitment, immediately useful to the "I need to hand my sister proof this weekend" user.

11. Competitive Positioning

Note: Competitive analysis below is Speculative / requires further audit. No formal market research has been performed.

Adjacent / competing categories

Differentiation

1. Third-party posture. Nobody else builds explicitly for the concerned outsider.
2. Evidence-grade output. Citations + audit chain + PDF = paralegal-quality report.
3. Explainable model. Every signal has a strength, reason, and citation — not a black box.
4. Verification workflow. Challenge-response identity proof with signed audit is a differentiated primitive.

Barriers to replication

• Pattern-pack curation is a moat that compounds over time (with data from pattern_reports).
• Third-party framing requires committing the entire UX to it — hard to bolt on to an existing consumer product.
• Audit chain in the DB is a small piece of code but a big change in product posture ("we take evidence seriously"); competitors would need to rebuild trust to match it.

Vulnerabilities

• A well-funded incumbent (Aura, Bark, LifeLock) could absorb the concept in a quarter.
• An LLM company could ship "scan a conversation" as a demo and eat the free-tier market overnight — but not the evidence / audit chain use case.
• Regulatory: some jurisdictions may treat sharing another person's conversation as a privacy violation. Requires further audit.

12. Future Vision

Ultimate form (Speculative)

The category-defining tool for interpersonal fraud forensics.

A platform where any concerned third party can:

1. Ingest a conversation from any channel (paste, email forward, WhatsApp export, iMessage export).
2. Get a citation-backed forensic verdict across multiple fraud typologies (romance, pig-butchering, sextortion, rental fraud, elder-caregiver fraud, impersonation-of-family).
3. Issue verification challenges the subject must complete on video (or fail visibly).
4. Monitor an ongoing conversation with rolling live-guard alerts.
5. Produce a court-defensible, chain-anchored PDF that survives an evidentiary challenge.
6. Contribute anonymized outcomes to a growing pattern corpus that improves the model.

Ecosystem expansions:

• Chrome/mobile extension: right-click a chat thread → "scan with CLCKBL".
• API for non-profits, APS, and family-law firms.
• White-label detection core for platforms that want to embed victim protection.
• Family-plan multi-seat product ("I share this case with my sister and mom").
• Localized pattern packs for non-English scam scripts (West African, South Asian, East Asian variants).
• Deepfake-video-selfie detection lane in verification workflow.

Moonshot ideas (Speculative)

• A fraud archive where confirmed scammer patterns and identities are collectively remembered — with strict privacy safeguards.
• A victim recovery workflow: once a scam is confirmed, guide the target through bank recall, wallet freezes, platform reporting, and (where lawful) evidence preservation.
• A preemptive scoring service for dating platforms: "This profile matches N confirmed scammer signals" — sold as a B2B API.

13. Priority Roadmap

Ordered by (value × leverage) / effort. Ranks are the owner's estimates.

Now (this month) — Stabilise & validate

Next (this quarter) — Prepare for beta

Later (this year) — Expand & monetize

Someday — Category expansion

• Rental-fraud vertical
• Elder-fraud vertical
• Custody-communication logging vertical
• Court-defensible evidence certification with a third-party notary integration

14. Risk Analysis

15. Preservation & Continuity

Irreplaceable knowledge (must survive founder absence)

1. The third-party framing is the whole product. Any "just add features for the subject" pivot destroys the differentiator. Preserve this.
2. The Bayesian fusion is intentionally simple. Do NOT replace with a black-box classifier until there is corpus-validated evidence of a materially better accuracy/explainability tradeoff.
3. The audit chain is a trust artifact, not a database detail. Do NOT "optimize" it away for write throughput. Its existence is the moat.
4. Pattern packs are curated craft. Adding patterns without validation cases can decrease accuracy. Every pattern should be paired with test fixtures.
5. The detection path is deterministic by design. Change Order 001 removed the AI reasoning lane on purpose — pure algorithmic detection keeps the engine patentable, licensable, privacy-clean, and runnable anywhere. Do NOT re-add an LLM to the detection path without an explicit strategy reversal from the founder.

Continuity requirements

• Custom domain, if registered, must be paid on autopay from a monitored payment method. [SECURE PAYMENT REFERENCE: stored outside this document]
• Lovable project ownership + Supabase project owner email. [ACCESS PROCEDURE: requires creator-controlled vault]
• Detection-core source is portable — even if the hosted app dies, the src/detection-core/ folder is a self-contained IP asset. Back it up outside Lovable.

Recovery procedure (project resurrection)

1. Clone repository.
2. bun install.
3. Provision new Supabase project; apply migrations in supabase/migrations/ in strict lexicographic (timestamp) order. Do NOT skip any — the audit-chain RPC and enum types depend on prior migrations.
4. Restore secrets: SUPABASE_* only. The detection path calls no external inference API — no LOVABLE_API_KEY or OpenAI-equivalent is required to run scans (Change Order 001).
5. bun run dev.
6. Verify: bun run test (vitest core determinism).
7. First smoke check: paste any of the fixtures from src/detection-core/fixtures.ts on /scan.

Inheritance / handoff

Attach this manual + the repository + the domain registrar credentials + the Supabase project owner credentials in a legal instrument (will, trust addendum, or equivalent). Do not embed secrets in this document.

[DEAD MAN SWITCH DETAILS: stored separately in secure legal/estate channel]

16. Strategic Importance Ranking

Owner's estimates. Scale 0–10.

17. Recommended Next Actions

Concrete, ordered, executable.

1. This week. - Register clckbl.com (or best available). Point at the Lovable published URL. - Rename package (tanstack_start_ts → clckbl) in package.json for future clarity. - Add a labeled corpus folder (corpus/) even if empty — commit the intention.
2. This month. - Wire Sentry (or equivalent) for both client and server errors. - Ship a Playwright smoke suite covering: landing renders → sign-in → scan → case create → share link → PDF export. - Build the pattern-report triage admin surface. - Draft a corpus of 50 conversations (start small; adversarial labeling later).
3. This quarter. - Build a separate marketing landing (short, one message: "Someone you love is being scammed. Prove it.") with a waitlist form. - Launch invite-only beta to 25 users in the "adult child of aging parent" segment via targeted outreach (Reddit r/AgingParents, r/Scams, Facebook groups). - Ship the AI-skipped-verdict marker. - Document a ToS + privacy stance for third-party conversation analysis; get one lawyer's eyes on it.
4. This year. - Decide on monetization (only when owner is ready). Recommended: Stripe subscription + per-report one-off. - Ship Chrome extension. - Sign one design-partner org for API validation.

Documentation / branding gaps to close:

• Marketing site copy is the tagline and nothing else — needs a 3-panel "who / what / why" landing.
• No demo video. A 45-second screencast of a scan → verdict → PDF would be the highest-ROI marketing asset.
• Favicon exists (shield); no full brand mark. Consider a lockup: CLCKBL wordmark + shield glyph, monospace, forensic tone consistent with the app.

18. Canonical Summary

CLCKBL is a working prototype of a category that does not yet meaningfully exist: consumer-grade, third-party, evidence-generating forensics for interpersonal fraud.

The product treats the concerned outsider as the operator, the conversation as the artifact, and the verdict as evidence — not as advice. It refuses to guess and refuses to bury its reasoning. Every signal cites its source. Every case event chains into a tamper-evident audit log. Every verdict is deterministic and re-hashable.

The engineering is complete for a beta. What remains is calibration against real data, distribution to the acute-pain segment, and a commercial layer the owner has intentionally deferred.

The core intellectual asset is not the app — it is the detection craft (pattern packs + fusion calibration + audit posture). That asset is portable, testable, and inheritable. Even if the hosted product dies, src/detection-core/ is a self-contained artifact of real value.

This project should continue existing because it addresses a specific, painful, and under-served problem for the third party watching someone they love be exploited — and because the person best positioned to hand them evidence is almost never the platform, almost never the police, and almost never the victim.

It is the outsider. CLCKBL is the tool the outsider does not currently have.

Appendix A — Enterprise Audit Trail (v1 → v2)

This document was audited end-to-end against source on 2026-07-05. Every finding is either a correction to a v1 claim, a strengthening of an under-specified section, or an unresolved item flagged for creator follow-up.

A.0 Change Order 001 — deterministic-only pipeline (2026-07-05)

After v2 was published, the founder issued Change Order 001: remove the AI reasoning lane entirely and restore the pure-rules moat. This v2.1 revision reflects the post-change-order state of the code.

What changed in code: - Deleted src/detection-core/lanes/ai.server.ts. - runFullPipeline no longer accepts an aiRunner; it composes five deterministic lanes only (pattern ×3, linguistic, temporal, network). Zero external inference calls. - Pipeline version bumped 1.1.0 → 1.2.0 and stamped into every verdict. - TS RiskGrade union re-aligned to Postgres: negligible / low / moderate / high / critical. - Postgres signal_source enum rebuilt via migration 20260705172536_*.sql to drop ai and match the TS SignalSource union. - Persistence-boundary guards assertRiskGrade and assertSignalSource added in src/lib/scan.functions.ts. - Vitest: 12/12 pass after the change; tsgo --noEmit clean.

Why it matters strategically: The deterministic engine is the IP thesis. A pure algorithm is patentable, licensable, privacy-clean, portable, and offline-runnable. An LLM in the detection path would compromise every one of those. Change Order 001 is a strategy decision, not a cleanup — do NOT re-add an inference call to the detection path without an explicit reversal from the founder.

A.1 Corrections applied

A.2 Strengthened (unchanged facts, better sourcing)

• Recovery procedure (§15). Added strict-lexicographic migration order requirement — audit-chain RPC and enum types have inter-migration dependencies. Out-of-order application will succeed silently and then fail at first RPC call.
• §5.6 AI Integration (removed). Change Order 001 deleted the AI reasoning lane entirely — src/detection-core/lanes/ai.server.ts is gone and runFullPipeline no longer accepts an aiRunner. The section is intentionally absent; the observability gap it flagged is now moot. Privacy copy on the landing / privacy pages is a follow-up (§13, item 10).
• §10 Monetization. All valuation figures remain explicitly labelled Speculative. No changes to numbers; they should not be quoted out of context.

A.3 Remaining unknowns (require creator confirmation)

A.4 Items intentionally out of scope

• Monetization implementation — Owner has explicitly deferred. Preserved as strategic analysis only; no wiring recommendations beyond §10 and §13.
• Public-domain enumeration of scammer identities or patterns — Deliberate omission for privacy/liability reasons.
• Any secret material (API keys, session tokens, DB passwords, recovery keys) — Placeholders only, per §15.

A.5 Final quality scores (owner's post-audit estimates)

Overall: v2 is fit to be called the canonical source of truth. Re-audit trigger: any change to pipeline lanes, schema enums, or the append_audit_event RPC.

Document prepared by the Lovable agent, from source inspection of the CLCKBL repository, migrations, and configuration as of 2026-07-05. Every claim tagged in Section header — Truthfulness Legend. All valuations and future-vision claims are estimates, not guarantees.

Kenneth E. Sweet Jr. · PromptFluid@gmail.com · KESJR.com · Abilene, TX 79605