Product Requirements Document

Lighthouse Financial Services Company — What Beacon Index Advantage is, what it is deliberately not, and which gate authorized each answer. Version 1.1, adopted Jun 11, 2026 and frozen until Gate 2 on April 1, 2027.

1. Why There Is No BRD

The absence of a business requirements document is worth stating plainly because its absence is what makes this document unusual. A BRD answers what the business needs; here that question was answered at Gate 1, by a business case that was scored and voted on, and re-answering it in a requirements document would create a second version of a decision the board has already taken.

What follows is therefore narrower than a BRD and more contingent. It says what is being built, at the level of detail the current gate has funded, and it does not argue that the product should exist. That argument lives in the Gate 1 Business Case Package, including the dissent, and this document is downstream of it.

There is a second reason worth stating, because it explains the shape of everything below. A BRD is written once and baselined; this document is re-scored at every gate. Those are different instruments. A baselined document answers what did we agree, and change to it is an exception handled by control; a gate-versioned document answers what do we currently intend, given what the board has funded so far, and change to it is the normal case rather than the exception.

Conflating them is how stage-gate programs quietly become waterfall programs with extra meetings. If the requirement set is treated as baselined at Gate 1, then each subsequent gate is reduced to approving a schedule, and the decision the gate exists to take — whether to continue at all — has already been foreclosed by a document.

One practical note on how to read what follows. Because the document is re-scored rather than baselined, its sections are not equally durable. §2 has survived every gate unchanged; §4 has been rewritten once; §3 contains requirements whose funding does not yet exist. Treating all three as equally settled is the commonest way this kind of document is misread.

This program produces no business requirements document, and the absence is a decision rather than an oversight.

2. Product Definition

The product definition below is the stable core — the part that has survived two gate convenings and one recycle without changing. Everything downstream of it has moved at least once.

⚠ Read the version history in §6 before treating any requirement here as settled. Version 1.0 was tabled at the first Gate 1 convening on Apr 30, 2026 and never adopted — the gate recycled before the requirement set was scored. The set that stands was adopted at the second convening on Jun 11, 2026, with five proposed crediting strategies reduced to three. A requirement set that has already been un-adopted once is not a document to read as though it were fixed.

The definition is deliberately thin on mechanism. It states what the product is and for whom, and leaves how it behaves to §3, because the mechanism has already changed once at a gate and may change again. A product definition that encodes mechanism has to be revised every time the mechanism moves, and a document revised that often stops being read.

⚠ One consequence for readers outside the program: this document cannot be quoted as a commitment to a customer, a distributor or a regulator. Until a stage is funded, its requirements describe an intention the board may decline, and the difference is not visible from the formatting.

3. Requirements by Area

Eighteen requirements are listed, and they do not all mean the same thing. This is the point at which a stage-gate PRD departs from an ordinary one, and reading them as a flat committed list would misrepresent the program.

⚠⚠ Only Stage 2 is funded. Stages 3 and 4 — $11,780,000 of program funding — depend on gate decisions that have not been taken and may go against the program. A requirement whose stage is funded is a commitment; a requirement whose stage is not is a statement of intent conditional on a decision nobody has made yet. Both appear below, because hiding the second kind would produce a shorter document and a false one.

The vendor contract is built on the same distinction. The Cordelane SOW uses a release-notice mechanism rather than a committed scope precisely because committing the full scope would mean either committing money the Board has not released, which the Chair has no authority to do, or quietly assuming the gates are a formality. This document is written to the same standard: a requirement is not more certain because it appears in a numbered table.

The practical consequence for anyone building against this: requirements for unfunded stages are specified to the depth needed to price and plan them, not to the depth needed to build them. Elaborating an unfunded requirement to build-ready detail spends money on a stage the board may decline, and it creates a sunk-cost argument for approving that stage — which is the failure mode the gate exists to prevent.

There is a further asymmetry worth naming. Requirements for funded stages have been costed against a released tranche and can be held to; requirements for unfunded stages have been costed against an estimate, and the estimate was prepared by people who expect the program to continue. That is not dishonesty, it is the ordinary optimism of a team mid-program, and the correction for it is a gate rather than a better estimate.

So the reader should treat the funded and unfunded halves of this table as carrying different evidentiary weight, even though they are formatted identically. Formatting them differently was considered and rejected: it would invite the requirement set to be read as two documents, and the point of keeping them together is that the unfunded requirements are what the board is being asked to decide about at the next gate.

The requirement set below is the same set the Requirements Traceability Matrix traces — one list, read two ways. The Authorized column records which gate released the funding for the stage that builds each item, because in this program a requirement does not exist until a gate has paid for it.

Product chassis

Rider

Crediting strategies

Regulatory footprint

Risk and capital

Platform and operations

Distribution

4. The Three Crediting Strategies

The three crediting strategies are the clearest illustration of how a gate decision changes the requirement set rather than merely the schedule. Five were proposed at Gate 0 and carried into version 0.1. Three survived to adoption at the Gate 1 second convening.

That is not a deferral. The two that were dropped are not waiting in a backlog for a later stage; they were removed because the illustration engine's verified capability could not support five at launch, and re-proposing them would be a new scope item requiring its own justification. ⚠ A gate decision that reduces scope removes requirements permanently unless someone re-argues them, which is a materially different thing from postponing them.

The reduction also changed what the remaining three have to do. With five strategies the product could offer breadth; with three it competes on the quality of each, which raised the bar on the illustrated cap and pushed PQ-02 from a pricing detail to an open question. ⚠ A gate decision that removes scope does not leave the remaining scope unchanged — it redistributes the product's competitive weight onto what survives, and requirements written before the reduction may now be under-specified for the job they have to do.

That is the practical answer to how a gate decision changes the requirement set rather than the schedule. The schedule effect was visible immediately; this effect was not, and it is the reason the version history in §6 records what changed rather than only when.

5. Deliberately Out of Scope

The exclusions below are as load-bearing as the requirements, and on a stage-gated program they carry an additional function: they mark the boundary between what the current gate authorized and what would need a new authorization.

⚠ An item excluded here cannot be added by agreement between the program and the vendor, however sensible the addition looks. It would extend scope the board funded to a specific boundary, and the mechanism for changing that boundary is a gate decision, not a change order. The Cordelane SOW's release-notice structure enforces the same rule commercially.

Two exclusions are worth explaining rather than merely listing, because both were argued for and lost. Each was excluded on capability grounds rather than on merit — the illustration engine's verified capability, not a judgment that the feature is undesirable — which means the exclusion is reversible in a later program in a way that a merit-based exclusion would not be.

Recording the grounds matters for exactly that reason. An exclusion whose reason is lost becomes permanent by default, and the organization ends up unable to say whether something was rejected or merely deferred and forgotten.

⚠ The exclusions also protect the gate itself. Scope that creeps in between convenings arrives at the next gate as work already underway, and a board asked to approve something half-built is not really being asked. Keeping the boundary explicit is what leaves the next decision genuinely open.

A requirements document that lists only what is in scope invites the reader to assume everything else was forgotten.

6. Versioned by Gate

This section is the honest record of a requirement set that has been revised at every gate, and it is the reason this document carries a version rather than a date.

⚠ Version 1.0 is the entry worth pausing on. It was tabled and not adopted — the gate recycled before the requirement set was scored, so there is no version of this document that was ever approved at the first Gate 1 convening. A reader who assumes a numbered version implies an approval will read that line wrongly.

What happens to requirements written for a stage that is recycled or cancelled is not hypothetical here. The Harborline Buffer Series — a registered index-linked annuity from this same board — passed Gate 0 in March 2025 and was cancelled at Gate 1 that August, with the unspent tranche returned to capital. Its requirements did not transfer to a successor program and were not treated as a head start; the suite's own cancellation record sets out the auditable test for why a successor is a new program rather than a zombie restart.

The implication for this document is direct. If Gate 2 goes against the program, the requirements below do not become the basis of whatever is attempted next. They become part of the record of a decision, and the $11,780,000 behind Stages 3-4 returns to capital unspent.

Versioning by gate rather than by date also fixes who may change the document. Between gates the requirement set is not editable by agreement — not by the program, not by the vendor, not by the two together. It changes when a gate changes it, which is what keeps the scored record and the built product describing the same thing.

⚠ The alternative is the failure this program's own history warns about. A requirement set that drifts between gates arrives at the next convening describing a product the board has not seen, and the gate is then asked to approve continuation of something it never authorized — while appearing to follow the process exactly.

This document meets that obligation, and the record is better than a reader of §6 alone would guess. The two withdrawn strategies are carried in the Requirements Traceability Matrix as withdrawn rows rather than deletions — its own version note records that at the Gate 1 second convening PR-07 and PR-08 moved to withdrawn and no row was deleted. An RTM that deletes cut scope cannot answer the most common question asked of a launched product: why doesn't it do X?

⚠ Both are recorded as not deferred — out of scope, and the distinction is deliberate. A withdrawn requirement is not waiting for a later stage; it was removed on a capability ground and would have to be re-argued as new scope. Calling it deferred would imply a commitment the gate never made.

⚠ The ground is capability weighed against forecast demand, and the second half matters as much as the first. Both were buildable with custom development; neither earned it. Saying only that the vendor could not do it would be the easier story and the weaker one — it implies the product was constrained by a supplier, when the board actually declined to buy a capability whose forecast contribution did not repay it.

That distinction decides what a successor would face. The constraint half may simply not exist on different infrastructure, so a later program could find these strategies buildable as standard. The demand case would still have to be made again, because nothing at Gate 1 established that these strategies were worth building — only that they were not worth building at that price. Neither strategy was judged undesirable, and neither was judged valuable; the gate never reached that question.

This is also why the program keeps no change control log. There is nothing for one to record: material change is a gate re-submission, and the gate package is the record. Change within a stage that does not alter this document is handled by the owning team and does not need a register to prove it happened.

7. Open Questions

The open questions are recorded rather than resolved, and the distinction matters more here than the count. Each is a question the program has decided it cannot answer at this gate — not one it has failed to get to.

⚠ PQ-01 is the clearest case. Pricing assumes a 62% rider election, and nothing in Stages 2-4 can test it: the first real reading comes months after launch, recorded as BEN-02 in the Benefits Realization Plan with a Month 3 first read. Carrying it as an open question is the accurate treatment. Closing it with an estimate would convert an acknowledged unknown into a number that later reads as a commitment.

PQ-02 has a different shape: the illustrated cap of 9.25% sits against a peer 9.00% with a competitive floor of 8.50%, so the question is not what the answer is but how long it stays true. A question whose answer decays is not resolvable in a requirements document at all — it is a monitoring obligation, and recording it here is how it survives into the stage that has to watch it.

What an open question does not do is block a gate. A program that required every question closed before proceeding would never proceed, since some answers only exist after launch. What the gate asks instead is whether the open questions are the right ones: whether anything closed as settled is actually unresolved, and whether any of these four would change the decision if answered badly.

⚠ PQ-01 is the one that would. If rider election lands materially below the assumed 62%, the economics that carried Gate 1 change — and the first reading arrives months after launch, when Stages 3 and 4 are already committed. That is stated here rather than buried in the pricing appendix because it is the single largest thing this document cannot tell you.

PQ-03 and PQ-04 are recorded on the same basis: each is answerable only by evidence that does not exist yet, and each is assigned to the stage that will first be able to see it. An open question with no owning stage is not being tracked, it is being remembered, and the difference shows up about a year later.

Owned by D. Falkner, VP Product Development, under G. Marchetti, Chief Product Officer. Maintained through the gate process by C. Tyrrell, NPD Program Manager. Related: Requirements Traceability Matrix · Gate 1 Business Case Package · Regulatory Filing Plan · Glossary.