Phase 0 · Foundation Assessment — BEA-08 Amazon NIS Automation

The permanent base layer (FAD). Establishes success criteria, the decision-maker's real incentives, the constraint envelope, scope, and the assumptions every later phase is built on. Written to be consistent with — and load-bearing for — Phases 1–5 and the Decision Gate (Refine, Architecture A, executability 74).

Problem in one line (from manifest): Auto-populate the 22-file New Item Setup (NIS) package per Amazon launch from PIM/DAM. Category: Production Automation. Build type: backend-automation. Owner: Jaclyn Kreidstein. Proprietary: no.

1. Success criteria (measurable, time-bound)

• [ ] Measure before build (the load-bearing number). Within 30 days of project start, complete a time-and-motion study on ≥3 real Beats NIS launches that fixes three priors to within a stated confidence interval: (a) true coordinator hours per 22-file package, (b) the transcription/formatting fraction of those hours (the only part any of A/B/C automates), and (c) true launch cadence (packages/year). Pass condition: transcription fraction and cadence are measured, not estimated, and the denominator scope (one team vs. many) is resolved. This criterion gates every other one — if transcription is ~35% of effort on a genuinely single-team ~$17K/yr pool, the correct outcome is "do not build," and that is a success of the methodology, not a failure.
• [ ] Cycle-time reduction on the automated slice. For the shipped architecture, reduce coordinator hours per NIS package by ≥40% versus the measured manual baseline within 90 days of go-live, measured over ≥5 launches. (Architecture A's synthetic model claims ~55% of effort is automatable transcription; the 40% threshold leaves margin for review overhead and is falsifiable against the time-and-motion baseline.)
• [ ] Reduce Amazon ingest rejections. Cut the per-package Amazon ingest-rejection rate from the measured manual baseline (synthetic prior: ~18%) to ≤8% within 6 months / ≥10 launches of go-live, attributable to the three named failure modes (missing files, mid-run source drift, cross-file field mismatch). Pass condition: rejection rate trend is tracked per package and the reduction is statistically distinguishable from baseline noise.
• [ ] Forcing-function correctness guardrail (not just speed). Before go-live, the shipped tool must include diff-highlighting of changed-vs-prior values, a per-file sign-off log, and a sampled independent reconciliation of ≥1-in-N shipped packages against PIM ground truth by a second person. Pass condition (ongoing): zero "wrong-but-consistent" values reach a live Beats listing across the first 6 months; any that do trigger a reconciliation-rule update. Without this, faster generation just ships wrong listings faster (Boyd-Quist / Velury).
• [ ] Sustainability / no-rot guarantee. A named, funded maintenance owner for the template set (or slot registry) exists at go-live, with a quarterly revalidation against the current Amazon NIS spec. Pass condition: owner named in the runbook and a revalidation occurs within the first quarter. Pharma analog (Velury): an unowned registry rots in ~9 months regardless of build quality.

2. Decision-maker profile (Three Ledgers)

• Public ledger (what we pitch): "Eliminate the manual, error-prone hand-assembly of the 22-file Amazon NIS package by auto-populating it from data that already lives in PIM/DAM — faster launches, fewer launch-day Amazon rejections, an auditable trail of where every value came from."
• Shadow ledger (what the decision-maker actually optimizes for): Jaclyn owns Beats Amazon launch outcomes, so her real optimization target is no launch-day fire drills and no brand-damaging wrong listing on a Beats ASIN — predictability and reputational safety, not raw hours saved. A secondary shadow goal is headcount/credibility defense: a tool that visibly de-risks her launches strengthens her team's standing; a tool that ships a wrong price/dimension/claim to a live listing is a career-negative event far larger than the ~$17K labor pool. This is why she will tolerate a cheap, human-gated tool (A) over a clever-but-fragile one (B/C) — the downside of automation error dwarfs the upside of speed.
• True ledger (what will actually get built, absent intervention): A script-based mail-merge over a frozen PIM/DAM export (Architecture A) with 22 tokenized templates and a completeness checklist — but only if the time-and-motion study confirms the value pool, and only with the human-review forcing function baked in. The realistic risk is that what actually ships is a thinner A (templates for the high-volume files only, manual review without diff-highlighting), which silently degrades into "rubber-stamp 22 green checkmarks under deadline" — a faster wrong-package generator. The forcing-function success criterion exists precisely to prevent the True ledger from drifting below the Public ledger.
• Owner / sponsor: Jaclyn Kreidstein (manifest owner). Sponsor for funding/headcount sign-off is her management chain; the user is the frontline catalog coordinator (the Boyd-Quist persona), whose disengagement under launch pressure is the single biggest threat to the correctness value.

3. Constraint inventory

4. Scope boundary

• In scope:
  • Auto-populating the 22-file Amazon NIS package for a Beats product launch from existing PIM (master/copy/attributes) and DAM (imagery/assets) data.
  • Transcription, per-file template formatting, and cross-file consistency-checking — the labor the manual process spends today.
  • A completeness gate on source data before assembly, and a human-review forcing function (diff-highlighting, sign-off log, sampled reconciliation) on the output.
  • Producing a frozen, versioned snapshot of the source data at assembly time so all 22 files derive from one truth.
• Out of scope:
  • Fixing upstream PIM/DAM data quality at its source — the tool surfaces/attributes incompleteness but does not own remediation of the master records (the upstream-steward incentive problem is named, not solved).
  • Amazon-side listing management (pricing strategy, advertising, browse-node taxonomy decisions) — the tool fills NIS fields; it does not decide categorization strategy or run the listing.
  • The closed-loop / self-learning assembler (Architecture C) and any LLM-based extraction or auto-modification of bindings — shelved until a real parseable, timely, slot-attributable Amazon rejection payload is demonstrated at training volume (Khoury kill condition).
  • Live PIM/DAM service integration (Architecture B) as a near-term commitment — gated on confirmed securable access AND a volume/denominator finding that flips its NPV positive.
  • Other Apple/Beats teams' catalog tooling, unless the denominator-scope finding proves the problem is replicable (then a separate scope expansion, not silent scope creep).
• Recursion budget acknowledged: max 3 recursions per phase. (Consistent with the Decision Gate's "Refine = a narrow, measurement-led pass, not a redesign" — the recursion here is into Phase 4 re-scoring with measured inputs, not back into Phase 3 architecture.)

5. Assumption log

Gate: success criteria defined, constraints mapped, decision-maker identified → set phaseGates.0-foundation = passed in manifest.json.