Operations Readiness & Cutover Plan — Version 1.0

Lighthouse Financial Services Company — This plan governs the transition of the Beacon Index Advantage from a program deliverable into a product the company sells, administers and is contractually bound by. It is deliberately not written as an inventory of things to have ready. It is written around the one structural fact that separates an annuity cutover from a software cutover: a release can be rolled back and an in-force contract cannot. The point of no return is not go-live. It is the first policy issued — and it arrives some time after launch, unannounced, when a producer somewhere submits an application that clears suitability review. Everything before it is reversible and is planned that way. Everything after it is permanent and is planned that way. Rollback does not fail at cutover. It expires.

1. Purpose, Scope & the Point of No Return

This plan covers the operational readiness of Lighthouse Financial Services Company to sell, issue and administer the Beacon Index Advantage, and the cutover activity that moves the platform configuration into production. It covers new business intake, suitability review, policy issue, funding, policyholder services, correspondence, reconciliation and the hypercare period that follows launch.

1.1 The organizing distinction

Cutover plans in most industries are built on an assumption so ordinary it is rarely stated: if the thing goes wrong, you put back what was there before. That assumption is available here right up until it isn't. Configuration can be reverted. Rate tables can be reloaded. Interfaces can be disabled. A sales portal can be closed. None of that is difficult and all of it is planned in §6.

What cannot be reverted is a contract. The moment an application is accepted and a policy is issued, a person owns a financial instrument this company is obliged to honor for decades. There is no release note that undoes it. This produces a plan with two halves that obey different rules:

1.2 What this plan does not cover

• Product design and pricing — owned by the Actuarial Pricing & Assumption Summary.
• Test execution and defect management — owned by the Master Test & Validation Strategy. This plan consumes its output, specifically the workaround rule discussed in §9.2.
• Producer appointment and certification — owned by the Distribution & Advisor Enablement Plan. Operations inherits the volume that plan produces and does not influence it.
• The launch go / no-go decision itself — owned by the Launch Readiness Criteria. This plan supplies evidence into that decision; it does not make it.

2. What Actually Changes at Launch

A useful readiness plan starts by being honest about how much is genuinely new, because readiness effort should concentrate where the novelty is. Lighthouse Financial Services Company already administers annuity business. The platform already exists. Most of what happens on launch day is a variation of what the operation does every day. Treating all of it as new dilutes attention away from the parts that actually are.

3. The Day-One Operating Model — and Why It Is Not the Steady State

Operations is a 7-person team spanning new business and policyholder services, against a program labor envelope of $856,800 across 10,200 hours. That team is sized for the program, not for the product's eventual in-force block.

3.1 Why a headcount is the wrong answer

The obvious readiness question — "how many people do we need on day one?" — has no honest answer, because day one volume is unknown and the plan's own volume assumption is contested. The Distribution plan reports written Year One commitments below target and field coverage at four wholesalers against six planned (I-06). Staffing to the target risks paying for capacity that never arrives; staffing to the shortfall risks failing the producers who do sell.

So the day-one model is defined by triggers rather than headcount. The operation opens at its current size and expands on observed volume, with the expansion pre-authorized so that it does not require a fresh approval cycle at the moment it is needed.

3.2 Named day-one ownership

4. New Business Processing & the Suitability Review Constraint

Every fixed indexed annuity sale is subject to suitability review under the NAIC Suitability in Annuity Transactions Model Regulation (#275) as adopted in each state. The reviewer must form a judgment that the recommendation was in the consumer's best interest given their financial situation, objectives and needs. This is a licensed judgment task. It cannot be batched, it cannot be meaningfully automated, and it cannot be deferred: an unreviewed application is an unissued policy.

4.1 The arithmetic nobody put in a business case

The Year One premium target is $185,000,000 at an average case size of $118,000, which implies roughly 1,568 policies — about 131 per month, or on the order of 6 suitability reviews per working day at a steady rate.

The suitability rate above is a planning rate, not a locked figure: it assumes roughly 21 working days a month and an even arrival pattern, and annuity sales are not evenly distributed — they cluster at month end and quarter end. The peak is what matters, and the peak is higher than the average by a margin this program has not measured.

4.2 One analyst

The roster carries one Suitability Review Analyst. That is a correct establishment for a program team and an obviously insufficient one for a product operating at the Year One target. The gap is not a criticism of the staffing decision — program teams are not operating teams — but it becomes a launch problem at the exact moment the program hands over, which is precisely when program staffing dissolves.

4.3 What closing OR-3 requires

1. A documented peak-load assumption, not an average, with the month-end clustering stated.
2. At least two additional staff trained and assessed to perform suitability review, drawn from existing licensed personnel, and named.
3. A queue-depth measure visible daily from day one, with the T2 trigger in §3.1 attached to it.
4. An agreed turnaround standard published to Distribution, so that degradation is a breach of a stated commitment rather than a matter of opinion.
5. Written confirmation of who performs review if the named analyst is unavailable for a week.

5. Policyholder Services, Correspondence & the Free-Look Window

Policyholder services carries lower novelty than new business but higher consequence for error, because its output is a document a policyholder keeps. Confirmation statements, contract assembly and free-look disclosure are state-variable and must reflect the filed forms exactly.

5.1 The free-look period is the only rollback the company does not control

Every state mandates a free-look period during which a purchaser may rescind the contract and receive a return of premium, with the length and the return basis set by state law and the filed form. It is worth stating plainly what this means against §1: after the point of no return, the only remaining reversal belongs to the customer, not to the company.

Operationally this creates three obligations that are easy to under-prepare because they arrive weeks after the excitement of launch:

• Free-look disclosure must be correct on the contract as issued — it cannot be corrected by later communication without creating a second problem.
• Rescission must be processable on day one of a request, including premium return within the timing the form specifies. A rescission handled slowly is a regulatory matter, not a service matter.
• Rescission volume is a leading indicator of a suitability problem, not just a service statistic. Elevated early free-look returns concentrated with particular producers is the earliest evidence that something in the sales process is wrong, and it should be reported to Distribution and Compliance jointly rather than sitting in an operations report.

OR-9 covers this and is written to require a proven end-to-end rescission, including the money movement, rather than a procedure document describing one.

5.2 First index crediting cycle

The first crediting cycle falls a full contract year after the earliest issues, which places it outside the hypercare period and outside most people's attention. It is nonetheless the first moment the product's defining mechanic is exercised in production against real policyholder money. OR-7 requires the reconciliation and control set to be proven before launch, on the reasoning that a control designed a year after go-live is a control designed by whoever is left.

6. Platform Cutover — Sequence, Environments & Data

Cutover is executed by the 10-person platform team under V. Sandoval, with release and environment control held by R. Achterberg. The sequence below runs backward from launch, so that a change to the launch date moves every anchor rather than leaving the plan quietly out of step.

6.1 Rate table verification is a compliance step wearing an IT step's clothing

Loading rate tables looks like configuration. It is not: the values loaded must reconcile to the filed methodology, and where the configuration and the filing disagree, the filing governs. This is the same rule the Master Test & Validation Strategy applies to illustration validation, and it has the same consequence — a mismatch discovered at cutover cannot be resolved by changing the system, because the system is not the authority. Verification at T-4 is therefore performed against the filing, by a second person, with the result recorded.

6.2 Environments and the dress rehearsal standard

Both operational dress rehearsals (T-45 and T-21) run against the release candidate in a production-like environment, staffed by the people who will actually do the work. The second is deliberately structured around failure: rejected suitability, incomplete applications, mismatched premium, free-look rescission, and every Severity-2 workaround accepted to date (§9.2). A rehearsal that only exercises the happy path proves the least interesting third of the operation.

7. The Rollback Question, and When It Expires

Most cutover plans contain a rollback section that describes how to restore the previous state. This one contains a rollback section that describes how long that option exists.

7.1 What the program does about a boundary it cannot schedule

Because first issue is an event rather than a date, the plan cannot place the point of no return on a calendar. It can do three things instead, and does:

1. Make the boundary visible in real time. The first issued policy is reported immediately to the launch decision-maker and the program manager — not in a daily summary. Everyone should know the hour at which the option to stop ended.
2. Hold the highest-consequence checks before T-0, not after. Any verification whose failure would justify stopping must complete before new business opens, because the window in which stopping is cheap may be very short. Rate table verification, form correctness and the hedging confirmation in §10 are all pre-T-0 by design.
3. Pre-decide the forward-only response. §7.2 sets out what happens if a material defect is found after first issue, so that the decision is made now rather than under pressure by people who will be tempted to minimize it.

7.2 Pre-committed response to a material defect found after first issue

• Stop selling immediately; keep administering. New business suspension is reversible and cheap. Service suspension is neither, and the policyholders already in force did nothing wrong.
• Notify Compliance and the Gate Review Board chair within the same business day, before the scope of the defect is understood. Waiting for a complete picture is how disclosure becomes late.
• Assess policyholder detriment before assessing program impact. If any issued contract is disadvantaged, remediation of that detriment is not traded against schedule.
• Do not reissue or amend contracts without Legal sign-off, regardless of how obviously clerical the fix appears.

8. Hypercare — Structure, Staffing and Unreleased Funding

Hypercare is the elevated-support period immediately following launch, during which defects are triaged faster, staffing is heavier, and the operation runs with direct access to the people who built the platform. It is where the residual risk of the entire program concentrates.

8.1 The funding problem, stated plainly

Hypercare is delivered in part by Cordelane under work package WP-3 — Stage 4 cutover, hypercare and handover, valued at $410,000, or 9% of the $4,330,000 Stage 4 tranche. Consistent with the program's gate-authorized contracting model, WP-3 is not released. It releases at Gate 4, which is 11 days before launch.

8.2 Hypercare structure

8.3 The handover is a decision, not a date

Handover completes when the receiving managers accept the operation, not when the calendar reaches week eight. Acceptance is withheld if defect volume is still elevated, if any §3.1 trigger is active, or if the suitability queue standard from §4.3 is not being met. Writing this down before launch matters, because the pressure at week eight will run entirely one way — program teams want to close, vendors want to demobilize, and nobody in the room is paid to keep it open.

9. Readiness Criteria and the 11-Day Window

The nine criteria below are Operations' evidence into the Gate 4 launch decision. They do not replace the Launch Readiness Criteria, which owns the go / no-go framework and its no-go conditions; these are the operational inputs that document feeds on.

9.1 Three of these cannot close before Gate 4, by construction

OR-2 is blocked on form approval (I-05) and cannot complete until forms clear. OR-8 cannot close until the vendor package releases, which is Gate 4 itself. OR-3 depends on staffing decisions that follow the Gate 4 funding release. Showing these as amber would imply they are progressing slowly. They are not progressing slowly; they are structurally sequenced after the gate that assesses them, and the honest presentation of a criterion that cannot close yet is to say so.

9.2 The workaround rule quietly assigns work to Operations

The Master Test & Validation Strategy and the Launch Readiness Criteria both state that a Severity-2 defect may proceed to launch where its workaround is documented, staffed and accepted. That rule is sound, and the middle word is the one this plan cares about. Staffed means somebody performs a manual step that the system was supposed to perform — and that somebody is almost always Operations.

Each accepted Severity-2 workaround therefore creates an operational liability that was created by a testing decision, costed in no budget, and inherited by a team of 7. Individually they are trivial. Collectively they are how a launch arrives with an operation quietly running on manual effort that nobody planned and nobody removes. OR-5 requires every accepted workaround to carry a named owner, a written procedure and an explicit staffing allocation before Gate 4, and the second dress rehearsal (T-21) exercises them as a set rather than individually — because the risk is cumulative load, and load is invisible one workaround at a time.

10. Dependencies Operations Does Not Own

Three readiness dependencies sit outside this plan's control and can each independently prevent launch. Naming them here is not an attempt to transfer accountability; it is so that Operations' readiness reporting is not read as a complete picture of launch readiness when it is not.

11. Risks, Issues & Register Linkage

Entries below are held in the program RAIDD log and the Gate Conditions Register; they are reproduced here only where they bear directly on operational readiness. The register is authoritative for status.

12. Governance, Ownership & Document Control

12.1 Reporting and decision rights

• Operational readiness status reports weekly to the Program Management Office from 07 December 2027 (T-90), and daily from T-11.
• The operations go / no-go input is given by L. Marchand and is a single documented recommendation with reasons, not a status colour.
• Cutover execution decisions inside the T-4 to T-0 window rest with V. Sandoval, escalating to the program manager for anything that would delay T-0.
• Hypercare exit is decided by the receiving operational managers per §8.3, not by the program or the vendor.

12.2 Related documents

• Launch Readiness Criteria — owns the go / no-go framework; this plan supplies operational evidence into it.
• Master Test & Validation Strategy — source of the Severity-2 workaround rule inherited in §9.2 and of the filing-governs rule applied in §6.1.
• Vendor Management Plan — explains the gate-authorized contracting model that produces the WP-3 timing discussed in §8.1.
• Distribution & Advisor Enablement Plan — produces the producer volume this plan absorbs; shares the I-06 coverage position.
• Gate Conditions Register — authoritative for GC-05 and its Gate 2 obligation.

12.3 Version control

Prepared by the Program Management Office, Lighthouse Financial Services Company. Owning executive: L. Marchand, Director, Annuity Operations. Platform cutover lead: V. Sandoval. Status date 16 October 2026.