Skip to content

IDE Baseline Freeze Plan

Status: Active working plan Owner: BionicLoop engineering Last updated: 2026-04-06 14:30 EDT

1. Purpose

Define the strict sequence, exit criteria, and freeze gate for the IDE software submission baseline.

This plan exists to prevent freezing the software packet while design inputs, traceability, scope decisions, or evidence structure are still ambiguous.

This plan governs engineering-side baseline preparation only. It does not assign formal quality review, approval, or release ownership to engineering. The target state is a frozen, handoff-ready final draft package with the metadata needed for the receiving quality/submission team to complete formal review and release handling.

2. Freeze Principle

Freeze order is:

  1. lock scope
  2. lock design inputs
  3. prepare final-draft document-control metadata
  4. create protocol and evidence structure
  5. clean traceability references
  6. freeze baseline
  7. execute formal closure evidence

Do not freeze the baseline early in order to "start closing evidence." That only locks ambiguity into the package.

3. Authoritative Inputs

  • Docs/Quality/IDE_Submission_Readiness_Report.md
  • Docs/Quality/IDE_Submission_Closure_Checklist.md
  • Docs/Planning/IDE_Software_Scoping_Plan.md
  • Docs/Quality/IDE_Software_Packet/README.md
  • Docs/Quality/IDE_Software_Packet/IDE_Receiving_Team_Freeze_Disposition_Memo.md
  • Docs/Quality/IDE_Software_Packet/IDE_RTM_Audit_Summary.md
  • Docs/Quality/IDE_Software_Packet/IDE_Formal_Evidence_Execution_Plan.md
  • Docs/Quality/Evidence/Formal/STR-README-Template.md
  • Docs/Quality/RiskAnalysis.md
  • Docs/Quality/SoftwareRequirementsSpecification.md
  • Docs/Quality/SoftwareDesignDescription.md
  • Docs/Quality/SoftwareVerificationAndValidationPlan.md
  • Docs/Quality/TraceabilityMatrix.md
  • Docs/Quality/CybersecurityPlan.md
  • Docs/Quality/DevelopmentSOP.md
  • Docs/Requirements/Requirements.md
  • Docs/Architecture/Architecture.md
  • Docs/Planning/ExecutionPlan.md

4. Definitions

  • Baseline freeze: the point at which the exact IDE document set, scope, revision set, and source SHA are declared fixed for formal closure work.
  • Submission-critical: a gap that must be resolved before claiming IDE readiness for the chosen package scope.
  • Deferred: intentionally excluded from the frozen IDE baseline, with written rationale, risk impact, owner, and approval date.

5. Phase 1: Pre-Freeze Blockers

Complete all sections in Phase 1 before freezing the submission baseline.

A. Scope Lock

Goal: - eliminate ambiguity about what the IDE package is claiming

Required outputs: - packet scope memo - in-scope / deferred / out-of-scope decisions confirmed against the current software packet

Checklist: - [ ] Confirm the current software-packet scope/defer decisions still match the intended freeze package. - [ ] Confirm cloud / auth / Part 11 remain deferred unless the receiving team intentionally re-opens them. - [ ] Confirm step-0 BG rescue remains deferred. - [ ] Confirm any hardware/manual behaviors not intended to be formally rerun are explicitly deferred rather than implicitly claimed. - [ ] Record owner, rationale, and approval date for each deferred item.

Exit criteria: - no major system area is still half in scope and half future-planned for the software packet

B. Design Input Lock

Goal: - freeze the actual behavior being submitted

Required outputs: - requirement disposition log - cleaned, final-language SRS - aligned SDD

Checklist: - [ ] Disposition SRS-BG-008. - [ ] Disposition SRS-MEAL-004. - [ ] Disposition SRS-CLIN-002. - [ ] Disposition SRS-SEC-003 through SRS-SEC-009. - [ ] Remove provisional, temporary, pending team review, and similar unresolved wording from controlled in-scope statements. - [ ] Update Requirements.md so it no longer conflicts with the accepted SRS baseline. - [ ] Update Architecture.md so it no longer conflicts with the accepted SDD baseline.

Exit criteria: - one authoritative behavior baseline exists across SRS, SDD, narrative docs, and actual implementation

C. Final-Draft Document Control Prep

Goal: - convert the quality set from working drafts into handoff-ready final draft records

Required outputs: - final-draft versions of RA, SRS, SDD, SVVP, RTM, CybersecurityPlan, and DevelopmentSOP with prepared release metadata

Checklist: - [ ] Add revision history table to each controlled document. - [ ] Add reviewer / approver role fields, decision-date placeholder, effective-date placeholder, and revision metadata. - [ ] Replace Draft v0.1 / working-draft status lines with final-draft / pending-review status. - [ ] Ensure the final-draft doc set references the same baseline date and package scope.

Exit criteria: - no core IDE-facing document is still a draft or active working note without the metadata needed for quality review/approval handling

D. Verification Architecture Lock

Goal: - make verification reproducible before formal execution begins

Required outputs: - handoff-ready final-draft STP package - formal STR template - test-family ownership map

Checklist: - [ ] Create Docs/Quality/STP/. - [ ] Create STP master index covering all in-scope TV-* families. - [ ] Define setup/environment, procedure, expected result, and pass/fail criteria for each STP. - [ ] Define required artifact payload for each formal STR run: - command log - environment and tool versions - run timestamp - git SHA - pass/fail summary - checksums or equivalent package-integrity record - [ ] Define which claims require real-device evidence and cannot close on simulator/unit evidence alone.

Exit criteria: - every in-scope verification claim has a handoff-ready protocol path and a formal evidence format

E. Evidence Lane Discipline

Goal: - stop mixing working evidence, missing paths, and formal closure claims

Required outputs: - formal evidence index - corrected RTM and SVVP evidence references

Checklist: - [ ] Remove closure dependence on Docs/Quality/Evidence/Working/. - [ ] Correct legacy or missing STR-* references in SVVP, planning docs, and RTM. - [ ] Use IDE_RTM_Audit_Summary.md to confirm which claimed rows are formal-ready, rerun-needed, or deferred. - [ ] Use IDE_Formal_Evidence_Execution_Plan.md as the authoritative smallest-freeze execution sequence. - [ ] Reserve Docs/Quality/Evidence/Formal/ for submission-usable artifacts only. - [ ] Ensure every in-scope RTM row points either to a formal artifact or to a clearly planned formal artifact placeholder.

Exit criteria: - the repo shows one defensible evidence lane for submission closure

F. Risk, Security, and Open-Issue Governance

Goal: - close the governance gaps that would undermine the frozen baseline

Required outputs: - updated risk acceptance model - defect and deviation register - cybersecurity closure plan matched to scope

Checklist: - [ ] Add explicit risk scoring model to RiskAnalysis.md. - [ ] Add residual-risk acceptance criteria and signoff roles. - [ ] Review all open bugs and unresolved anomalies for freeze impact. - [ ] Either close BUG-002 before freeze or record approved rationale for carrying it. - [ ] If security/auth/cloud is in scope, convert the cybersecurity package from high-level narrative to control-and-evidence format before freeze. - [ ] If security/auth/cloud is out of scope, state that explicitly in the scope memo and controlled docs.

Exit criteria: - no known submission-critical issue is still unmanaged at freeze time

6. Pre-Freeze Master Checklist

  • [ ] Scope memo approved
  • [ ] Lean packet review set approved as the default reviewer-facing freeze set
  • [ ] Design-input disposition log approved
  • [ ] Narrative docs aligned to controlled docs
  • [ ] Core final-draft docs prepared for handoff
  • [ ] Docs/Quality/STP/ created and populated for in-scope verification families
  • [ ] Formal STR template approved
  • Current prepared template: Docs/Quality/Evidence/Formal/STR-README-Template.md
  • [ ] RTM and SVVP evidence references cleaned
  • [ ] Risk scoring and residual-risk acceptance model approved
  • [ ] Open bug/deviation review completed
  • [ ] Baseline freeze candidate SHA identified

7. Freeze Gate

Freeze is allowed only when all items in Section 6 are complete.

Required freeze artifacts: - submission baseline branch or tag - document index with exact included versions and dates - scope manifest - baseline git SHA - formal evidence execution plan by owner - software-packet review folder as the default receiving-team review set

Freeze checklist: - [ ] Baseline branch or tag created - [ ] Final-draft document index issued - [ ] Scope manifest issued - [ ] Baseline SHA recorded in handoff records - [ ] Post-freeze change-control rule communicated to all contributors

Post-freeze operating rule: - no behavior-changing code or controlled-document requirement changes enter the frozen baseline without explicit change-control review and baseline re-open decision

8. Freeze Procedure

  1. Confirm Section 6 is fully complete.
  2. Create baseline branch or tag and record exact SHA.
  3. Publish document index and package scope manifest.
  4. Lock controlled-doc versions for formal evidence execution.
  5. Begin formal STR execution against the frozen baseline only.

9. Phase 2: Post-Freeze Formal Closure

After freeze, the work shifts from design-input cleanup to objective closure.

A. High-Risk Formal Evidence First

  • [ ] Execute formal STP-ALG-001 for the accepted algorithm claim set (RA-014).
  • [ ] Execute formal STP-AUTO-001 for the accepted automated local software claim set.
  • [ ] Execute formal TV-SEC-001 using the prepared freeze checklist within the automated lane.

B. Hardware and System Evidence

  • [ ] Run STP-HW-001 only for hardware behaviors still explicitly claimed at freeze.
  • [ ] Run STP-ALERT-001 only for manual/system alert behaviors still explicitly claimed at freeze.
  • [ ] Defer any live/manual behavior not intentionally claimed rather than widening the freeze set by default.

C. Traceability Closure

  • [ ] Update RTM rows from In progress to Complete or approved deferred status.
  • [ ] Replace all Partial and Pending evidence text with explicit formal STR references.
  • [ ] Validate bidirectional links across RA -> SRS -> SDD -> TV/STP -> STR -> RTM.

D. Security and Cloud Closure

  • [ ] Keep deferred cloud/auth/provider/session scope explicit and non-ambiguous unless the receiving team intentionally re-opens it.
  • [ ] Record the freeze-time acceptability decision for the current investigational export/file-sharing posture.
  • [ ] If broader cloud/security/Part 11 scope is intentionally re-opened, issue an explicit scope change before adding new freeze evidence lanes.

10. Phase 3: Submission Hardening

  • [ ] Perform final consistency sweep across all controlled docs and evidence paths.
  • [ ] Publish final unresolved-items or deviation register, if any.
  • [ ] Publish final readiness signoff memo.
  • [ ] Confirm package reproducibility from the document index and formal evidence set alone.

11. Do-Not-Freeze Conditions

Do not freeze the baseline while any of the following are still true:

  • controlled docs are still drafts
  • in-scope requirements still contain unresolved provisional language
  • STP does not exist
  • RTM closure depends on working evidence
  • evidence references point to missing or legacy-only paths without disposition
  • cloud/security scope is ambiguous
  • hardware-dependent claims are supported only by simulator or unit evidence
  • residual-risk acceptance model is undefined

12. Immediate Focus Order

When work begins, use this order:

  1. Review the software packet in Docs/Quality/IDE_Software_Packet/
  2. Section 5A Scope Lock
  3. Section 5B Design Input Lock
  4. Section 5C Controlled Document Release
  5. Section 5D Verification Architecture Lock
  6. Section 5E Evidence Lane Discipline
  7. Section 5F Risk, Security, and Open-Issue Governance
  8. Section 7 Freeze Gate
  9. Section 9 Post-Freeze Formal Closure