Bluefly Technology Reduction — Delivery Method¶

How the three offers are actually delivered. Field names are not defined here — they are defined in data-model.yaml and referenced by entity.

1. MAINTENANCE REVIEW¶

The customer's question, in their words:

What are we maintaining that we don't need anymore?

One item row per candidate. 21 fields, grouped so each group answers a question that actually changes the verdict.

Phase 1 — Scope and access¶

Agree the SCOPE_UNIT in writing before anything starts: one platform family, one business unit, N sites, N applications, or N repositories. An unbounded estate produces an unbounded review and an unsellable second engagement.

Record the denominator. "We reviewed 34 of an estimated 40 custom modules; the remaining 6 were in a repository we were not granted access to" is a finding. "We reviewed the custom modules" silently claims a total it never established.

Phase 2 — Discovery and inventory¶

Populate identity, ownership and burden for every item. Three fields do most of the work here, and two of them are usually uncomfortable:

current_owner — "Unknown" is a result, not a blank. An unowned system is already a finding regardless of its verdict.
who_uses_it — "Nobody identified" is the single strongest retire signal available. Chase it before accepting it; the users are sometimes real and undocumented.
credentials_or_access — what this thing holds open. Frequently worth more to the buyer than the maintenance hours, because it is auditable.

Interview before reading code where possible. why_it_was_built usually names a constraint that no longer exists, and that sentence does more to justify a retirement than any measurement.

Phase 3 — Replacement assessment¶

The core of the offer. For each item, answer: does the customer already own something that can carry this outcome?

replacement_evidence is graded, and the grade is the integrity of the whole engagement:

Grade	Meaning	Sufficient to recommend removal?
`SIDE_BY_SIDE_PROVEN`	Run against real customer data, outcomes compared	Yes
`TESTED_IN_CUSTOMER_ENV`	Exercised in their environment, not production data	Yes, with the gap stated
`VENDOR_DOCUMENTED`	Vendor says it does this; we have not run it	No — rank `NEXT`, not `NOW`
`ASSERTED_ONLY`	Somebody believes it does this	No — verdict is `INVESTIGATE`

A vendor's documentation is a hypothesis about the customer's environment. The estate's own hard-won rule applies: documented is not the same as working. Never promote VENDOR_DOCUMENTED to a NOW removal.

replacement_maturity of BETA or NOT_AVAILABLE caps the verdict at INVESTIGATE or KEEP. Do not plan a removal onto an unreleased capability.

Phase 4 — Verdicts and ranking¶

Five verdicts. Not fifty categories.

Verdict	Meaning
`KEEP`	Justified. No adequate replacement, or the custom version is genuinely better.
`RETIRE`	Not needed at all. No replacement required — the need is gone.
`REPLACE`	Needed, but an owned platform capability can carry it.
`CONSOLIDATE`	Several implementations of one capability; collapse to one.
`INVESTIGATE`	Cannot be decided on current evidence. Must name the specific missing evidence.

INVESTIGATE is legitimate and must not be used to avoid a decision. It carries the question that would resolve it, or it is not a verdict.

Then rank: NOW · NEXT · LATER · KEEP. NOW means low risk, proven replacement, and the customer can approve it in this engagement.

Phase 5 — Deletion Plan and readout¶

Acceptance: every item carries a verdict and a rank, and the customer has made a decision on every NOW item. A plan the customer has read is not acceptance; a plan the customer has decided on is.

2. THE DELETION PLAN¶

The customer-facing deliverable. Projects item plus the removal-planning fields of removal.

Per item: CURRENT_THING · WHY_IT_EXISTS · WHAT_REPLACES_IT · WHY_REPLACEMENT_IS_PREFERRED · CURRENT_ANNUAL_BURDEN · REMOVAL_EFFORT · REMOVAL_RISK · SECURITY_SURFACE_REMOVED · CREDENTIALS_CLOSED · UPGRADE_TESTING_REMOVED · ROLLBACK_PATH · CUSTOMER_APPROVAL · STATUS

Ranked NOW / NEXT / LATER / KEEP.

The plan must lead to decisions. It does not end with "recommendations for consideration" — that phrase is the failure mode this deliverable exists to avoid. Every NOW item has a named approver and a decision field that is filled in during the readout, not after it.

3. SAFE REMOVAL¶

Twelve steps, in order. The order is the safety property; reordering it removes the guarantee.

#	Step	Why it is where it is
1	Establish baseline	Measure the current business outcome before touching anything. A baseline captured after the first change is not a baseline.
2	Configure existing replacement	Using the platform's supported configuration path. Not a bridge, not a shim.
3	Run old and new side by side	Both live, same inputs.
4	Compare required business outcomes	Compare the outcome, not the implementation. Identical internals are not the goal.
5	Document differences	`known_differences` of "none" is only valid if something was actually compared. Say what.
6	Customer approves	Named approver, in writing, on the evidence from steps 4–5.
7	Switch old implementation off	Disabled, not deleted.
8	Retain bounded rollback capability	Tested, not assumed.
9	Verify production	Read the result back from production, not from the deploy log. A green deploy is not a working outcome.
10	Revoke old credentials and access	This is where most of the security value is realised, and it is the step most often skipped because the feature already appears to work.
11	Remove old implementation	Only after the rollback period has elapsed.
12	Record the ownership removed	`measure` rows, with provenance.

The rollback period¶

Default: 30 days.

This is a default, not a promise that every item can use 30 days. It is set per removal in removal.rollback_period_days and is driven by the customer's reality:

A quarterly financial close may require the window to span a full cycle.
A regulatory retention or change-freeze requirement overrides the default in either direction.
A seasonal peak may require the window to extend past it.
A trivial, zero-integration item may justify a shorter window with the customer's agreement.

Never quote 30 days as a fixed property of the service.

Why steps 7 and 11 are separate¶

Switching off and removing are different events with different risk. Collapsing them removes the rollback window, which is the entire reason the customer can approve step 6 without taking a leap of faith. A removal that deletes at cutover is not Safe Removal.

4. THE VERIFICATION CONTRACT¶

A removal does not count because code disappeared. It counts when the customer outcome still works.

One verification row per removal, 15 fields, ending in final_verdict = PASS | FAIL | ROLLED_BACK.

Three fields are the ones that make it a contract rather than a checklist:

rollback_test — NOT_RUN means there is no rollback path, only an intention. An untested rollback is not a control.
production_readback — read from production. Not the pipeline, not the deploy log, not the absence of alerts.
functional_equivalence — three values, because EQUIVALENT_WITH_DIFFERENCES is the honest and most common answer. Forcing it to binary produces either a false claim of identity or a false claim of failure.

ROLLED_BACK is a real and acceptable verdict. It is recorded, reported to the customer, and counted. Hiding rollbacks would make the pass rate meaningless and is the fastest way to lose the only thing this offer sells.

What Bluefly must be able to prove at the end:

Same required outcome, less customer-owned machinery.

5. MAINTENANCE WATCH¶

Recurring, quarterly, two pages maximum unless material evidence requires an appendix.

Not a dashboard. Not a platform. Not a portal the customer has to log into — that would be new technology for them to own, which contradicts the offer.

LIST 1 — What can you stop maintaining now?¶

Driven by the platform catching up. Per finding: NEW_PLATFORM_CAPABILITY · CURRENT_CUSTOM_IMPLEMENTATION · WHY_IT_MAY_NOW_BE_REDUNDANT · RECOMMENDED_ACTION.

Note the hedge in "may now be redundant" — it is deliberate. A quarterly watch item is a candidate, at VENDOR_DOCUMENTED evidence at best. It feeds a Review, it does not authorise a removal.

LIST 2 — What are you about to build that you shouldn't?¶

The prevention half, and the reason this is recurring rather than a follow-up. Per finding: PROPOSED_CUSTOM_WORK · EXISTING_CAPABILITY · DUPLICATION_RISK · RECOMMENDED_ACTION.

Reduction without prevention regrows. A customer who retires 20 systems and builds 25 new ones has bought nothing. List 2 is what makes the engagement compound instead of repeat, and it is increasingly the more valuable list as custom code becomes cheaper to produce than to decide on.

Honest limitation¶

List 2 requires visibility into what the customer is planning — roadmaps, design docs, or a standing conversation with the platform team. Where that access does not exist, say so in the quarterly report and name what would be needed. A List 2 compiled without planning visibility is guesswork wearing a deliverable's format.

6. Where the method must not drift¶

No artifact invents a field. If it needs one, it goes in data-model.yaml first. Twelve documents with twelve field lists drift inside a single engagement.
No number without provenance. measure rows carry source, assumption, customer_confirmed. A number that cannot carry those is not shown.
No removal without a named approver. Not a team, not an email thread — a person with the authority to authorise it.
No NOW rank on VENDOR_DOCUMENTED evidence. That is the specific shortcut that turns this offer into an outage generator.