--- status: demonstration audience: public-demonstration fixture: kibble-and-co (fictional) --- # 8. Scope Boundary & Engagement Model This section is normative for the bid. It defines what is being purchased, what is explicitly deferred, which product policies are already decided, and how requirement changes are governed once the engagement starts. A bid that silently redraws any boundary in this section is treated as out of scope for the fixed bid on that item. ## 8.1 Engagement premise 1. **Kibble & Co. owns the requirements.** The requirements summarized in this package (28 epics, 218 stories with per-story acceptance criteria) are the contractual statement of scope. The vendor's role during bid preparation is to **validate and tighten** — challenge feasibility, flag ambiguity, propose sharpening — not to re-derive requirements from first principles. 2. **There is no billed discovery phase.** Questions raised during bid preparation are answered from this package, the requirements export, and bounded Q&A sessions with Kibble & Co.'s product and technical owners (see 8.7). Vendor effort to understand the problem space before contract signature is bid diligence and is carried by the vendor. 3. **The bid is fixed-scope against the MVP phase** (see 8.2), with later phases priced as separately exercisable options (see 8.3). 4. **Commercial terms are handled separately** by Kibble & Co.'s procurement team. Outcome-based incentive structures (delivery bonus / holdback mechanics) are under consideration; this package deliberately contains no commercial figures. ## 8.2 In scope — initial engagement (MVP phase) The initial engagement delivers every story tagged **MVP** in the work-breakdown register ([07-work-breakdown.md](07-work-breakdown.md)) — approximately 104 of the 218 stories, spanning all ten capability domains — built natively on Kibble & Co.'s existing BigCommerce storefront. In addition to the story scope itself, the engagement includes: - **Solution architecture** for the native build, including a written position on every platform-integration decision point enumerated in [05-platform-integration-contract.md](05-platform-integration-contract.md) §5.2. - **Test strategy and evidence** meeting the acceptance bar in [06-non-functional-requirements.md](06-non-functional-requirements.md) §6.9 — each NFR category carries a named verification method and delivered evidence. - **Demonstration against the user journeys** in [03-user-journeys.md](03-user-journeys.md): each journey runs end-to-end in a pre-production environment as part of acceptance. - **Documentation**: store-admin help content for Kibble & Co.'s operations team, developer-facing docs (API reference for the Platform-domain surfaces), and runbook-level operational docs. - **Knowledge transfer** sufficient for Kibble & Co.'s engineering team to own the capability after handover (see 8.6/8.7; the KT plan is a scored bid deliverable per [09-estimation-scaffold.md](09-estimation-scaffold.md)). ## 8.3 Deferred scope — priced options, not silent inclusions Stories tagged **P1**, **P2**, and **P3** in the register are out of the initial fixed-scope build. Bids must price them as options at the domain level so Kibble & Co. can exercise them without renegotiating from zero. Headline deferred items (the register is authoritative): | Deferred item | Phase tag | Note for estimators | |---|---|---| | Migration tooling from incumbent subscription apps | P1/P2 | Highest-value fast-follow; option should be priced with its own timeline | | Additional processor adapters beyond the initial rail set | P2 | Gateway matrix in 05 §5.4 defines the landscape | | Multi-storefront / channel-scoped plans | P2 | | | Customer-group–scoped plans; prepaid / fixed-term subscriptions | P2 | | | SMS notifications; marketing-platform integrations | P2 | | | Cancel-flow experimentation (A/B) and intervention analytics | P2 | | | B2B account support (company accounts, approvals, PO-based billing) | P3 | Distinct persona surface; see Epic 24 | | Build-a-box / bundle subscriptions | P3 | | | Usage-based billing primitive | P3 | Scoped separately by Kibble & Co.; do not price here | | White-label subscriber portal (custom domain, full theming) | P3 | | Anything not present in the written requirements is out of scope entirely and enters only through change control (8.5). ## 8.4 Decided product policies — not open for re-litigation The following behaviors look like open design questions but are **already decided** — most in story acceptance criteria, the remainder as recorded product-policy decisions Kibble & Co. made before bid issuance (noted per item). Bids should treat them as fixed inputs; proposals to revisit them belong in change control, with an impact statement. 1. **Price drift at renewal** — default: current catalog price wins at renewal; merchant-configurable lock-at-creation alternative (a Catalog-domain story in the work breakdown). 2. **Inventory conflict at renewal** — merchant-configurable policy: allow (continue/backorder), skip the cycle, substitute a configured alternate variant, or pause the subscription (Orders-domain stories in the work breakdown, including a proactive pre-renewal scan and a merchant resolution flow). 3. **Tax recalculation** — always recalculated at renewal from the current address; an address change mid-subscription triggers recalculation at the next cycle. 4. **Multi-currency** — plan prices are denominated in Kibble & Co.'s store default currency; presentment-currency conversion happens at display time only. (A recorded product-policy decision rather than a story AC — the vendor's solution design states how it is honored.) 5. **Data deletion** — platform customer deletion cascades: subscription PII is hard-deleted; only anonymized revenue records are retained. Charge records required for financial/legal retention survive with subscription state closed. 6. **Platform API budget discipline** — renewal processing must respect platform rate limits by design (scheduling jitter / queued spreading), not by retry-storm. 7. **Raw card data** — the system never touches it. All recurring charges ride the stored-instruments vault rail (05 §5.3). This is a hard architectural constraint, not a preference. ## 8.5 Requirements change control - **Single product owner.** Kibble & Co. names one accountable requirements owner; all scope communication routes through them. The vendor names one accountable delivery owner as the counterpart. - **Changes are written, story-addressed, and priced.** Any change — including vendor-discovered gaps, ambiguities, or "we found more than expected" — is logged as a written change proposal against specific US-IDs, with schedule and cost impact stated, and is not worked until approved. Discovery of a gap is never, by itself, authorization to expand scope. - **Ambiguity resolution is free; scope expansion is not.** Where a story's AC is ambiguous, the product owner's written clarification binds both parties at no cost change. Where a clarification genuinely adds behavior, it is a change proposal like any other. - **The reference implementation settles behavior disputes** in the first instance ([10-reference-prototype.md](10-reference-prototype.md)): where written AC and observed prototype behavior diverge, the written AC governs, and the divergence is flagged to Kibble & Co.'s product owner for disposition. ## 8.6 What the vendor owns - Native solution architecture on the BigCommerce platform, including the 05 §5.2 decision points, subject to Kibble & Co.'s architectural approval. - Delivery plan, staffing, and internal tracking (seeded from the requirements export; story identity — US-IDs — must be preserved in the vendor's tracker so acceptance maps 1:1). - Engineering quality: production-grade code, test coverage per 06, operational readiness (observability, runbooks, failure-mode documentation). - Knowledge transfer execution per the KT plan committed at bid time. ## 8.7 What Kibble & Co. owns - Requirements, prioritization, and acceptance sign-off at every phase gate. - Platform access: sandbox store, API credentials, pre-production environments, and internal escalation paths to Kibble & Co.'s own IT and product teams. - Bounded SME availability: scheduled architecture/product Q&A cadence (expected weekly during solution design, tapering during build) — not embedded full-time staff, and not an open-ended interview program. - Timely turnaround on clarifications and change-proposal dispositions, so vendor idle time is not a cost lever against Kibble & Co. ## 8.8 Acceptance & definition of done A story is done when its acceptance criteria pass in a pre-production environment against a real BigCommerce store, with evidence retained. The engagement is done when: 1. Every MVP-phase story passes its ACs. 2. Every NFR category carries delivered evidence per 06 §6.9. 3. Every journey in 03 demonstrates end-to-end, including the renewal and decline/dunning system journeys against real (sandbox) payment rails. 4. The system demonstrably instruments the operational health measures the product defines for launch readiness — charge success rate, dunning recovery rate, reconciliation drift (target <1% inconsistent state across system ↔ platform ↔ processor), and subscriber self-service resolution — such that Kibble & Co. can operate against them from day one. (Commercial launch outcomes themselves are Kibble & Co.'s accountability, not the vendor's.) 5. Knowledge transfer is delivered and accepted by the receiving Kibble & Co. engineering team. --- Kibble & Co. is a fictional demo merchant. This package is an independent demonstration by Nino Chavez of a scoping method — not a BigCommerce product, and not a real procurement.