What must be resolved before a changed product configuration can be released?

The previous baseline has already been released

The change is a bound hardware-and-firmware configuration

The same product family does not mean identical verification conditions

Change Approval and Product Release are different decisions

The proposed Full-Family Release

Responsibility and authority are separate

Even final internal authority may not reinterpret evidence

• 01It may not treat an unperformed test as passed.
• 02It may not silently convert a technical assumption into a fact.
• 03It may not replace Product Safety authority without a mandate.
• 04It may not approve a broader scope than the evidence supports.

Factory Release, Service Release and Field Update are not identical

External requirements depend on the specific product context

The regulatory date belongs to the Decision State

Software and firmware changes can be relevant under product rules

The Verification Campaign is variant-specific

The Coverage Map

A missing test is not the same as a failed test

Fact, Evidence, Inference and Decision remain separate

A valid test report has a limited scope

• 01Another hardware revision may have been tested.
• 02Another firmware version or product variant may have been used.
• 03Different thermal, fault or operating conditions may have applied.
• 04The Release Scope may be broader than the Test Scope.

The Evidence-Inheritance Conflict

Evidence Inheritance is a professional decision

• 01A technical comparison basis and identified differences
• 02Relevant worst-case conditions and Requirement linkage
• 03Documented uncertainty and a defined scope
• 04Competent professional authority

Requirement Coverage is variant-specific as well

Manufacturing Readiness is already largely resolved

• 01Incoming component qualification
• 02Validated assembly process and updated work instructions
• 03Adapted End-of-Line Test
• 04Traceability through Hardware Revision H4

Design Release and Manufacturing Release remain separate

A Deviation is not a substitute for passed evidence

• 01Affected Requirement Coverage and configuration
• 02Scope, impact and Mitigation
• 03Validity, Conditions and Monitoring
• 04Competent Authority and Change Trigger

The Service Scope has its own requirements

• 01Is H4 a permitted replacement state for every variant?
• 02Which firmware belongs to which hardware revision?
• 03Are H3 and H4 service-compatible?
• 04Does the service tool recognise the baseline?
• 05Is Cross-Revision Substitution permitted?

Commercial urgency belongs in the state, but not in the evidence

Alternatives belong to the release decision

Authority is itself a state

Decision Space v1 as a complete state

Path A: missing Verification Evidence

• 01High-Temperature Verification and defined Single-Fault Injection
• 02Worst-case Reaction-Time measurement
• 03Diagnostic behaviour under combined load
• 04Complete Test Report bound to H4 / 4.8.0
• 05Documented setup and traceable conditions

Path A: Engineering and Safety State

• 01Variant-specific Thermal Analysis
• 02Updated Hardware / Firmware Interaction Analysis
• 03Formal Equivalence Assessment
• 04Updated Safety Assessment and explicit Product Safety position

Path A: Quality and Product Compliance

Path A has no preferred outcome

Path B: Remodel the Release Decision Space

Three illustrative Remodel Candidates

The selected Remodel Candidate

• 01Field Firmware Update excluded
• 02Cross-Baseline Service Substitution excluded
• 03Untested mixed configurations excluded

The Candidate changes the actual decision

The Baseline Split creates a new Configuration State

• 01Incorrect Variant Effectivity
• 02Unintended H4 installation in S4-45
• 03Incorrect firmware binding
• 04Cross-Baseline Service Substitution
• 05Mixing in inventory or production

New Configuration-Management requirements

• 01Unambiguous H3 / H4 Revision Identity
• 02Variant-specific Effectivity and distinct Part Numbers
• 03Explicit firmware assignment
• 04Consistent PLM and ERP states
• 05Versioned Manufacturing Instructions and S4-45 Successor Conditions

New Manufacturing Controls

• 01Segregated material control
• 02Variant-specific work instructions
• 03H4 block for S4-45
• 04Baseline-specific End-of-Line Tests
• 05Serial-number and revision traceability
• 06Stop Triggers for Configuration Drift

New Service Controls

• 01Compatibility Matrix and spare-part identification
• 02Service Tool recognition
• 03Prohibition of Cross-Baseline Substitution
• 04Clear H3/H4 replacement rules
• 05Field Update remains excluded

External hard constraints remain preserved

The Remodel Candidate is not yet a Product Release

• 01No new PLM Effectivity exists yet.
• 02No new ERP and Manufacturing controls exist yet.
• 03No bound Service Compatibility exists yet.
• 04No Product Compliance assessment or release authority event exists yet.

v2 must be materialised

• 01Bind S4-08 and S4-22 to H4 / 4.8.0.
• 02Bind S4-45 to H3 / 4.7.2.
• 03Separate Part Numbers and revisions.
• 04Prevent wrong materials and H4 installation in S4-45.
• 05Bind End-of-Line, service parts, Field exclusion and documentation.
• 06Exercise authority for exactly this Split Release.

Decision Space v2

v1 and v2 are different decisions

Evidence may be inherited, but not blindly

Still relevant for S4-08 and S4-22

• 01Complete H4 / 4.8.0 Verification
• 02Fault Injection and Thermal Tests
• 03STO / SS1 Verification and Firmware Regression
• 04Manufacturing Validation

Not automatically inheritable

• 01Family-wide H4 statements
• 02S4-45 H4 Evidence
• 03Field-Update and Cross-Revision Service Evidence
• 04Assumptions of one common new baseline

The uncertainty changes

BRIDGE checks the transition

• 01Decision Classification and Configuration Identity
• 02Version Separation and Scope Delta
• 03Requirement Delta and Evidence Inheritance
• 04Open S4-45 State and Configuration Control
• 05Manufacturing and Service Readiness
• 06Risk Delta, Conditions, Product Compliance and Authority
• 07v1 Blocker Integrity and new v2 Blockers

A possible v2 State

An open state is not a blocker in every Decision Space

Factory Release remains separate from Field Update and Service

SEAL Eligibility for v2

What SEAL can hold for the Product Release

What SEAL explicitly does not claim

• 01The product is technically safe or legally marketable.
• 02IEC 61800-5-2 is fully satisfied or the product is CE-compliant.
• 03S4-45 H4 is safe or unsafe.
• 04Every conceivable test has been performed.
• 05Manufacturing cannot create a misconfiguration.
• 06An authority or conformity-assessment body approved the product.
• 07Future product liability is excluded.

Individual records do not automatically reconstruct the Release State

• 01Engineering Change and Bills of Material
• 02Software Build and Test Reports
• 03Safety Assessment and Deviation Records
• 04Release Notes and Manufacturing Instructions
• 05Board Approval and Service Documentation

T0: What was true at release?

• 01Historical baseline and proposed hardware / firmware combination
• 02Variants and affected Requirements in v1
• 03Evidence for S4-08 and S4-22
• 04Missing S4-45 Coverage and equivalence assumptions
• 05Professional positions and reason v1 was blocked
• 06Candidate, controls, exclusions and authority for v2

T1: A later diagnostic event

Later Outcome is not T0 Knowledge

Concrete later review questions

• 01Which hardware-and-firmware configuration was released?
• 02Which variants were included, and was S4-45 expressly excluded?
• 03Which tests covered S4-08 and S4-22, and which S4-45 tests were missing?
• 04Why could Evidence not automatically be transferred to S4-45?
• 05Who held authority over Evidence Inheritance and v2?
• 06How were H3 and H4 separated in PLM, ERP, Manufacturing and Service?
• 07Which later information was unavailable at T0?

Change Triggers after a possible v2 SEAL

An existing Factory Release State is not a blanket approval

• 01New firmware or hardware
• 02New variants, markets or production sites
• 03New service procedures or retrofit
• 04Field Update or Cross-Revision Substitution
• 05Later S4-45 H4 release

Real authority remains outside Epistemis

• 01Epistemis does not perform Safety Verification or Product Validation.
• 02It does not qualify components or independently assess Functional Safety.
• 03It does not interpret product law or determine whether a standard has been met.
• 04It does not accept technical Deviations or issue Design, Manufacturing or regulatory approval.
• 05It does not replace Product Safety, Quality or Product Compliance.

Why this case goes beyond PLM, QMS and Test Management

The Epistemis mechanism in four statements

• 01A blocker explains precisely why the proposed Scope is not finalisable.
• 02SIMULATION examines missing Current-Space Evidence or another Release Scope.
• 03BRIDGE checks which exploratory outcomes may enter a governed new State.
• 04SEAL holds only the bound State whose defined prerequisites are satisfied.