Bluefly Technology Reduction — Delivery Kit

Twelve reusable artifacts. None of them defines a field. Each is a projection of data-model.yaml, named in that file's projections: block.

The rule that keeps this kit usable: if an artifact needs a field that is not in the model, add it to the model first. Twelve documents that each grew their own field list would disagree with each other inside a single engagement — which is the exact failure this structure exists to prevent.

An artifact may narrow a projection for a given audience. It may not widen it.

#	Artifact	Entity	Produced during	Audience
1	Discovery questionnaire	item	Review ph.2	Customer team
2	Technology inventory	item	Review ph.2	Joint
3	Reduction candidate record	item	Review ph.3	Internal → joint
4	Keep/retire/replace/consolidate decision	item	Review ph.4	Joint
5	Customer approval	removal	Pre-removal	Customer approver
6	Side-by-side validation	verification	Safe Removal 3–5	Joint
7	Rollback plan	removal	Safe Removal 8	Joint
8	Retirement checklist	verification	Safe Removal 9–12	Internal → joint
9	Reduction report	measure	Engagement close	Customer
10	Quarterly Maintenance Watch	watch_finding	Each quarter	Customer
11	Executive summary	measure	Close & quarterly	Economic buyer
12	Sales qualification worksheet	prospect	Pre-sale	Internal

---

1. Discovery questionnaire · item

Asked of the customer's team, one pass per candidate. Written to be answered by someone who did not build the thing.

• What is it called, in the words your team uses? → item
• What would stop working if it vanished tonight? → business_purpose
• Whose budget or team owns it today? → current_owner (record "Unknown" — it is a finding)
• Who actually uses it? Name roles. → who_uses_it ("Nobody identified" is the strongest retire signal there is)
• Why was it built? What couldn't the platform do then? → why_it_was_built
• What do you do to it in a normal year? → current_maintenance
• What accounts, tokens, keys or network paths does it hold? → credentials_or_access
• If one person left, would this become a problem? → key_person_dependency

2. Technology inventory · item

One row per item. The engagement's spine.

item_id · item · business_purpose · current_owner · who_uses_it · current_maintenance · credentials_or_access · upgrade_impact · security_impact · key_person_dependency

Header the denominator, e.g. "34 items across 3 of 4 in-scope repositories; repository 4 access not granted." An inventory that implies a total it never established is the most common way a review overstates its own coverage.

3. Reduction candidate record · item

The replacement case, per item.

item_id · item · existing_platform_replacement · replacement_maturity · replacement_evidence · removal_difficulty · removal_risk

Gate, applied mechanically:

replacement_evidence = ASSERTED_ONLY      -> verdict INVESTIGATE
replacement_evidence = VENDOR_DOCUMENTED  -> rank may not be NOW
replacement_maturity in {BETA, NOT_AVAILABLE} -> verdict INVESTIGATE or KEEP

4. Keep / retire / replace / consolidate decision · item

item_id · item · verdict · rank · verdict_rationale

verdict_rationale must reference replacement_evidence. A rationale that does not say what the evidence was is an opinion.

An INVESTIGATE verdict names the specific missing evidence, or it is not a verdict.

5. Customer approval · removal

The authorisation record. Not an email thread.

removal_id · item_id · what_replaces_it · rollback_path · rollback_period_days · customer_approval · customer_approver

customer_approver is a named individual with authority to authorise the change. rollback_period_days defaults to 30 and is set per removal — see Delivery-Method.md §3 for when it must differ.

Nothing moves to cutover with customer_approval of DEFERRED or NOT_REQUESTED.

6. Side-by-side validation · verification

Produced while both implementations run.

before · after · business_outcome · functional_equivalence · known_differences

• before is captured before any change. A baseline measured after the first change is not a baseline.
• business_outcome is in the customer's language.
• known_differences of "none" is valid only if something was compared. State what.
• functional_equivalence has three values because EQUIVALENT_WITH_DIFFERENCES is the usual honest answer.

7. Rollback plan · removal

removal_id · rollback_path · rollback_period_days · status

rollback_path names the specific mechanism — the snapshot, the disabled configuration, the retained artifact and where it lives. The word "rollback" is not a rollback path.

The plan is only complete once verification.rollback_test = PASS. Until then there is an intention, not a control.

8. Retirement checklist · verification

Run at steps 9–12 of Safe Removal.

production_readback · old_credentials_revoked · old_runtime_disabled · old_source_retired · documentation_updated · final_verdict

Credential revocation is the step most often skipped, because by then the feature already works and the removal feels finished. It is where much of the security value actually lands, and it is the one item here a customer auditor will check.

production_readback is read from production.

9. Reduction report · measure

Engagement close. One row per reported number.

name · value · unit · source · assumption · customer_confirmed · period

Rendering rule: a row with customer_confirmed = NO is labelled unconfirmed in the customer's view. It is not quietly dropped, and it is not promoted. Dropping it hides the gap; promoting it fabricates a saving.

10. Quarterly Maintenance Watch · watch_finding

Two pages maximum. Two lists.

List 1 — what you can stop maintaining now (direction = CAN_STOP): new_platform_capability · current_custom_implementation · why_now_redundant · recommended_action

List 2 — what you are about to build that you shouldn't (direction = SHOULD_NOT_BUILD): proposed_custom_work · existing_capability · duplication_risk · recommended_action

If planning visibility does not exist, List 2 says so and names what would be needed. A List 2 assembled without it is guesswork in a deliverable's format.

11. Executive summary · measure

One page, economic buyer.

name · value · unit · customer_confirmed

Narrowed deliberately: no source or assumption columns, because this audience reads a summary, not an evidence table. The confirmation flag stays — that is the one provenance signal that must survive compression, and dropping it is how an unconfirmed estimate becomes a quoted fact.

12. Sales qualification worksheet · prospect

Completed in one conversation, by a salesperson, without a scoring algorithm.

Mark each signal PRESENT / ABSENT / UNKNOWN:

forced_upgrade_with_date · end_of_life_deadline · customization_count · upgrade_difficulty · maintenance_cost_pressure · security_findings · unexplained_credentials · key_person_dependencies · duplicate_capabilities · ai_generated_custom_code_growth · number_of_sites_or_applications · platform_standardization_opportunity

UNKNOWN is a real answer, and on a first call it is the most useful one — it names the next question rather than inflating the score.

Fit

Fit	Test
IDEAL_FIT	A dated trigger (forced_upgrade_with_date or end_of_life_deadline = PRESENT) and meaningful custom surface and a platform likely to carry replacements.
POSSIBLE_FIT	Custom surface and cost pressure are present, but no dated trigger. Real, slower. Nurture against the next upgrade cycle.
BAD_FIT	No custom surface; or mid-migration to a new platform (the estate is changing underneath a review); or looking for staff augmentation; or no one can authorise a removal.

The dated trigger is the discriminator. Everything else describes whether the work exists; the date determines whether anyone will act on it this year.

fit_reason is mandatory. A fit without a stated reason cannot be reviewed later, and BAD_FIT needs it most — it is the record that stops the account being requalified from scratch every quarter.

---

Integrity check

Every field named in this file exists in data-model.yaml, and every projection header matches a projections: entry there. This was verified mechanically at authoring time rather than by reading. Re-run it after any edit — a kit whose field names have drifted from the model is worse than no kit, because each artifact still looks internally consistent.