42 docs tagged with "acceptance"

Layer 3 acceptance spec defining what every plan × role combination sees in the admin dashboard at /admin/[token]. Supersedes per-tier admin-dashboard sections for all plans.

APPROVED — Stage 1 agent research, pre-populated from the AI Front Desk Provisioning handoff (2026-05-21), the eight locked Phase-0 founder decisions, the AI Front Desk and Local Authority offer pages, the voice-agent code (resolve_route, the funeral/vet vertical pattern, moderation.py), the chatbot stream route, and the confirmed `local_business_*` production schema, then resolved in the founder Stage-2 interview (2026-05-21). Defines the EXPECTED OUTPUT — what a caller, a website visitor, and the business owner experience — for the per-business AI voice agent and website chatbot that the AI Front Desk + Local Authority packages promise. The voice agent is the church-built, multi-tenant, LIFE-SAFETY-tier LiveKit agent (one deployed agent serves church / funeral / vet / local-business). All 16 decisions (8 Phase-0 architecture/scope + 8 Stage-2 resolutions) are folded in; CLAUDE.md Rule #17 is satisfied — the customer-facing build is cleared.

APPROVED — pre-populated from the 2026-06-08 four-agent examination (voice-agent audit, admin/data-model audit, cited best-practice research, QA acceptance audit) and three founder decisions (2026-06-08): (1) spec-then-build phased, (2) refer-first / capture-only-if-already-tried, (3) available on ALL agent tiers (chat + voice), then resolved in the Stage-2 founder interview (2026-06-08 — all open questions closed). Defines the EXPECTED OUTPUT — what a caller / chat visitor, the church benevolence team, and the church admin experience — when a person asks the church for food / money / shelter / rent / utility help (reportedly ~50%+ of church inbound). The model is REFER-FIRST: point callers to vetted local agencies + 211 first; capture for a human benevolence team only when the caller has already tried those; the AI NEVER decides worthiness. CLAUDE.md Rule #17 is SATISFIED — the build is cleared.

What a customer experiences when they cancel their subscription — in-dashboard flow, emails, service during remaining period, post-service state, reactivation

What a ChurchWiseAI Pro Website customer sees at every touchpoint — distinct from the legacy PewSearch path

Note on table naming. viewmode lives on tenantteammembers; churchteammembers is a view that exposes it. Migrations and direct writes target tenantteammembers. Reads through churchteam_members continue to work transparently.

What a cold-outreach prospect must see at every touchpoint — from email receipt through demo interaction and booking CTA. Defines MUST/MUST NOT criteria per vertical (church / funeral / vet) for campaign-ready demos.

What the founder sees in the Outreach Engine dashboard about how a cold-outreach prospect engaged with their demo — viewed, chatted, clicked a conversion CTA — so follow-up targets the demos that actually landed.

What customers see and can do at every state of the per-church email-domain-verification flow in the admin Settings tab. Shipped 2026-05-12 (FA-107 v2).

Layer 3 of the knowledge system — per-tier specs defining exactly what a customer sees at every touchpoint

Stage 1 DRAFT — pre-populated from code and production research by an agent. Every touchpoint must be confirmed or corrected by the founder in a Stage-2 interview. No production deployment decisions should rely on this file alone.

What customers see and can do when composing or replying to an Inbox item via email, SMS, or internal note. Shipped 2026-05-11/12.

What an IllustrateTheWord Premium customer sees at every touchpoint — discovery through working product

Acceptance spec for the player + classroom AI Mode toggle. Default OFF — all scene NPCs respond from scripted dialogue (drawn from character bibles) + RAG into scripture, no live LLM. Opt-in ON — a new Scribe character appears as the live-LLM conversational surface. Honors founder decision F1 (anti-AI Christians/families/churches need an opt-out) locked 2026-05-24.

DRAFT acceptance spec for teacher-hosted live class play — "Living Word in the room on Sunday." Surfaces the founder decisions (L1–L5) and a recommended async-first design. Not yet buildable; decisions required.

Acceptance / expected-output spec for the teacher reporting view over a classroom's students. DRAFT — founder decisions R1–R4 required before build. Surfaces a load-bearing data-model finding (verified 2026-06-04) that contradicts the deep-dive plan's "mostly a read on existing data" assumption.

Acceptance spec for the lw_classrooms table and the teacher-invite-via-join-code flow. Unblocks UGC Phase 1B (school-pool visibility). Honors founder decisions D1 (join-code roster), D2 (anonymous-nickname student model), D3 (free-for-early-list during Phase 1A/1B) locked 2026-05-24.

DRAFT acceptance spec for a cooperative class goal — one shared objective no individual finishes alone ("recover all 7 Creation scrolls, each student finds one"). Async-shared-goal-first. Surfaces founder decisions CQ1–CQ4. Not yet buildable.

Acceptance spec for the Wave-1 growth lever — a once-per-day, frictionless, spoiler-free Bible word puzzle at /living-word/daily with a shareable result card and an earned-trust ChurchWiseAI doorway. The habit + share loop the finish-once narrative game structurally cannot generate. Honors the AI Bridge Principle and the brand-doorway 3 rules from the Wave-1 plan.

Acceptance spec for the three in-game cross-sell surfaces that route Living Word players to the parent ChurchWiseAI brand. Continues from Phase 1A (PR

Acceptance / expected-output spec for the per-tradition applied-understanding question hook (`KnowledgeEnemy.traditionQuestion`, keyed by lensId 0–17) on the Genesis 3 `mistrust-shadow` encounter. Defines the data contract, the cross-tradition FAIRNESS BAR, the founder theological guardrails, the PASS/FAIL acceptance checklist, the authoring + moderation process, and a per-lens DRAFT question table for all 17 visible lenses. Unblocks the `traditionQuestion` TODO in encounters.ts. Every drafted question is marked DRAFT — founder theological review required.

DRAFT acceptance spec for per-scene teacher lesson plans (objective / Scripture / time-boxed beats / discussion prompts) with a printable export. Surfaces founder decisions LP1–LP5. Curriculum content → founder theological/pedagogical review required. Not yet buildable.

Acceptance spec for the first live-ops layer in Living Word. Ships the three-feast Christian calendar (Christmas + Easter + Pentecost on by default for all players per Decision 4), the Holy Week six-scene event as the headline annual content drop, and the multi-streak telemetry foundation that future retention mechanics build on. Honors founder voice rule "is always new" / "deepens" / never "evolves."

DRAFT acceptance spec for a published scope-and-sequence (e.g. "13-week Genesis Beginnings") mapping scenes + quizzes to a weekly teaching plan. Surfaces founder decisions SS1–SS5. Curriculum content → founder review. Not yet buildable.

Acceptance spec for the first user-generated content tier in Living Word. Educators (Sunday school teachers, chaplains, Bible study leaders) author quiz questions for existing scenes, lens-locked to one of the 17 traditions, with private/class/school/public visibility tiers + multi-stage moderation pipeline. Honors founder-locked decisions from 2026-05-23.

What a service-business customer (plumber, roofer, vet, dentist, etc.) sees and does when adding their own logo, hero photos, team headshots, and service-category photos in the WiseAI Agency dashboard — and how those render on their public site.

What customers see at every touchpoint of self-serve add/remove/resume product flows, with industry-standard UX rationale

What a Pro Website customer sees and does when adding a small number of separate pages (About, Ministries, Sermons, Contact, etc.) to their one-page site — the page model, the public render, the editor, and the draft/publish flow.

What a PewSearch Premium Page customer sees at every touchpoint — discovery through working product

What a PewSearch Pro Website customer sees at every touchpoint — discovery through working product

What a Pro Website customer sees and does when connecting their Planning Center / Church Center calendar to their site so the Events section auto-syncs. v1 = iCal feed.

Why this spec exists

What a Pro Chat or Suite Chat customer sees at every touchpoint — discovery through working product. Combined spec; differences called out inline.

What a Pro Both (Voice + Chat bundle) customer sees at every touchpoint — discovery through working product

What a SermonWise Pro customer sees at every touchpoint — discovery through working product

What a Starter Both (Voice + Chat bundle) customer sees at every touchpoint — discovery through working product

What a Starter Chat customer sees at every touchpoint — discovery through working product

What a Starter Voice customer sees at every touchpoint — discovery through working product

What a Suite Both (Voice + Chat bundle) customer sees at every touchpoint — the top-tier plan

What a customer sees when their chat plan trial expires without payment — dashboard state, emails, re-subscribe flow

Expected outputs across every touchpoint for VetWiseAI tenants — Discovery, Pre-Purchase, Email, Dashboard, Voice Agent, Public-Facing, Ongoing, and Lifecycle. Two tiers (Starter/Pro). Sales-led product with self-serve checkout as secondary path.

What a visitor, prospect, or partner sees at every touchpoint on wiseaiagency.com — a marketing-site spec for the meta-brand / parent hub that ties the WiseAI vertical family together. NOT a tier-gated product journey; this is a discovery, contact-form, pricing-overview, local-SEO, and playground spec.