Planning Gates: Recording Approval, Revision and Final Acceptance

This article shows developers how to record plan approval, material revisions and final acceptance. The gate defines what is approved, who may approve it and which changes require renewed approval.

A recorded plan gives implementation and review a common reference point without claiming that planning alone improves delivery.

Record the plan

A plan captures decisions expected to remain stable during implementation:

• Intended behaviour
• Relevant business rules
• System boundaries
• Failure handling
• Testing strategy
• Evidence required for acceptance

Product and engineering participants agree the outcome and constraints. The implementer decides how to meet them within the repository.

Without this agreement, reviewers reconstruct more of the requirement from implementation choices. Those choices can anchor the discussion. Replacing an unsuitable approach appears more expensive after implementation than selecting one before work begins.

The plan should not prescribe incidental code structure. Excess detail takes time to review, becomes stale and restricts implementation decisions that do not affect the agreed outcome.

Use an explicit approval gate

The gate requires three decisions:

1. Approve or reject the plan before implementation.
2. Continue, pause or seek renewed approval when a material change arises.
3. Accept or reject the completed change against the current approved plan.

Rules for each risk band must state:

• How the risk band is assigned
• Who is authorised to approve the initial plan
• Who is authorised to approve revisions
• Who is authorised to give final acceptance
• Whether those authorities may be the same role
• Whether independent challenge is required
• Whether implementation pauses during revision
• How unresolved disagreement is escalated
• What evidence final acceptance requires

Plan approval, revision approval and final acceptance are separate decisions. The control model must identify the authorised role for each rather than assume that one approval covers the full lifecycle.

A risk label without these rules cannot determine which controls apply.

Keep one lifecycle record

The following synthetic table defines the minimum lifecycle record. It is a proposed template, not evidence that the control has operated.

Stage	Field	Required entry
Identification	Work item	Identifier linking the plan to implementation
Planning	Intended behaviour	Observable outcome of the change
Planning	Business rules	Rules the implementation must preserve
Planning	Boundary	Included and excluded systems or components
Planning	Failure handling	Required behaviour when the operation fails
Planning	Acceptance conditions	Testable conditions for acceptance
Planning	Validation method	Tests, checks or inspection used as evidence
Classification	Risk band	Assigned classification
Initial approval	Plan approver	Role or person authorised for the assigned classification
Initial approval	Approval state	Draft, approved, rejected or superseded
Initial approval	Approval record	Decision, date and recorded location
Revision	Revision trigger	Material change requiring reassessment
Revision	Revision record	Changed field, reason, proposer and decision
Revision	Revision approver	Role or person authorised to decide the revision
Revision	Work status	Continue or pause while approval is pending
Implementation	Code reference	Link between the approved plan and implementing code
Validation	Acceptance evidence	Links to tests, checks and review findings
Final acceptance	Acceptance authority	Role or person authorised to accept the completed change
Final acceptance	Acceptance state	Pending, accepted or rejected
Final acceptance	Accepted plan version	Exact approved version used for final review

Each approved version should link to the version it supersedes. Missing records should remain visible rather than be inferred from surrounding entries.

Define material change

A material change affects the approved intent or the basis on which it was approved. It requires reassessment through the revision fields in the lifecycle record.

Area	Material change	Normally not material
Behaviour	An operation returns a different result for an accepted input	Internal refactoring preserves the same result
Boundary	The change writes to a component excluded by the plan	Code moves between files inside the approved component
Risk	New information meets the defined criteria for another risk band	An implementation detail changes without affecting the assigned criteria
Acceptance	A required test is removed, weakened or replaced with different evidence	The same acceptance condition is tested at a different internal layer
Failure handling	A specified rejection becomes a retry or partial success	Error construction changes while externally observable handling remains unchanged

These examples define the decision test, not the risk-band rules. Each organisation still needs operational criteria for assigning risk and identifying authorised approvers.

When a material change arises, update the lifecycle record with the affected field, reason, risk classification, work status, decision and superseded plan version.

Review against the plan

An approved plan reduces initial requirement discovery and business-rule interpretation during normal code review. It does not remove them. Review can still uncover mistaken assumptions, unrecognised dependencies or missing requirements.

Reviewers can ask:

• Does the implementation preserve the agreed behaviour and invariants?
• Are error paths handled as specified?
• Do tests exercise each acceptance condition?
• Has the change stayed within its declared boundary?
• Is every material departure recorded and approved?
• Does the acceptance evidence refer to the current plan version?

If a finding changes behaviour, boundaries, risk or acceptance conditions, the plan requires reassessment. Otherwise, the reviewer can treat it as an implementation issue within the approved scope.

Apply the workflow

This synthetic example demonstrates the mechanics rather than a delivery result:

1. A plan states that a component must reject an invalid input without writing outside its declared boundary.
2. Acceptance requires a test showing the rejection and confirming that no external write occurs.
3. An authorised plan approver approves the plan under the assigned risk band.
4. During implementation, the engineer finds that the proposed path requires a write to a component excluded by the plan.
5. The engineer records the boundary change and requests reassessment.
6. Work continues or pauses according to the rule for that risk band.
7. The authorised revision approver accepts or rejects the revised boundary.
8. Code review checks the implementation and tests against the approved version.
9. The authorised acceptance role records the final decision and links it to the supporting evidence.

The external write is material because it changes the declared boundary. A local refactoring that preserves the rejection behaviour, boundary and acceptance test does not require renewed approval.

The example does not establish whether the three approval decisions should be made by the same person or by separate roles. That choice belongs in the organisation’s authority rules.

Link repository controls to evidence

Planning cannot compensate for a repository that cannot reproduce or enforce its validation process. Repository controls should support named acceptance evidence rather than form a general checklist.

Repository control	Acceptance evidence it supports	Review question
Runtime pinning	Test results produced under the declared runtime	Was validation run with the recorded runtime version?
Continuous integration with observed checks	Recorded execution of required tests and checks	Did the required checks run against the accepted change?
One-command validation	A repeatable command covering the stated validation method	Can a reviewer repeat the required validation from the repository?
Default-branch protection	Enforcement of required checks before integration	Could the change enter the default branch without the recorded checks?

A plan should not imply that evidence is repeatable unless the repository provides the required mechanism. The lifecycle record should link the approved plan, implementing code, validation results, review findings and final acceptance decision.

Define delivery measures

Planned and unplanned work can only be compared when each measure has an operational definition.

Measure	Proposed definition
First-pass result	Whether the change meets all recorded acceptance conditions at its first formal acceptance review
Review finding	A recorded issue raised during review that requires a response or change
Finding classification	The defined category and severity assigned under the review process
Final acceptance result	Accepted or rejected against the current approved plan
Change size	The organisation’s declared sizing method, applied consistently to both cohorts
Change complexity	The organisation’s declared complexity method, applied consistently to both cohorts
Revision frequency	Number of approved-plan revisions per change
Approval latency	Time between submission for approval and the recorded decision
Missing data	A required field or record that is absent, unavailable or cannot be linked to the change

Teams must define sizing, complexity and severity schemes before collecting results. Retrospective classification risks inconsistent comparisons.

Do not force ambiguous records into a category. Record them as unknown and state why. A missing approval or acceptance record is not evidence of rejection, acceptance or an absence of findings.

Reports should include:

• Definitions and reporting period
• Planned and unplanned cohort sizes
• Risk band, repository and scope
• Change size and complexity
• First-pass and final acceptance results
• Finding counts and classifications
• Revision frequency
• Approval latency
• Missing and ambiguous records

Compare work with similar risk, repository and scope characteristics. Where direct matching is impractical, group results by those factors and report size and complexity within each group. This can reduce unsuitable comparisons, but it cannot establish causation.

Evidence limitations

This article proposes a control model and synthetic record. It does not include a real change record, repository artefacts, operational risk-band rules, defined outcome measures or a source-backed separation of approval roles. No governance, change-management or software-assurance standard has been cited because no supporting source was provided.

No reported percentage is justified without its source, population, numerator, denominator and definition. The model therefore does not demonstrate that planning improves delivery or makes intent clearer in practice.

What this means

An approval gate gives implementation and review a recorded reference for intent, revision and acceptance. Claims about delivery impact require complete lifecycle records, repeatable repository checks and consistently defined comparisons between planned and unplanned work.

---

Originally published at AFT Group Engineering Insights.