Beth 2.0 project scope

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Three versioned journey briefs have approved outcomes and boundaries.

Inputs required before starting

• P01 scope brief

Start prerequisites

No prerequisite work packages. The required inputs and readiness criteria are listed below.

Ordered execution checklist

1. Read existing setup, monthly-compliance and backlog journey drafts.
2. List allowed founder segments and explicit exclusions for each journey.
3. Write the observable founder outcome and human-review boundary.
4. Obtain accountable-owner review and record unresolved decisions.

Scope boundary

A bounded deliverable within P01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Journey briefs, approval record and decision log.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a segment or advice boundary is disputed, leave that journey draft and request the named domain decision. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.2 · Choose a starting situation

Related screen and functional scope

Pilot scope · Founder journeys · Package definitions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p01-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each selected code has a reviewed bounded service card; unknown evidence is visibly unresolved.

Inputs required before starting

• P01.1

Start prerequisites

P01.1

Ordered execution checklist

1. Select the proposed 12–15 pilot service codes.
2. Define one entity, period, workload unit and included result for each code.
3. List exclusions, required inputs, prerequisites and observable completion checks.
4. Label each input measured, estimated or proposed; record its evidence and reviewer.
5. Resolve duplicate codes or incompatible service definitions.

Scope boundary

A bounded deliverable within P01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Service-card register, source references and review decisions.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If evidence or professional approval is missing, retain the service in draft and identify the question needed to approve it. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

quote.1 · Indicative range and billing period

Related screen and functional scope

Pilot scope · Founder journeys · Package definitions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p01-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Four reviewed package definitions have clear boundaries and no duplicate shared work.

Inputs required before starting

• P01.1
• P01.2

Start prerequisites

P01.2

Ordered execution checklist

1. Match one approved founder need to each proposed package.
2. List included service codes, prerequisites and conditional additions.
3. Check entity/period/work-unit overlaps and remove duplicate work.
4. Write founder-facing inclusions, exclusions and escalation options.
5. Record package owner and versioned approval.

Scope boundary

A bounded deliverable within P01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Package composition matrix, overlap examples and approval record.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If the component services conflict or lack approval, block package release and list the required service decisions. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

quote.2 · What the package includes
workshop.2 · Package composition and draft comparison

Related screen and functional scope

Pilot scope · Founder journeys · Package definitions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p01-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A versioned crosswalk covers all 20 current topics and explains each retired or changed legacy link.

Inputs required before starting

• collection-spec.mjs
• Beth_Learning_Logic.json

Start prerequisites

P01.1

Ordered execution checklist

1. List s1–s8, m1–m6 and e1–e6 with the current collection version.
2. Compare them against the legacy 23-question learning audit.
3. Link each current topic to a specific founder or business decision.
4. Record obsolete mappings and missing consumers without altering submitted snapshots.

Scope boundary

A bounded deliverable within P02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Current-to-legacy crosswalk and accepted mapping review.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a topic has no decision consumer, mark the gap and seek a product decision; do not invent a consumer. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards

Related screen and functional scope

Answer-to-decision learning plan · Current 20-topic interview · Model answers

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p02-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The approved record contract preserves provenance and rejects invented defaults or executable interview text.

Inputs required before starting

• P02.1

Start prerequisites

P02.1

Ordered execution checklist

1. Define field type, unit, period, service ID and allowed values for each consumer.
2. Keep unknown, estimate, measured observation and proposed policy as separate states.
3. Retain exact submission/topic/field and evidence references.
4. Specify checks for dates, missing units, conflicting scope and permitted rule operators.
5. Provide one valid, one unknown and one invalid record example per candidate type.

Scope boundary

A bounded deliverable within P02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Candidate schema, validation table and redacted examples.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If unit, scope or evidence meaning is unresolved, keep the candidate incomplete and route the question to its decision owner. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards

Related screen and functional scope

Answer-to-decision learning plan · Current 20-topic interview · Model answers

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p02-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each topic has one named decision consumer, reviewer role and test, with examples visibly separated from approved rules.

Inputs required before starting

• P02.1
• P02.2

Start prerequisites

P02.2

Ordered execution checklist

1. Assign a reviewer role and acceptance example to every topic.
2. Explain how each answer changes scope, knowledge, pricing, matching or evaluation.
3. Check that contributors see anonymisation, evidence-basis and honest-unknown instructions.
4. Keep model answers labelled illustrative and separate from respondent evidence.
5. Approve the map and record revision/retirement decisions.

Scope boundary

A bounded deliverable within P02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Signed consumer matrix and guidance review.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a reviewer is not appointed or evidence is unsuitable, report that topic as awaiting review rather than complete. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards

Related screen and functional scope

Answer-to-decision learning plan · Current 20-topic interview · Model answers

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p02-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

An approved matrix identifies every review action, authorised role and required record.

Inputs required before starting

• P02.3
• P16 business-role policy

Start prerequisites

P02.3 P16

Ordered execution checklist

1. List contributor, assigned reviewer, manager, expert and publisher actions.
2. Define captured, draft, conflict, reviewed, approved and returned states.
3. Specify who can view identities, evidence and private commercial inputs.
4. Define return reasons, resubmission links and reviewer assignment rules.
5. Approve the transition/permission matrix.

Scope boundary

A bounded deliverable within P03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Role/action matrix and state diagram.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If reviewer authority or data access is disputed, stop that transition and request an access-policy decision. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards

Related screen and functional scope

Review and approval design · Collection readiness · Business administration

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p03-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

An assigned reviewer can return a pack; a corrected version retains both snapshots and decisions.

Inputs required before starting

• P03.1
• Cloud account storage verified

Start prerequisites

P03.1

Ordered execution checklist

1. Reuse immutable submitted packs instead of reviewing mutable drafts.
2. Provide an assigned-review queue and evidence/gap view.
3. Record approve, reject or return decisions with reason and reviewer.
4. Link corrected resubmissions to the original without overwriting history.
5. Verify unauthorised accounts cannot inspect or decide a review.

Scope boundary

A bounded deliverable within P03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted walkthrough, permission tests and review-history export.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If cloud identity or review storage is unavailable, mark implementation blocked and retain the approved contract. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards

Related screen and functional scope

Review and approval design · Collection readiness · Business administration

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p03-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Only reviewed candidates enter the release bundle; unresolved conflicts remain excluded and traceable.

Inputs required before starting

• P03.2
• P02.2

Start prerequisites

P03.2

Ordered execution checklist

1. Compare conflicting candidates by unit, segment, period and evidence basis.
2. Request the missing evidence or correction from the appropriate contributor.
3. Record accepted variants or a reasoned resolution by the accountable reviewer.
4. Create an approved candidate bundle with unresolved exclusions visible.
5. Hand the bundle and decisions to the release owner.

Scope boundary

A bounded deliverable within P03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Conflict register, decisions and candidate-bundle manifest.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Do not average incompatible answers; block affected candidates until the accountable reviewer resolves or preserves distinct variants. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards

Related screen and functional scope

Review and approval design · Collection readiness · Business administration

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p03-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Every approved fact has inspectable support, applicability and a responsible reviewer.

Inputs required before starting

• P01.1
• P03.3
• RAG/document-lifecycle design: beth2.top/scope#rag; approved compatibility, licence and freshness decisions.

Start prerequisites

P01.1 P03.3

Ordered execution checklist

1. Select a bounded FAQ set for the approved pilot journeys.
2. Capture exact BIR, CTA or Supreme Court document and supporting locator.
3. Distinguish legal rule, expert interpretation and internal practice policy.
4. Record applicability, effective dates, amendment checks and source owner.
5. Obtain qualified review; keep uncertain dates or interpretations unpublished.
6. Configure the single Directus knowledge workspace, record/field permissions and production licence decision; avoid duplicate knowledge administration.
7. Register PDFs with official URL/publication channel, document ID/version, page locators, applicability, source owner and freshness policy.
8. Let a nontechnical editor upload, review extracted metadata, test examples and request approval; uncertain OCR or dates remain candidates.

Scope boundary

A bounded deliverable within P04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Fact/source register, locators and expert approvals. Include the PDF/source schema, role-access test, version history, licence decision and recorded editor walkthrough.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If source support or applicability cannot be established, retain the fact as a candidate and specify a human-review route. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

sources.1 · Read the cited guidance
sources.2 · Open the original source

Related screen and functional scope

RAG and document freshness · Knowledge and evidence · Live sources and cache

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p04-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Answers cite the actual applicable support and do not turn fetched source text into agent instructions.

Inputs required before starting

• P04.1
• P14 runtime contract
• RAG/document-lifecycle design: beth2.top/scope#rag; approved compatibility, licence and freshness decisions.

Start prerequisites

P04.1 P14.2

Ordered execution checklist

1. Retrieve relevant approved passages for the selected founder facts and tax period.
2. Retain source/version IDs and exact evidence used by the answer.
3. Check each material claim against the cited passage.
4. Reject unsupported claims and disclose cached or incomplete evidence.
5. Test current, historical, contradictory and prompt-injected source cases.
6. Run Docling conversion and LlamaIndex ingestion as libraries in one worker with persistent IDs/hashes and page/section provenance.
7. Use PostgreSQL full-text/identifier search plus pgvector retrieval; rank relevant passages and retain tables/exceptions.
8. Stage a complete approved passage version and activate it consistently; enforce approval/version/date checks before prompt assembly.
9. Benchmark PDF extraction, retrieval and citation support on expert-approved cases; reject unsupported or uncertain consequential guidance.

Scope boundary

A bounded deliverable within P04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted answer-to-passage trace and claim-support test results. Include original-PDF versus extracted-table checks, ingestion manifest, active-version transaction proof and held-out retrieval results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a claim lacks support, remove or qualify it and request review; do not fabricate a citation to complete the answer. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

sources.1 · Read the cited guidance

Related screen and functional scope

RAG and document freshness · Knowledge and evidence · Live sources and cache

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p04-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Superseded evidence cannot be reused as current; all tested outages lead to a documented verified fallback or review.

Inputs required before starting

• P04.1
• P04.2
• RAG/document-lifecycle design: beth2.top/scope#rag; approved compatibility, licence and freshness decisions.

Start prerequisites

P04.2

Ordered execution checklist

1. Define review-due, changed-source and retirement triggers.
2. Expire affected cached answers while preserving historical versions.
3. Test changed hashes, later amendments and uncertain effective dates.
4. Test blocked sources and verify alternate-copy identity before reuse.
5. Record bounded fallback wording and specialist escalation when evidence remains unavailable.
6. Implement Temporal schedules and resumable activities for source checks and ingestion with bounded retries/timeouts and duplicate-safe writes.
7. Monitor publication lists for new amendments and selected document hashes; preserve last successful checks and review-due status.
8. Use explicit retirement and dependent answer-cache invalidation; do not interpret website outages or partial-sync absence as deletion.
9. Reconcile approved/indexed versions and alert on failures, lag and overdue reviews; delayed events cannot reactivate retired versions.
10. Test interruption recovery, duplicate events, scanned PDFs, partial sync, publication changes and offline fallback with exact expected/actual evidence.

Scope boundary

A bounded deliverable within P04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Freshness policy, retirement trace and outage test report. Include durable-workflow recovery trace, reconciliation report, freshness dashboard and retirement/cache invalidation results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If freshness or alternate identity is unresolved, quarantine current use and record the source owner's next check. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

sources.1 · Read the cited guidance
sources.2 · Open the original source

Related screen and functional scope

RAG and document freshness · Knowledge and evidence · Live sources and cache

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p04-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

No pilot rule relies on an undefined fact or silently converts an unknown into a confirmed value.

Inputs required before starting

• P01.2
• P02.2

Start prerequisites

P01.2 P02.2

Ordered execution checklist

1. Define canonical fact keys and units for the pilot decisions.
2. Record volunteered information with confirmed, approximate or unknown state.
3. Define how conflicting answers are clarified and corrections are attributed.
4. Identify material changes requiring scope reconfirmation.
5. Approve a fact-to-question-to-decision crosswalk.

Scope boundary

A bounded deliverable within P05. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Fact dictionary, correction examples and reviewer sign-off.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If fact meaning is ambiguous, leave it unknown and request one clarifying definition before implementing a rule. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.2 · Choose a starting situation
profile.1 · Review the business facts

Related screen and functional scope

Founder profile screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p05-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Pilot routes preserve uncertainty, avoid repetitive questions and choose the approved review boundary.

Inputs required before starting

• P05.1
• P04.1

Start prerequisites

P05.1 P04.1

Ordered execution checklist

1. Map approved facts to eligible work, missing prerequisites and escalation.
2. Ask the easiest unresolved question that changes the decision.
3. Skip already volunteered facts and explain why a new fact matters.
4. Prioritise stated deadlines and qualified review for official notices.
5. Record the rule/version and reason for each routing decision.

Scope boundary

A bounded deliverable within P05. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Decision table and typical/unknown/urgent routing results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If required applicability or urgency rules are unapproved, route to a person instead of guessing the service outcome. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.1 · Ask Beth a question
start.2 · Choose a starting situation
profile.1 · Review the business facts

Related screen and functional scope

Founder profile screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p05-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Reviewed scenarios produce the right scope, recorded confirmation and traceable correction history.

Inputs required before starting

• P05.2

Start prerequisites

P05.2

Ordered execution checklist

1. Run normal, conflicting and not-sure founder conversations.
2. Show a plain-language fact and proposed-scope summary.
3. Record explicit confirmation and the exact profile snapshot.
4. Change a material workload or tax-status fact and require reconfirmation.
5. Verify a quote never treats unconfirmed guesses as verified inputs.

Scope boundary

A bounded deliverable within P05. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Scenario transcripts, confirmation records and reviewer decisions.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a critical scope error occurs, report the failing rule and block that route's acceptance until corrected. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.2 · Choose a starting situation
profile.1 · Review the business facts
profile.2 · Confirm the proposed scope

Related screen and functional scope

Founder profile screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p05-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A reviewed pricing-input contract identifies units, evidence basis and authority; confidential values remain restricted.

Inputs required before starting

• P01.2
• P03.3

Start prerequisites

P01.2 P03.3

Ordered execution checklist

1. Specify entity, period, currency, work unit and increment for each pilot service.
2. Separate productive delivery/review/coordination hours from waiting days.
3. Label measured jobs, professional estimates and proposed commercial policy distinctly.
4. Define assumptions, exclusions, minimum inputs and fee-policy authority.
5. Provide approved version references without posting confidential amounts to the shared board.

Scope boundary

A bounded deliverable within P06. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted driver register, evidence references and approval manifest.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If costs or policy approval are missing, retain a draft estimate basis and request the finance decision; do not invent rates. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

quote.1 · Indicative range and billing period
workshop.2 · Package composition and draft comparison

Related screen and functional scope

Package and estimate screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p06-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Approved rule changes affect the correct quantities, and overlapping work is never charged twice.

Inputs required before starting

• P06.1
• P01.3

Start prerequisites

P06.1 P01.3

Ordered execution checklist

1. Locate existing hardcoded base allowances and quantity rules.
2. Replace only approved inputs with versioned validated rule records.
3. Calculate workload increments without LLM arithmetic.
4. Deduplicate shared work by entity and period and respect prerequisites.
5. Test boundary counts, conditional extras and wrong-unit/currency/period rejection.

Scope boundary

A bounded deliverable within P06. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Boundary calculations, overlap checks and rule-version change trace.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If rule interpretation differs from the reviewed unit, stop that service calculation and return the definition for correction. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

profile.1 · Review the business facts
quote.1 · Indicative range and billing period
quote.2 · What the package includes
workshop.2 · Package composition and draft comparison

Related screen and functional scope

Package and estimate screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p06-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The exact saved estimate is reproducible and its uncertainty/exclusions are visible to the founder.

Inputs required before starting

• P06.2
• P05.3

Start prerequisites

P06.2 P05.3

Ordered execution checklist

1. Save confirmed inputs, explicit assumptions and quote/rule version.
2. Explain range, billing period, exclusions and pass-through fees.
3. Block firm quotes where critical inputs remain unknown.
4. Replay saved quotations after a later rule-version change.
5. Verify new prices affect future quotes while previous accepted versions stay intact.

Scope boundary

A bounded deliverable within P06. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted quote snapshots, replay results and missing-input test report.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If saved inputs or rule versions are incomplete, mark the quote unreplayable and block approval until the record is repaired. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

profile.2 · Confirm the proposed scope
quote.1 · Indicative range and billing period
quote.2 · What the package includes
report.1 · Babylon 2k report and scope
portal.2 · Approve scope and budget
workshop.2 · Package composition and draft comparison

Related screen and functional scope

Package and estimate screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p06-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each eligible pilot roster entry has verified job-specific capability and explicit limitations.

Inputs required before starting

• P01.2

Start prerequisites

P01.2

Ordered execution checklist

1. Confirm the proposed 8–12 pilot practitioners and service codes.
2. Record qualification type, issuer, review/expiry and verification reference privately.
3. Verify actual service experience, segment, language and location/remote coverage.
4. List professional limitations and incompatible engagements.
5. Approve roster entries or record missing evidence.

Scope boundary

A bounded deliverable within P07. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted roster, private verification references and review decisions.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If capability or a required qualification is unverified, exclude the practitioner from that service's eligible results. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

specialists.1 · Compare suitability

Related screen and functional scope

Specialist selection screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p07-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Availability promises require verified status and explicit acceptance, with documented fallback.

Inputs required before starting

• P07.1

Start prerequisites

P07.1

Ordered execution checklist

1. Collect productive capacity, lead time and callback target for each pilot specialist.
2. Define explicit available/busy/offline states and expiry.
3. Identify backup roles and the acceptance needed before promising a slot.
4. Define no-reply, declined-job and reassignment handling.
5. Approve the operating policy without treating online activity as acceptance.

Scope boundary

A bounded deliverable within P07. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Capacity register, status-expiry examples and signed handoff policy.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a specialist has not confirmed capacity, display unavailable or pending and route the case to its operations owner. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

specialists.1 · Compare suitability
handoff.1 · Live / Not live indicator

Related screen and functional scope

Specialist selection screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p07-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

No ineligible practitioner is recommended and every selected specialist remains traceable across the handoff.

Inputs required before starting

• P07.1
• P07.2

Start prerequisites

P07.2

Ordered execution checklist

1. Apply verified skills, required credentials, coverage and conflicts as hard filters.
2. Rank only eligible people with readable reasons.
3. Test nearer-unqualified, expired, busy/offline and no-match cases.
4. Persist exact specialist/profile IDs on selection.
5. Verify downstream appointment and case keep that selection or an audited reassignment.

Scope boundary

A bounded deliverable within P07. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Matching fixtures, reasons and selection/reassignment trace.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If filtering or identity linkage fails, suppress that match and report the roster or mapping correction required. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

specialists.1 · Compare suitability
specialists.2 · Select this specialist

Related screen and functional scope

Specialist selection screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p07-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Repeated acceptance creates one case with the agreed scope and a visible responsible role/next action.

Inputs required before starting

• P06.3
• P07.3
• Cloud /cases storage verified

Start prerequisites

P06.3 P07.3

Ordered execution checklist

1. Define case states, responsible role and allowed transitions.
2. Create a case from the exact accepted quote/profile/specialist versions.
3. Give retries one identity so acceptance creates one case.
4. Show owner, current milestone and next action to the client.
5. Record reassignment and staff-owned follow-up without promising autonomous recovery.

Scope boundary

A bounded deliverable within P08. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted case record, state-transition checks and retry result.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If scope or specialist identity is unresolved, keep acceptance pending and ask the authorised owner to resolve it. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

report.1 · Babylon 2k report and scope
specialists.2 · Select this specialist
handoff.3 · Create a case and request a human
portal.1 · Case status and owner

Related screen and functional scope

Case delivery screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p08-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A case has a usable readiness checklist; missing evidence and unapproved extra work remain visibly blocked.

Inputs required before starting

• P08.1
• P16 secure file controls

Start prerequisites

P08.1 P16

Ordered execution checklist

1. Translate service prerequisites into a document-type/period checklist.
2. Separate quick intake answers from later secure document requests.
3. Record missing records, permitted substitutes and the reason work must pause.
4. Propose extra work with exact deliverable, fee version and acceptance checks.
5. Require authorised client approval before starting the changed scope.

Scope boundary

A bounded deliverable within P08. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Document-preparation checklist, redacted change proposal and approval history.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If required records or approval are absent, pause only the affected milestone and record who must supply or approve the next input. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

portal.1 · Case status and owner
portal.2 · Approve scope and budget

Related screen and functional scope

Case delivery screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p08-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A case retains correct scope/owner/messages, rejects unapproved work, and closes only against reviewed delivery evidence.

Inputs required before starting

• P08.1 case state and agreed service outcome

Start prerequisites

P08.1 P08.2

Ordered execution checklist

1. Define case/work states and the authorised actor for each transition
2. Retain assigned specialist and approved scope across messages and follow-ups
3. Attempt start of unapproved/rejected additional work and require rejection
4. Retry start/completion actions and verify one recorded transition and audit entry
5. Record delivery output against each agreed milestone and unresolved exception
6. Obtain client-facing completion review; link consultation work to P17 rather than duplicating booking controls

Scope boundary

A bounded deliverable within P08. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved state table, redacted message history, retry/denial results and reviewed delivery sample

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a milestone or approval is missing, leave the affected work/case pending and record the required owner decision. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

specialists.2 · Select this specialist
portal.1 · Case status and owner

Related screen and functional scope

Case delivery screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p08-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A founder's website and Telegram messages resolve to the correct authorised case without duplicate tickets.

Inputs required before starting

• P07.3
• P08.1
• P16 identity policy

Start prerequisites

P07.3 P08.1 P16

Ordered execution checklist

1. Select the approved pilot channel and shared-inbox destination.
2. Map verified founder, conversation and case identities.
3. Send a consented redacted brief into the correct inbox.
4. Deduplicate repeated inbound events and retain ticket identifiers.
5. Test wrong-account routing and rejected/expired access.

Scope boundary

A bounded deliverable within P09. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Channel setup manifest, redacted ticket trace and routing/deduplication tests.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If provider access or identity linkage is unavailable, retain manual supervised handoff and report the exact account/connector requirement. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

handoff.1 · Live / Not live indicator
handoff.2 · Consent to share the brief
handoff.3 · Create a case and request a human

Related screen and functional scope

Human handoff screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p09-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

One person owns the conversation and Beth cannot speak over active human takeover.

Inputs required before starting

• P09.1
• P07.2

Start prerequisites

P09.1 P07.2

Ordered execution checklist

1. Require a verified specialist to accept conversation ownership.
2. Atomically reject competing simultaneous accepts.
3. Pause Beth and suppress late generated replies after takeover.
4. Expire stale presence and retain disconnection status.
5. Require explicit return-to-Beth before automated replies resume.

Scope boundary

A bounded deliverable within P09. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Concurrent-accept, late-reply, expiry and resume test results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If ownership is uncertain, pause automated posting and assign operations to reconcile the ticket rather than choose a speaker silently. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

handoff.1 · Live / Not live indicator

Related screen and functional scope

Human handoff screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p09-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

No reply retains an owned follow-up task; retries cannot duplicate the handoff or expose an unconsented brief.

Inputs required before starting

• P09.2
• P13 sharing-consent policy

Start prerequisites

P09.2 P13

Ordered execution checklist

1. Retain the case/ticket when no specialist answers.
2. Record callback consent, target and accountable fallback role.
3. Save channel acknowledgement and failure states separately from case state.
4. Retry or reassign with duplicate-safe ticket/action receipts.
5. Verify contact withdrawal or changed assignment stops inappropriate sharing.

Scope boundary

A bounded deliverable within P09. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

No-reply walkthrough, redacted channel receipts and reassignment/withdrawal tests.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If delivery remains unacknowledged, keep it failed/pending with an operations owner; never report sent as received. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

handoff.1 · Live / Not live indicator
handoff.2 · Consent to share the brief
handoff.3 · Create a case and request a human
portal.3 · Notification delivery status

Related screen and functional scope

Human handoff screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p09-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Approved editor contracts cover routine business changes without direct code/database edits.

Inputs required before starting

• P03.1
• P01.3
• P16 role policy

Start prerequisites

P03.1 P01.3 P16

Ordered execution checklist

1. List routine FAQ, source, service, package, price-driver and specialist changes.
2. Define author/reviewer/publisher actions for each record type.
3. Specify plain-language fields, help, required evidence and validation.
4. Show changed values and affected founder decisions.
5. Review the design with a manager using existing records and fictional examples.

Scope boundary

A bounded deliverable within P10. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Editor field/action matrix and manager usability notes.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a change needs policy authority or unsafe direct access, exclude that action and request a role/workflow decision. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards

Related screen and functional scope

Team workshop screen · Business administration

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p10-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A manager can inspect a candidate's effect and evidence without changing live Beth; every preview ties to an immutable version.

Inputs required before starting

• P10.1
• P03.3
• P04.1
• P06.2

Start prerequisites

P10.1 P03.3 P04.1 P06.2

Ordered execution checklist

1. Bundle candidate knowledge, source, pricing and prompt/rule versions.
2. Display approvals, gaps and change comparison before preview.
3. Run agreed development examples against the candidate version.
4. Record preview inputs, outputs and failed gates with the bundle.
5. Prevent unapproved or incomplete candidates from becoming current.

Scope boundary

A bounded deliverable within P10. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Release manifest, change comparison and failed-gate walkthrough.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an approval or test fails, retain the previous current version and identify the candidate record needing correction. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards
workshop.2 · Package composition and draft comparison
workshop.3 · Readiness and evidence check

Related screen and functional scope

Team workshop screen · Business administration

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p10-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The manager can publish and reverse a tested change without developer intervention, with a complete audit trail.

Inputs required before starting

• P10.2
• P04.3

Start prerequisites

P10.2 P04.3

Ordered execution checklist

1. Require the authorised publisher and recorded accepted test result.
2. Publish one atomic version bundle and append an audit record.
3. Invalidate affected caches and retire superseded current records.
4. Restore the previous bundle while preserving applicable history.
5. Have a trained manager complete a fictional correction/publish/rollback exercise.

Scope boundary

A bounded deliverable within P10. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Publish/rollback exercise record, version audit and cache-retirement checks.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a release or rollback cannot be proven consistent, keep or restore the verified previous release and escalate to its operating owner. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.1 · Role interviews and service effort cards
workshop.2 · Package composition and draft comparison
workshop.3 · Readiness and evidence check

Related screen and functional scope

Team workshop screen · Business administration

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p10-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The reviewed suite and frozen split have expected outcomes and no development/holdout leakage.

Inputs required before starting

• P01.1
• P01.2
• P02.3

Start prerequisites

P01.1 P01.2 P02.3

Ordered execution checklist

1. Draft 45 cases across three journeys and five scenario categories.
2. Label expected facts, clarifications, scope, pricing drivers, citations and escalation.
3. Group paraphrases/related clients before assigning 30development and15holdout cases.
4. Restrict holdout answers from prompts and worked examples.
5. Agree metrics and critical-failure gates before any comparison.

Scope boundary

A bounded deliverable within P11. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted scenario manifest, split/version record and reviewer acceptance.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If reference outcomes are disputed or holdout leaks, stop evaluation and have independent reviewers correct/refreeze the affected cases. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.3 · Readiness and evidence check

Related screen and functional scope

Evaluation and improvement · Acceptance requirements

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p11-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A reproducible paired evaluation has reviewed results and no critical suite failure before release acceptance.

Inputs required before starting

• P11.1
• P10.2
• P04.2
• P05.3
• P06.3
• P07.3
• P15 tracing

Start prerequisites

P11.1 P10.2 P04.2 P05.3 P06.3 P07.3 P15.2

Ordered execution checklist

1. Pin model, prompt, source, tool and candidate versions for the run.
2. Run baseline, enriched and relevant input-removal comparisons.
3. Repeat holdout cases as agreed and retain redacted output traces.
4. Blind reviewers to version and record metric/critical-failure judgments.
5. Publish measured results and limits without claiming universal accuracy.

Scope boundary

A bounded deliverable within P11. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Run manifest, redacted outputs, blinded scoring and critical-failure log.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If a critical error occurs, block that candidate and assign the failed rule/source/action for correction and affected-case rerun. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.1 · Ask Beth a question
workshop.3 · Readiness and evidence check

Related screen and functional scope

Evaluation and improvement · Acceptance requirements

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p11-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Pilot acceptance and improvement proposals rely on reviewed outcomes, not filled surveys or conversion alone.

Inputs required before starting

• P11.2
• P08.3
• P15 operational readiness

Start prerequisites

P11.2 P08.3 P15.3 D07.3

Ordered execution checklist

1. Record accepted scope/version and actual hours by role using anonymised job IDs.
2. Separate extra approved scope, waiting time and rework from estimate error.
3. Compare reviewed reference quotes with actual delivery and quality outcomes.
4. Propose adjustments through candidate review instead of automatic price edits.
5. Present evidence, unresolved blockers and a go/hold decision to the pilot owner.

Scope boundary

A bounded deliverable within P11. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Anonymised outcome register, calibration review and pilot go/hold decision.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If actual job evidence or launch readiness is absent, label results provisional and keep expansion approval on hold. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.3 · Readiness and evidence check

Related screen and functional scope

Evaluation and improvement · Acceptance requirements

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p11-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A prioritised expansion brief has explicit scope, acceptance and approvals; it authorises planning only.

Inputs required before starting

• P11.3

Start prerequisites

P11.3

Ordered execution checklist

1. Review pilot errors, demand and operational workload.
2. Select remaining journeys/services toward the proposed broader catalogue.
3. Identify VAT/payroll/inventory/foreign-founder review boundaries.
4. Define English/Filipino/Taglish acceptance examples and reviewer capacity.
5. Record proceed/defer choices, prerequisite owners and estimated evidence needs.

Scope boundary

A bounded deliverable within P12. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Expansion decision log and scoped acceptance briefs.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Without pilot acceptance or reviewer capacity, retain each expansion as proposed and do not commit a launch date. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

specialists.1 · Compare suitability

Related screen and functional scope

Broader launch scope · Delivery sequence

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p12-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each option has a reviewed feasibility brief and explicit proceed/defer approval before implementation.

Inputs required before starting

• P11.3
• P14 approved connector proof

Start prerequisites

P11.3 P14

Ordered execution checklist

1. Select exact proposed WhatsApp/LINE, calendar and Babylon interface requirements.
2. Confirm provider ownership, API access, consent and identity mappings.
3. Define request/reschedule/cancel, callback and failure receipts to verify.
4. Identify provider approvals, compatibility gaps and support responsibility.
5. Submit a bounded proof/build decision; keep unavailable integrations manual.

Scope boundary

A bounded deliverable within P12. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Provider/action inventory, compatibility questions and decision record.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If provider action or permission cannot be proven, record the gap and seek a scope decision rather than promise the integration. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

portal.1 · Case status and owner

Related screen and functional scope

Broader launch scope · Delivery sequence

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p12-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The broader-launch plan states validated need, bounded workflow, tests and decision owners without installing new infrastructure.

Inputs required before starting

• P11.3
• P12.1
• P12.2

Start prerequisites

P12.1 P12.2

Ordered execution checklist

1. Define one proposed document/approval/reminder lifecycle and system-of-record boundaries.
2. Specify action receipts, retry limits, reassignment and worker-recovery scenarios.
3. Identify the measured need for Temporal or another approved recovery choice.
4. Define broader load, capacity, retention and recovery acceptance tests.
5. Obtain a separate implementation decision and keep optional engines deferred.

Scope boundary

A bounded deliverable within P12. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Workflow brief, recovery scenarios, capacity assumptions and scope approval.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If autonomous recovery is not an approved need, keep supervised follow-up and request a separate architecture/scope decision. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Broader launch scope · Delivery sequence

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p12-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Approved field/access and retention matrices cover each operation; unknown policy decisions block affected implementation.

Inputs required before starting

• P01 pilot scope
• P16.1 role/data-access decisions

Start prerequisites

P01 P16.1

Ordered execution checklist

1. Inventory report fields and identify founder-visible versus restricted fields
2. Specify recipient, purpose, scope and revocation behavior for sharing contact details and summaries
3. Define chat, case, submission, document and audit retention/deletion behavior separately
4. Define authorised history search, download, recall and deletion operations
5. Record unresolved decisions and obtain product/privacy approval

Scope boundary

A bounded deliverable within P13. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved field matrix, consent wording, data-lifecycle decisions and reviewer record

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

report.1 · Babylon 2k report and scope
handoff.2 · Consent to share the brief

Related screen and functional scope

Report screen · History screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p13-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Downloaded and on-screen reports exactly reproduce the saved amounts/assumptions and never disclose restricted internal costs.

Inputs required before starting

• P13.1
• approved saved quote and source versions

Start prerequisites

P13.1 P04 P06

Ordered execution checklist

1. Map saved facts, scope lines, quantities, quote/rule version and source references to the report
2. Generate HTML/print/download formats from the same saved snapshot
3. Display assumptions, conditional additions, fees, currency and estimate status consistently
4. Compare report totals and line items to the saved quote without recalculating under current rules
5. Test long text, missing optional fields, repeat downloads and cross-account access
6. Attach a reviewed sample report and replay result

Scope boundary

A bounded deliverable within P13. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Saved input snapshot, report samples, exact-total comparison and authorisation test results

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

report.1 · Babylon 2k report and scope
report.2 · Download, print or save

Related screen and functional scope

Report screen · History screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p13-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

An authorised sharing/history/deletion scenario and an unauthorised scenario match the approved policy; retained cases remain traceable.

Inputs required before starting

• P13.1 policy
• saved records and authorised files

Start prerequisites

P13.1 P16.2

Ordered execution checklist

1. Search and reopen only the signed-in founder’s allowed history
2. Require and record approved consent before sharing a summary/contact details
3. Verify intended recipients and restrict shared file/document access
4. Delete a test chat and check its search, recall, caches and delayed-save behavior
5. Confirm active case retention and explain the resulting state to the founder
6. Record policy exceptions, revocation behavior and reviewer acceptance

Scope boundary

A bounded deliverable within P13. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Consent/audit records, before/after history results and denied-access evidence

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.3 · Start a new conversation
report.2 · Download, print or save
handoff.2 · Consent to share the brief
history.1 · Search previous conversations
history.2 · Recall or delete

Related screen and functional scope

Report screen · History screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p13-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A versioned policy states the allowed model/tool path for every pilot task and distinguishes current deployment from future runtime work.

Inputs required before starting

• Pilot scope and current cloud architecture evidence

Start prerequisites

P01

Ordered execution checklist

1. Document current cloud runtime versus proposed production components and obtain a decision before introducing engines
2. Define new/resume/reset/interrupt/correction states and shared confirmed-fact ownership
3. Define economical, balanced and reasoning task profiles with minimum risk/capability requirements
4. Approve exact provider/model versions, budgets, timeouts, retries and fallback paths
5. Define permission-checked tools and which actions require explicit founder approval
6. Record missing provider/privacy/edition decisions as blockers

Scope boundary

A bounded deliverable within P14. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved runtime decision, state diagram/table, model policy and tool-permission matrix

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.1 · Ask Beth a question
start.3 · Start a new conversation
sources.1 · Read the cited guidance

Related screen and functional scope

Conversation screen · Model and source mechanism · MCP connections

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p14-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The scenario preserves latest facts and single action receipts; failure/budget cases take the approved fallback or human path.

Inputs required before starting

• P14.1 policy
• approved knowledge and cloud AI connection

Start prerequisites

P14.1 P04.1 D04.1

Ordered execution checklist

1. Implement or adapt the approved runtime without duplicating gateway responsibilities
2. Test streaming, reconnect/cancel and new-chat isolation without duplicate messages/actions
3. Interrupt an estimate with a cited question, correct a fact and resume with the latest confirmed state
4. Switch task profiles and verify confirmed facts persist while unrelated personal data is excluded
5. Test spend/time/retry caps, provider outage and unapproved cheap-model fallback refusal
6. Capture redacted versioned traces and obtain evaluation/security review

Scope boundary

A bounded deliverable within P14. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

State/streaming fixtures, expected/actual logs, redacted traces and policy-version review

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

start.1 · Ask Beth a question
start.3 · Start a new conversation
sources.1 · Read the cited guidance
history.1 · Search previous conversations

Related screen and functional scope

Conversation screen · Model and source mechanism · MCP connections

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p14-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The bounded approved actions work with least necessary scope, isolation and replay safety; failed compatibility yields an explicit replacement/manual decision.

Inputs required before starting

• Approved implementation path and two bounded existing-provider proof selections

Start prerequisites

P14.1 P16.1

Ordered execution checklist

1. Approve chosen providers/actions and record read/write scopes before enabling them
2. Prove the chosen client/gateway transport against pinned versions; keep one credential owner
3. Validate per-founder connection isolation, allowlists and encrypted credential storage
4. Test OAuth expiry/refresh, revocation, unauthorised actions and timeouts
5. Require consent for write actions and persist receipts so retries cannot repeat the action
6. Record real-provider success separately from catalogue claims and keep manual fulfilment for failed proof

Scope boundary

A bounded deliverable within P14. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Scoped compatibility matrix, real-provider receipts, denied-action/retry tests and adoption decision

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

sources.1 · Read the cited guidance

Related screen and functional scope

Conversation screen · Model and source mechanism · MCP connections

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p14-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

One approved real email flow succeeds; duplicate retries do not create another case/alert and failures remain actionable to staff.

Inputs required before starting

• Approved case/appointment events and notification recipients

Start prerequisites

P08.1 P17.2 P09.2

Ordered execution checklist

1. Map case, appointment and staff-action events to allowed recipients and consent requirements
2. Approve email connector, sender identity and template content
3. Persist event/delivery IDs before send and bound retries
4. Test duplicate events, provider failure, rejection and unavailable recipients
5. Show staff delivery state while retaining the underlying case/ticket
6. Attach one real delivery proof and label all simulated paths

Scope boundary

A bounded deliverable within P15. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Event/template matrix, redacted provider receipt and duplicate/failure test log

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

booking.2 · Save appointment request
portal.3 · Notification delivery status
workshop.3 · Readiness and evidence check

Related screen and functional scope

Alerts workstream · QA and observability · Operating capacity

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p15-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

An operator can detect, locate and triage a deliberate failure using the guide and approved traces without accessing unnecessary private data.

Inputs required before starting

• Approved runtime and test deployment

Start prerequisites

P14.1 D01.1

Ordered execution checklist

1. Define correlation IDs across answer, quote, source fetch, case and external action
2. Record model/prompt/rule/source versions, latency, spend and handoff outcome with redaction
3. Verify secrets, private documents and unnecessary personal data are excluded
4. Define health/error signals and thresholds for source/provider/storage/channel failures
5. Assign incident contacts and escalation/fallback steps; send one test operational alert
6. Trace a test failure from the user’s visible message to the relevant redacted evidence

Scope boundary

A bounded deliverable within P15. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redaction checks, correlated trace sample, tested alert and incident runbook

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.3 · Readiness and evidence check

Related screen and functional scope

Alerts workstream · QA and observability · Operating capacity

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p15-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Measured results support an approved capacity envelope or explicitly limit launch; no untested sizing assumption is reported as capacity.

Inputs required before starting

• Stable pilot functions, monitoring and approved test traffic

Start prerequisites

P14.2 P15.2 P16

Ordered execution checklist

1. Confirm the pilot sizing assumption and agree response/failure/spending thresholds before testing
2. Prepare representative chat, source, save and handoff workloads using fictional data
3. Measure 20 simultaneous sessions and the expected pilot traffic mix rather than only empty-page requests
4. Exercise rate limits, slow provider/source responses and recovery within bounded retry budgets
5. Record throughput, latency, error rates, successful-answer cost and capacity bottlenecks
6. Review results, set practical operating limits and create defects for unmet thresholds

Scope boundary

A bounded deliverable within P15. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved workload/threshold plan, result graphs/logs and launch-limit decision

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

workshop.3 · Readiness and evidence check

Related screen and functional scope

Alerts workstream · QA and observability · Operating capacity

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p15-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Every pilot operation has an approved role/membership rule and recovery/revocation path; edition gaps have a decision rather than an assumed permission.

Inputs required before starting

• Pilot organisation and role decisions
• cloud identity baseline

Start prerequisites

P01 D02

Ordered execution checklist

1. Define person/account/business identifiers and allowed memberships for the pilot organisation
2. Specify founder, assigned specialist, manager and expert reviewer actions with deny-by-default access
3. Choose invite/onboarding, access revocation and password/account recovery behavior
4. Define who administers access and where privileged credentials are held
5. Write same-business, other-business, revoked-role and unauthenticated test expectations
6. Approve the access matrix and identify any selected software-edition limitations

Scope boundary

A bounded deliverable within P16. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved access matrix, membership fixtures and recovery/edition decisions

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

access.1 · Sign in
access.2 · Create an account
handoff.1 · Live / Not live indicator
portal.1 · Case status and owner
portal.2 · Approve scope and budget
history.1 · Search previous conversations

Related screen and functional scope

Sign-in screen · Role permissions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p16-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Founders receive source-approved preparation requirements and authorised upload/retrieval; direct-link and cross-business attempts cannot bypass permissions.

Inputs required before starting

• P16.1 access matrix
• approved service-document requirements

Start prerequisites

P16.1 P01

Ordered execution checklist

1. Map each service’s approved required documents and preparation instructions without inventing requirements
2. Define allowed file types/sizes and storage location; reject unsupported/malformed uploads
3. Authorise upload, listing, download/export and deletion against business/case membership
4. Prevent public/static links from exposing confidential files and test direct URL access
5. Test retries/interrupted uploads and retain a clear pending/missing-document state
6. Verify two businesses and an assigned/unassigned specialist against file permissions

Scope boundary

A bounded deliverable within P16. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Document requirement mapping, upload fixtures, access-denial logs and private-storage proof

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

handoff.1 · Live / Not live indicator
portal.1 · Case status and owner
portal.2 · Approve scope and budget

Related screen and functional scope

Sign-in screen · Role permissions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p16-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Revocation and data-lifecycle tests match approved policy, including retained-case exceptions and provider boundaries.

Inputs required before starting

• Approved lifecycle policy and implemented roles/files

Start prerequisites

P16.1 P16.2 P13.1

Ordered execution checklist

1. Apply the approved separate retention rules to chats, cases, submissions, files and traces
2. Revoke a user or assignment and test existing sessions/links and new requests
3. Verify document/identity data stays out of public source searches and unnecessary model context
4. Exercise approved deletion/export request paths and record retained active-case exceptions
5. Review provider/data-handling and backup access decisions with the responsible owner
6. Publish the reviewed handling/revocation checklist for operators

Scope boundary

A bounded deliverable within P16. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Revocation/lifecycle test matrix, redacted trace checks and privacy owner acceptance

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

handoff.1 · Live / Not live indicator
portal.1 · Case status and owner
portal.2 · Approve scope and budget
history.2 · Recall or delete

Related screen and functional scope

Sign-in screen · Role permissions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p16-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

An approved state/validation matrix and fixtures distinguish a saved request from specialist acceptance.

Inputs required before starting

• Specialist roster and appointment-state requirements

Start prerequisites

P07.2 P16.1

Ordered execution checklist

1. Define request, awaiting confirmation, confirmed, rescheduled, cancelled and declined state transitions with authorised actors
2. Specify Philippine time zone, future-time bounds, allowed 30/60-minute durations and formats from current requirements
3. Specify missing/invalid specialist, time, duration and format validation responses
4. Verify a valid request saves the founder, selected specialist, time, format and request key
5. Test invalid boundary cases and show field-specific correction guidance

Scope boundary

A bounded deliverable within P17. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved state matrix; valid and boundary fixture results with exact expected/actual states

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

booking.1 · Preferred date and time
booking.2 · Save appointment request

Related screen and functional scope

Appointment screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p17-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each allowed transition has one durable result; conflicting bookings and unauthorised or repeated actions cannot change the wrong record.

Inputs required before starting

• P17.1 approved states
• authorised staff access

Start prerequisites

P17.1 P07.3

Ordered execution checklist

1. Retry a request with the same key and verify one request/receipt
2. Attempt a different account’s request and reject read/write/calendar access
3. Confirm one specialist slot and attempt a conflicting confirmation
4. Reschedule through the allowed state transition and release the old slot
5. Cancel through the authorised transition and verify it persists after refresh
6. Record rejected/unsupported transitions and client/staff notifications as real or simulated

Scope boundary

A bounded deliverable within P17. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Transition matrix execution log, duplicate/conflict proof and role-access test results

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

booking.1 · Preferred date and time
booking.2 · Save appointment request

Related screen and functional scope

Appointment screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p17-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Calendar files reproduce the saved appointment state, reminders have real delivery evidence, and no download implies an unaccepted booking.

Inputs required before starting

• P17.2 states
• P15.1 real alert path when required for the pilot

Start prerequisites

P17.2 P15.1

Ordered execution checklist

1. Export authorised calendar data and compare specialist, time zone, start/end, format and duration to the saved request
2. Label an unaccepted request/calendar invitation tentative and a confirmed meeting accurately
3. Check download MIME, escaping, cancellation/reschedule behavior and ownership
4. Send the approved reminder only for the intended state, recipient and consent
5. Retry delivery and verify saved receipts prevent duplicate alerts
6. Run founder and staff consultation journeys and obtain review acceptance

Scope boundary

A bounded deliverable within P17. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Sanitised calendar examples, saved-state comparison, reminder receipts and reviewed journey log

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If an input, approval, provider or expected result is missing, record the exact gap and decision/action owner; keep the relevant step open. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

booking.2 · Save appointment request

Related screen and functional scope

Appointment screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#p17-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A hosted preview serves all four entrances and its API reaches the cloud database.

Inputs required before starting

• Active cloud source and the existing registered private project.

Start prerequisites

No prerequisite work packages. The required inputs and readiness criteria are listed below.

Ordered execution checklist

1. Confirm the current deployment revision and four required paths.
2. Verify the reported page-loader routing repair against the published revision.
3. Build through the existing hosting workflow without starting a second deployment.
4. Apply pending cloud schema migrations once in the preview environment.
5. Open the hosted preview and record its revision, URL and storage status.

Scope boundary

A bounded deliverable within D01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Build/migration result and release revision.; Preview URL with route checks and redacted storage-status response.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If build, routing or database setup fails, record the failing step and owner; do not connect the live domain. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Deployment and recovery · Beth cloud

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d01-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

All promised guide assets work in preview and their access matches the approved inventory.

Inputs required before starting

• Working cloud preview, approved public/private asset inventory and guide files.

Start prerequisites

D01.1

Ordered execution checklist

1. List required guide pages, videos, captions and downloads with public/private classification.
2. Confirm the reported hosted uploads match approved guide versions; upload only an identified missing or changed approved asset.
3. Verify links, content types, video seeking and downloads in preview.
4. Check protected guides remain gated and public guides remain reachable.
5. Record missing or intentionally deferred files in the release notes.

Scope boundary

A bounded deliverable within D01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Asset inventory and upload receipts without publishing credentials.; Link/media checks including seeking and gated-download results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Missing required assets or incorrect exposure blocks this package; optional omissions need a visible limitation and reviewer agreement. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Deployment and recovery · Beth cloud

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d01-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The agreed cloud demo is live on beth2.top and its required journeys work without the Mac.

Inputs required before starting

• Preview acceptance evidence, release brief, configured domain and working rollback plan.

Start prerequisites

D01.1 D01.2 D02.1 D02.2 D02.3 D03.1 D03.2 D03.3 D04.2 D04.3 D06.1 D06.2 D06.3 D07.1

Ordered execution checklist

1. Confirm the exact accepted revision and unresolved limitations.
2. Save current domain/route configuration and identify the last working release.
3. Inspect the reported live revision/domain configuration and verify it matches the accepted release; change it only to resolve a verified mismatch.
4. Check HTTPS, canonical paths, legacy redirects and authenticated saves on the live hostname.
5. Record the live URL, revision and the rollback result or verified procedure.

Scope boundary

A bounded deliverable within D01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Preview acceptance sign-off and release revision.; Live hostname checks and redacted domain configuration change.; Rollback instructions tied to the published revision.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Do not connect live traffic if required preview checks fail; recover the prior route/release if live checks fail. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Deployment and recovery · Beth cloud

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d01-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Every tested private read, mutation and record download is tied to the current account; logout revokes access.

Inputs required before starting

• Cloud preview and two disposable accounts containing different records.

Start prerequisites

D01.1

Ordered execution checklist

1. Create account A and account B with distinct interviews, cases and requests.
2. Attempt A’s record IDs while signed in as B for reads and writes.
3. Check signed-out access to private API routes and record downloads.
4. Log out and verify the former session no longer authorizes requests.
5. Record expected denials and delete disposable test data where supported.

Scope boundary

A bounded deliverable within D02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Account-isolation test matrix with statuses and no personal credentials.; Redacted denial and logout results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Any cross-account exposure or unauthorized mutation blocks release until corrected and rechecked. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

access.1 · Sign in
access.2 · Create an account

Related screen and functional scope

Accounts and permissions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d02-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Private commercial assets and account exports remain protected across direct URLs; only the publishing credential authorizes guide uploads.

Inputs required before starting

• Preview, asset classification, decision access, publishing endpoint and two test accounts.

Start prerequisites

D01.1

Ordered execution checklist

1. Inventory decision pages, guide media, posters, captions and alternative/static file paths.
2. Attempt direct asset and legacy URLs without decision access; verify every private format is denied.
3. Attempt another account’s interview export and consultation calendar download.
4. Call publishing endpoints without a token and with an invalid token; check neither can alter assets.
5. Confirm approved public files work and document any intentional public information.

Scope boundary

A bounded deliverable within D02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Public/private asset map with no commercial amounts.; Direct-route, export/calendar and upload-denial test results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Unintended private exposure or unauthorized publishing blocks release; do not attach leaked content to the shared task. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

report.2 · Download, print or save

Related screen and functional scope

Accounts and permissions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d02-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Authentication and credential errors fail safely; configured limits work; secrets remain server-side and rotation steps are documented.

Inputs required before starting

• Preview with test credentials and authorized redacted configuration inspection.

Start prerequisites

D01.1

Ordered execution checklist

1. Test invalid login, duplicate registration, malformed form and oversized request responses.
2. Check repeated failed login and decision-unlock attempts trigger the configured limits.
3. Confirm HTTPS session cookies use HttpOnly, Secure and expected expiry; reject cross-origin mutations.
4. Inspect public assets, API responses and error logs for accidental credential or token exposure.
5. Verify a safe credential-rotation procedure is available for AI encryption and publishing access.

Scope boundary

A bounded deliverable within D02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Abuse/error test results with expected statuses.; Cookie/header checks and redacted secret-exposure review.; Rotation procedure containing credential names, never values.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Credential exposure, broken expiry, ineffective hosted login limits or accepted foreign-origin writes blocks release. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

access.1 · Sign in

Related screen and functional scope

Accounts and permissions

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d02-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Records persist correctly across cloud sessions and devices, with no dependence on the Mac database.

Inputs required before starting

• Preview with applied schema and a disposable account.

Start prerequisites

D01.1

Ordered execution checklist

1. Create an interview draft, saved chat and consultation request.
2. Sign out and reopen them in a new authenticated session.
3. Repeat from a second browser/device without relying on local draft storage.
4. Check record counts and values using account-scoped responses.
5. Record that existing local accounts remain separate and are not silently imported.

Scope boundary

A bounded deliverable within D03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Create/reopen result matrix and redacted record IDs.; Cloud storage status and fresh-account behavior notes.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Data loss, duplicate records or accidental local-data transfer blocks release and requires an explicit correction. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Collection readiness

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d03-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Stale changes never overwrite newer data; retries do not duplicate work; deleted chats stay deleted and drafts can be recovered.

Inputs required before starting

• Persisted test interview/chat and two tabs signed into the same account.

Start prerequisites

D03.1

Ordered execution checklist

1. Open the same study in two tabs and save a newer change in one.
2. Submit the stale tab and verify a visible conflict without overwriting newer data.
3. Interrupt a save and retry with the same request key.
4. Delete a test chat and replay a delayed save for its old client key.
5. Confirm unsaved text remains recoverable and record the recovery path.

Scope boundary

A bounded deliverable within D03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Conflict/retry/delete replay results with revisions.; Screenshots or recordings of draft-preservation messages.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Silent overwrite, duplicate mutation or resurrected deletion blocks release; preserve a sanitized reproduction. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Application features this work supports

history.2 · Recall or delete

Related screen and functional scope

Collection readiness

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d03-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Receipts are idempotent, submitted snapshots remain immutable and exports accurately represent only the authorized account’s data.

Inputs required before starting

• Account-owned interview with a draft and an existing submitted snapshot.

Start prerequisites

D03.1 D02.2

Ordered execution checklist

1. Submit a test interview and save its receipt and revision.
2. Retry the identical submission key and verify one receipt/snapshot.
3. Edit the draft and verify the earlier submitted snapshot is unchanged.
4. Export the review pack and compare owner, answers, revisions and submitted history.
5. Confirm exports identify inputs as candidates requiring review rather than approved training/publication.
6. Test missing consent, incomplete context and illustrative model-answer submissions; confirm rejection rather than real-evidence recording.

Scope boundary

A bounded deliverable within D03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Submission retry and snapshot comparison results.; Redacted sample export with field-completeness checks.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Mutable submissions, duplicate receipts, missing answers or incorrect ownership blocks release. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Collection readiness

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d03-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The selected connection mode is verified and accurately presented; any guided-only demo limitation is approved and visible.

Inputs required before starting

• Approved AI account/model and preview secret handling
• no secret values in task cards.

Start prerequisites

D01.1 D02.3

Ordered execution checklist

1. Confirm whether the demo uses shared cloud AI, per-account AI or guided preview only.
2. Record the approved model and who manages usage without storing credentials here.
3. Configure the permitted credential and encryption secret through protected settings.
4. Verify Connect AI, status and disconnect behavior for a test account.
5. Record any unavailable live-AI capability as a visible release limitation.

Scope boundary

A bounded deliverable within D04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Connection-mode decision and responsible role.; Redacted status/connect/disconnect results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If live AI is required but credentials or model access are unavailable, mark blocked and request the specific prerequisite; never imply AI is connected. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Beth AI connection · Model and evidence controls

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d04-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Accepted demo behavior is evidenced: live replies have usable authoritative sources when connected, and estimates follow scope confirmation; unavailable live AI is clearly limited.

Inputs required before starting

• Verified AI mode, curated test questions and expected authoritative sources.

Start prerequisites

D04.1

Ordered execution checklist

1. Run one Philippine business compliance question that requires web grounding when live AI is enabled.
2. Check returned citations point to allowed authoritative domains and support the reply.
3. Run a profiling example and inspect captured facts and risk flags.
4. Verify Beth asks for scope confirmation before showing an estimate.
5. Record pass/fail examples; for guided-only mode label live grounding unavailable rather than passed.

Scope boundary

A bounded deliverable within D04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted question/reply/citation examples and source-check notes.; Confirmation-before-estimate transcript and connection-mode label.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Unsupported citations or premature estimates blocks live-AI acceptance; guided-only release requires a clearly approved limitation. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Beth AI connection · Model and evidence controls

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d04-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

AI failures show useful recovery instructions, retain user work and accurately identify the active connection or fallback.

Inputs required before starting

• Preview AI configuration and safe simulations of provider failures.

Start prerequisites

D04.1

Ordered execution checklist

1. Test missing credential and rejected credential messages without exposing keys.
2. Exercise unavailable model, timeout and provider-limit responses using safe test methods.
3. Confirm drafts and conversation context remain recoverable after failure.
4. Check whether disconnect reverts to shared AI and make its displayed status accurate.
5. Record configured usage limits and who responds when they are reached.

Scope boundary

A bounded deliverable within D04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Missing/rejected/timeout/model/limit response matrix.; Draft-preservation and shared-fallback status results.; Usage responsibility note without billing amounts.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Secret-bearing errors, lost user work or misleading connection status blocks live-AI release. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Beth AI connection · Model and evidence controls

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d04-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A reviewed recovery plan states records, recovery targets, authorized owner and protected backup location.

Inputs required before starting

• Verified cloud data types and an identified operations contact.

Start prerequisites

D03.1

Ordered execution checklist

1. List interview drafts, submissions, saved cases, accounts and requests that need recovery.
2. Choose recoverable scope and maximum acceptable loss/downtime for the pilot.
3. Name the person or role authorized to back up and restore these records.
4. Separate credential recovery from ordinary review-pack exports.
5. Record how long test backups are retained and where access is restricted.

Scope boundary

A bounded deliverable within D05. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Recovery scope/owner/target checklist.; Access and retention decision, without credentials or personal records.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

If no authorized owner or protected location is agreed, keep pilot recovery blocked; do not call cloud hosting a backup. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Deployment and recovery

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d05-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A protected test backup contains the required records and a validated completeness manifest.

Inputs required before starting

• Approved recovery plan and disposable cloud test records.

Start prerequisites

D05.1 D03.3

Ordered execution checklist

1. Create representative interviews, submissions, cases and requests with known counts.
2. Use the approved backup/export procedure and record its timestamp/version.
3. Store the backup in the approved protected location.
4. Check that intended record types and ownership links are included.
5. Document missing items and rerun only after the procedure is corrected.

Scope boundary

A bounded deliverable within D05. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Backup timestamp/version and record-count manifest.; Protected-location confirmation and omitted-data list.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Incomplete backup or unapproved access blocks recovery acceptance; never upload raw user backups into shared tasks. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Deployment and recovery

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d05-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A reviewer observes successful restoration of the agreed records with correct ownership and a recorded recovery time.

Inputs required before starting

• Validated backup and an isolated recovery environment.

Start prerequisites

D05.2 D02.1

Ordered execution checklist

1. Create an isolated restore destination without overwriting the current release.
2. Restore using the written procedure and time the recovery.
3. Compare record counts, ownership, drafts and immutable submission history.
4. Verify restored-account access while keeping credentials protected.
5. Record recovery results and update the operator instructions.

Scope boundary

A bounded deliverable within D05. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Restore log and before/after manifest without personal contents.; Restored-access and snapshot checks.; Updated recovery runbook and owner acceptance.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Do not run destructive recovery against live data; failed restoration blocks production pilot recovery sign-off. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Deployment and recovery

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d05-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Required entrances and guide journeys work at desktop/mobile sizes with correct links and usable media.

Inputs required before starting

• Cloud preview with guide assets and route mapping.

Start prerequisites

D01.1 D01.2

Ordered execution checklist

1. Visit home, /chat, /interview, /docs and /cases on desktop and mobile.
2. Follow guide and legacy links and verify their final destinations.
3. Check text readability, form controls and downloads at a narrow viewport.
4. Play the intended guide video, enable captions and inspect transcript access.
5. Record any dead link, clipped control or inaccessible required guide.

Scope boundary

A bounded deliverable within D06. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Route/link matrix with preview revision.; Desktop/mobile screenshots and required media results.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Broken required paths or unusable core controls blocks demo release; cosmetic issues may remain with explicit tracked scope. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

All application screens · End-user guide

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d06-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

One complete demo journey works, retains the right data and makes the boundary between saved requests and real delivery clear.

Inputs required before starting

• Preview, reviewed example, configured AI mode and disposable customer account.

Start prerequisites

D03.3 D04.2

Ordered execution checklist

1. Complete the example interview and submit/export its answers.
2. Ask Beth a business question using the accepted connection mode.
3. Confirm the profiled scope and review the indicative estimate without treating it as a final quote.
4. Generate, download and print the report; compare it with the confirmed facts, scope and displayed assumptions.
5. Save/reopen the case and request a specialist consultation.
6. Verify specialist acceptance, notifications and booking status remain correctly labeled as simulations or saved requests.

Scope boundary

A bounded deliverable within D06. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Redacted journey recording or checklist.; Case/request IDs and simulation-label screenshots.; AI connection-mode note for the example.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Data loss, an impossible promised action or a simulated action presented as real blocks demo acceptance. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

All application screens · End-user guide

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d06-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Recoverable failures preserve work and give clear next actions; unavailable services never appear as successful completion.

Inputs required before starting

• Preview and approved non-destructive fault tests.

Start prerequisites

D01.1 D03.2 D03.3

Ordered execution checklist

1. Exercise expired sign-in while editing and verify the draft remains recoverable.
2. Simulate storage unavailability and an interrupted save without modifying live services.
3. Check oversized and malformed requests produce clear messages.
4. Exercise missing guide media and unknown paths; avoid misleading success screens.
5. Verify retry/sign-in/reopen instructions return users to a usable state.

Scope boundary

A bounded deliverable within D06. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Auth/storage/request/media failure matrix.; Draft-retention and recovery screenshots/notes.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Lost drafts or false-success submission messages block demo release; only use isolated test faults. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

All application screens · End-user guide

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d06-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A reviewer can determine what the demo does, what remains simulated and exactly which verified revision may be released.

Inputs required before starting

• Preview acceptance results and the agreed demo scope.

Start prerequisites

D06.1 D06.2 D06.3

Ordered execution checklist

1. List working entrances and tested user journeys.
2. Explain that cloud accounts are fresh and local records remain on the Mac.
3. List guided/live AI mode, simulations and known omissions.
4. Attach release checks and link unresolved work without private commercial details.
5. Record reviewer acceptance for the demo and the revision to release.

Scope boundary

A bounded deliverable within D07. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Demo release brief and acceptance record.; Links to preview QA evidence and tracked limitations.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

No demo sign-off while required acceptance fails or scope is misleading; do not wait for every production pilot enhancement. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Delivery and handover

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d07-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The operator can identify an unhealthy release and follow a tested response path without exposing user data or secrets.

Inputs required before starting

• Live release and an agreed operator
• recurring automation only if separately authorized.

Start prerequisites

D01.3

Ordered execution checklist

1. Identify the published version, required URLs and protected status endpoints.
2. Define simple checks for routes, storage, sign-in and AI availability.
3. Document where the operator sees errors using redacted logs.
4. Record who responds to unavailable storage, AI limits and failed uploads.
5. Run one manual status check and one safe response rehearsal; link the rollback guide.

Scope boundary

A bounded deliverable within D07. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Status/check matrix and operator role.; Redacted manual check/rehearsal results and response guide.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Without an operator or a way to detect service failure, mark operational handoff pending; do not silently create recurring monitors. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Delivery and handover

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d07-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The pilot decision is supported by evidence and states allowed users/functions, operational owners and remaining blockers.

Inputs required before starting

• Verified demo, recovery evidence, operating guide and candidate pilot participants.

Start prerequisites

D01.3 D05.3 D07.2 P11.2 P15.1 P15.3 P16 P17

Ordered execution checklist

1. List which demo functions will be real or explicitly disabled for the pilot.
2. Confirm reviewed knowledge/service rules, operator responsibilities and consultation follow-up expectations.
3. Confirm participant notice, access and retention choices for actual customer data.
4. Review backup recovery, AI usage responsibility and unresolved blocking defects.
5. Record go/no-go and create a linked action for each unmet condition instead of claiming production readiness.

Scope boundary

A bounded deliverable within D07. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Pilot scope and go/no-go decision.; Recovery and operation evidence links.; Tracked unmet conditions with responsible roles.

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Unreviewed domain advice, unowned customer follow-up or unproven required recovery blocks the relevant production pilot scope, not the labeled demo. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Delivery and handover

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#d07-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Every newly included journey/service/package has reviewed evidence and a versioned inclusion decision; old quotes remain replayable.

Inputs required before starting

• Approved P12.1 expansion list and pilot outcome evidence

Start prerequisites

P12.1 P11.3

Ordered execution checklist

1. Confirm the approved subset and target catalogue counts from the broader plan
2. Complete source-backed service cards, units, prerequisites, exclusions and accountable owners
3. Compose the approved expanded packages and remove overlapping shared work
4. Define migration/version compatibility with saved pilot quotes and cases
5. Review sample scopes and obtain domain/product approval before publishing draft entries

Scope boundary

A bounded deliverable within L01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved expansion register, service/package evidence and quote compatibility results

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Expanded catalogue · Language refinements

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l01-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each included advanced route has reviewed deterministic scope and safe human escalation; excluded cases are not priced as ordinary pilot work.

Inputs required before starting

• L01.1 service scope and reviewed source applicability

Start prerequisites

L01.1 P04.3 P05.3 P06.3

Ordered execution checklist

1. Define VAT, payroll, inventory, multiple-entity and foreign-founder route facts for the approved expansion
2. Obtain domain/counsel decisions for consequential or unsupported scope boundaries
3. Implement question, eligibility, service-unit and escalation rules from those decisions
4. Test qualifying, missing-input, ambiguous and out-of-scope variants
5. Verify estimates, specialist filters and source applicability against each approved route

Scope boundary

A bounded deliverable within L01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved route/risk matrix, source-linked rules and expected/actual route tests

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Expanded catalogue · Language refinements

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l01-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Supported language variants preserve the approved business decisions and citations; every newly activated source/model passes the agreed regression gate.

Inputs required before starting

• Approved language list and L01.2 routes

Start prerequisites

L01.2 P11.2

Ordered execution checklist

1. Approve English/Filipino/Taglish scenarios and domain terminology with reviewers
2. Create held-out translated/paraphrased variants without changing the intended facts
3. Compare citation support, question burden, scope and estimates across supported language variants
4. Test each new source family and model version on the same labelled cases
5. Publish only approved language/source/model configurations with rollback references

Scope boundary

A bounded deliverable within L01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Frozen language suite, reviewed comparison results and configuration/release record

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Expanded catalogue · Language refinements

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l01-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each approved real channel reaches the correct retained case, respects human ownership and exposes delivery failures without duplicate tickets.

Inputs required before starting

• Approved P12.2 provider/channel selections and account access

Start prerequisites

P12.2 P09.3 P16.3

Ordered execution checklist

1. Confirm provider approvals, channel permissions, credentials and allowed message types
2. Configure the approved inbox integrations and map channel identities to authorised founders
3. Route new and resumed messages to the correct case and staff owner
4. Test duplicate/reordered webhooks, unavailable staff and delivery failure
5. Verify takeover/return-to-Beth and consented sharing on each added channel

Scope boundary

A bounded deliverable within L02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Identity/event mapping, real-channel proof, takeover tests and redacted retry receipts

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Channels · Calendar · Babylon adapter

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l02-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Accepted appointments and provider events agree; conflicts/retries cannot create extra reservations and a failed provider action remains recoverable.

Inputs required before starting

• Approved calendar/provider actions and P17 appointment rules

Start prerequisites

P12.2 P17.3 P14.3

Ordered execution checklist

1. Approve required availability/read/write permissions and per-user calendar connections
2. Map appointment IDs, time zones, durations and accepted booking states to calendar events
3. Recheck specialist availability before confirmation and store the provider receipt
4. Synchronise approved reschedules/cancellations with recorded ownership and consent
5. Test expiry/revocation, webhook replay, conflicts and provider outages with a manual fallback

Scope boundary

A bounded deliverable within L02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Contract/state mapping, real provider receipts and conflict/replay/revocation test log

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Channels · Calendar · Babylon adapter

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l02-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

One approved real adapter transfers the correct authorised data exactly once and reconciles state; catalogue existence is not treated as working integration.

Inputs required before starting

• Approved Babylon API contract, access and sandbox data

Start prerequisites

P12.2 P07.3 P08.3 P14.3

Ordered execution checklist

1. Approve directory/job identifiers, schema, version and system-of-record ownership
2. Map specialist capability/capacity and accepted scope/job status without inferred defaults
3. Authorise each read/write and save stable request/provider receipt identifiers
4. Test incomplete/stale records, conflict updates, timeouts and duplicate requests
5. Reconcile one end-to-end job and preserve an explicit manual path for unresolved integration gaps

Scope boundary

A bounded deliverable within L02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved contract/mapping, sandbox or real action receipts, reconciliation and failure results

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Channels · Calendar · Babylon adapter

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l02-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

An approved state/timer/receipt contract covers normal, no-response, rejected, cancelled and failed branches without unnamed decisions.

Inputs required before starting

• P12.3 selected lifecycle and actual manual-case outcomes

Start prerequisites

P12.3 P08.3 P13.1

Ordered execution checklist

1. Select one bounded lifecycle and define state transitions and authorised actors
2. Specify document waits, approval deadlines, reminder intervals, cancellation and exception rules
3. Define stable case/workflow/action IDs, receipts and duplicate-handling behavior
4. Separate fast conversational replies from the durable case execution path
5. Approve retention, operator override, failure escalation and recovery expectations

Scope boundary

A bounded deliverable within L03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Reviewed state diagram/table, timer policies, action contract and exception ownership

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Durable case lifecycle

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l03-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The bounded workflow executes the contract with persisted receipts and version-compatible workers; chat remains on its intended fast path.

Inputs required before starting

• L03.1 approved contract
• approved workflow platform access

Start prerequisites

L03.1 L02.2 L02.3

Ordered execution checklist

1. Adopt the workflow platform selected in the approved broader architecture
2. Implement waits, approvals, reminders and fulfilment activities against saved case versions
3. Make each external activity consult/save its receipt before retrying
4. Expose pending/failed work and permitted operator actions in the case portal
5. Pin worker/workflow versions and test compatibility across a controlled upgrade

Scope boundary

A bounded deliverable within L03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Pinned workflow/worker artefacts, state/receipt proof and upgrade test results

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Durable case lifecycle

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l03-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Reviewed failure drills restore the right case state without duplicate actions; unresolved exceptions retain an owner and a reproducible recovery path.

Inputs required before starting

• L03.2 implementation and isolated test environment

Start prerequisites

L03.2 D05.3

Ordered execution checklist

1. Stop a worker during document wait and an external action, then resume it
2. Replay duplicate signals, callbacks and timed reminders
3. Test approval rejection, cancellation, late documents and operator override
4. Reconcile workflow state, provider receipts, case status and retained ownership
5. Measure recovery against the approved target and have operations follow the written runbook

Scope boundary

A bounded deliverable within L03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Fault/replay matrix, before/after states, receipts, measured recovery and operator review

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Durable case lifecycle

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l03-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Reviewed analytics reproduce underlying job evidence and clearly distinguish measured, estimated and missing outcomes.

Inputs required before starting

• P11.3 pilot outcome contract and approved broader metrics

Start prerequisites

P11.3 L01.1 L02.3

Ordered execution checklist

1. Approve metrics for quoted/actual effort, rework, scope changes, conversion and quality
2. Link each outcome to saved case, quote/rule/source/release versions
3. Implement authorised aggregation without exposing individual confidential records
4. Reconcile dashboard totals against representative job records and missing-data cases
5. Submit proposed rule/capacity changes for review rather than auto-editing prices

Scope boundary

A bounded deliverable within L04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved metric definitions, reconciliation results, permission checks and reviewed improvement proposals

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Outcome analytics · Expanded QA and load tests

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l04-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Measured results support an approved broader capacity envelope, with unresolved limits explicitly gating the affected scope.

Inputs required before starting

• Stable broader candidate and approved test thresholds/workload

Start prerequisites

L01.3 L02.1 L03.3 P15.3

Ordered execution checklist

1. Confirm the proposed 2,000 monthly active founders and 100 simultaneous-session envelope or an approved replacement
2. Approve meaningful latency/error/spend/recovery thresholds before testing
3. Run representative chat, source, file, save, handoff and durable-case traffic
4. Include cross-business permission attempts, provider/source failures and retry pressure
5. Record bottlenecks, limits and corrective defects; retest only affected failures

Scope boundary

A bounded deliverable within L04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Approved workload/threshold plan, measured results, defects/retests and capacity decision

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Outcome analytics · Expanded QA and load tests

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l04-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A named release authority approves only the evidenced scope and operating limits; staged validation and rollback proof precede expansion.

Inputs required before starting

• Broader feature, analytics, capacity and recovery evidence

Start prerequisites

L04.1 L04.2 L03.3

Ordered execution checklist

1. Reconcile feature coverage, required approvals and all open blocking defects
2. Review source/model regressions, role permissions, consent/retention and real channel/booking receipts
3. Confirm incident, specialist follow-up, backups and provider/edition responsibilities
4. Approve staged users/features, stop criteria and rollback/recovery versions
5. Record launch decision and verify the first stage before expansion

Scope boundary

A bounded deliverable within L04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Signed release checklist/decision, scoped rollout record and rollback/recovery rehearsal

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

P12 approval, missing provider permissions, unresolved policy or failed expected behavior blocks the affected implementation. Record the exact missing input, decision/action owner and next checkpoint. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Outcome analytics · Expanded QA and load tests

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#l04-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Both developers use one versioned schema; all three prototype facts, corrections and errors have examples.

Inputs required before starting

• Existing backend prototype brief and interface consumer

Start prerequisites

No prerequisite work packages. The required inputs and readiness criteria are listed below.

Ordered execution checklist

1. Write request fields for chat/session ID, message and prior confirmed facts
2. Define response fields for reply, collected facts, missing fields and errors
3. Use the fictional online-shop scenario to create complete and missing-field fixtures
4. Confirm correction/reset/session isolation semantics with the interface developer
5. Have both developers approve the schema and publish runnable example calls

Scope boundary

A bounded deliverable within B01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Versioned schema, four fixture request/response pairs and both developers’ review record

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Conversation engine

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b01-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Complete, missing-field, correction and reset fixtures return expected state without cross-session leakage.

Inputs required before starting

• Approved B01.1 schema
• candidate Langflow access

Start prerequisites

B01.1

Ordered execution checklist

1. Build the bounded candidate flow and record its version
2. Retain support requested, monthly order volume and record format per session
3. Ask only for fields not already supplied
4. Apply a corrected value without erasing other confirmed fields
5. Reset one session and prove a second session is unaffected
6. Return the agreed response schema and record candidate limitations

Scope boundary

A bounded deliverable within B01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Runnable flow export/code, fixture outputs and limitations log

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Conversation engine

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b01-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

A reviewer can reproduce the demonstration from the handoff and trace each result to the agreed schema.

Inputs required before starting

• B01.2 runnable build and fixtures

Start prerequisites

B01.2

Ordered execution checklist

1. Write setup/version/configuration instructions without credentials
2. Provide sample calls for all agreed fixture scenarios
3. Run from a clean test setup with a second developer
4. Record expected versus actual responses and defects
5. Demonstrate the flow and obtain review against the parent card’s outcome

Scope boundary

A bounded deliverable within B01. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Setup guide, version, test log, demo link and review outcome

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Conversation engine

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b01-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Selected adapter displays every fixture accurately; limitations and fallback choice are explicit.

Inputs required before starting

• B01.1 schema
• frontend assessment

Start prerequisites

B01.1

Ordered execution checklist

1. Confirm message, fact-panel and error mappings to B01.1
2. Create mock complete/missing/correction/reset responses
3. Try the scoped CopilotKit / AG-UI candidate with the same fixtures
4. Record transport limitations and select one adapter for this prototype
5. Publish the adapter mapping and implementation decision

Scope boundary

A bounded deliverable within B02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Mapping, adapter proof, fixtures and reviewed transport decision

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Chat screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b02-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

The customer sees the latest three facts; loading/error/reset cases are predictable and do not lose unrelated data.

Inputs required before starting

• B02.1 selected adapter and fixture mapping

Start prerequisites

B02.1

Ordered execution checklist

1. Render accumulated messages with usable scrolling
2. Display support requested, order volume and record format in the customer panel
3. Update only the corrected fact and preserve the remaining facts
4. Show loading and prevent duplicate sends
5. Show response errors while retaining input and prior conversation
6. Reset conversation and panel together and check desktop/mobile usability

Scope boundary

A bounded deliverable within B02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Runnable interface, fixture screenshots and expected/actual UI checklist

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Chat screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b02-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

All prototype UI cases have reproducible results; mock demonstrations are never reported as live integration success.

Inputs required before starting

• B02.2
• real backend if available

Start prerequisites

B02.2 B01.2

Ordered execution checklist

1. Run the four agreed scenarios with mocks
2. Connect B01.2 when available and repeat the same scenarios
3. Record whether each result is mock-backed or backend-backed
4. Reproduce and log defects with environment and input
5. Publish setup instructions and a short reviewed demonstration

Scope boundary

A bounded deliverable within B02. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Versioned setup, test log with environment, defects and demo/reviewer decision

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Chat screen

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b02-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

There is one reviewed summary schema and a documented reuse decision without importing Alpha pricing or eligibility rules.

Inputs required before starting

• RFQ Alpha assessment and prototype brief

Start prerequisites

B01.1

Ordered execution checklist

1. Inspect the assessment for retained-state and missing-field patterns
2. Choose adapt/rebuild for each pattern and record the reason
3. Define support requested, monthly order volume and record format with explicit unknowns
4. Agree the structured summary with the backend developer
5. Label the fields as prototype examples rather than approved service rules

Scope boundary

A bounded deliverable within B03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Assessment notes, schema, fixtures and reviewed reuse decision

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Profile confirmation

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b03-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Incomplete and corrected requests produce the expected latest facts with no fabricated field values.

Inputs required before starting

• B03.1 approved schema

Start prerequisites

B03.1

Ordered execution checklist

1. Load known answers and preserve unknown fields explicitly
2. Ask for one missing field without repeating supplied information
3. Update the relevant field when the customer corrects an answer
4. Preserve the rest of the summary after a correction
5. Return the latest structured summary and implement a clean reset

Scope boundary

A bounded deliverable within B03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Runnable code/configuration and scenario inputs/outputs

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Profile confirmation

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b03-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Another person can reproduce the example and determine the latest answers without relying on the author’s explanation.

Inputs required before starting

• B03.2 runnable example

Start prerequisites

B03.2

Ordered execution checklist

1. Write setup and execution instructions
2. Run complete, missing-field, correction and reset cases
3. Check outputs against the approved summary schema
4. Record adapted versus rebuilt logic and known gaps
5. Have QA reproduce the cases and record acceptance or defects

Scope boundary

A bounded deliverable within B03. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Version, instructions, result log and QA review

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Profile confirmation

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b03-3

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Every populated service field has a retrievable source; inferred and disputed requirements are clearly marked unapproved.

Inputs required before starting

• Source access from the project’s source-material owner

Start prerequisites

No prerequisite work packages. The required inputs and readiness criteria are listed below.

Ordered execution checklist

1. Select one service from existing catalogue/interview material
2. Record source ID, version/date and exact location for each populated field
3. Extract required customer information, scope, exclusions and handoff destination
4. Separate stated facts from inference and unresolved gaps
5. Ask the service owner to review missing or conflicting material

Scope boundary

A bounded deliverable within B04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Structured service record, source locator table and gap/review log

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Knowledge and evidence · Interview examples

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b04-1

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Each test has fixed input, pre-state, expected reply/state and pass/fail criterion; actual results cannot redefine the expectation.

Inputs required before starting

• B01.1 and B03.1 schemas

Start prerequisites

B01.1 B03.1

Ordered execution checklist

1. Prepare a fictional request with all three prototype fields
2. Prepare a request missing one field and identify the required follow-up
3. Prepare a corrected earlier answer and the expected retained state
4. Prepare a reset case with an explicit empty-session expectation
5. Review expected outputs with the developers before running tests

Scope boundary

A bounded deliverable within B04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Reviewed test matrix with complete/missing/correction/reset fixtures

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Knowledge and evidence · Interview examples

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b04-2

Source revision: 2026-10-09.1 · Draft — requires product and reviewer approval

Outcome and definition of done

Every available prototype has recorded results; missing builds and unresolved failures are visible and reproducible.

Inputs required before starting

• B04.2 expected results
• developer runnable handoffs

Start prerequisites

B01.3 B02.3 B03.3 B04.2

Ordered execution checklist

1. Record backend, frontend and intake build versions and availability
2. Run each scenario against each available prototype
3. Record expected and actual output with evidence
4. Mark unavailable builds as blocked/not tested rather than passed
5. Give each defect reproduction steps, severity and proposed owner
6. Retest fixes and publish the reviewed result summary

Scope boundary

A bounded deliverable within B04. Changes to adjacent work require the accountable scope owner’s decision.

Acceptance evidence to deliver

Test log, defects, retest evidence and reviewer decision

Attach the exact artifact/version, expected-versus-actual results and evidence links. The designated reviewer records a dated acceptance decision. Checked boxes alone do not establish completion.

If blocked

Record the unavailable input/build/decision, exact failing step, responsible role and next action. Unavailable or not-run checks cannot pass. Set Stage to Blocked and record the exact failing step, missing decision/input, responsible role and next action in Blocker / decision needed.

Related screen and functional scope

Knowledge and evidence · Interview examples

Progress and review record

Source revision; completed step numbers; exact deliverable version and evidence links; expected versus actual results; remaining steps; blocker and decision owner; next action and checkpoint; reviewer handoff.

Direct source reference: beth2.top/scope#b04-3