Aseguramiento / Técnico
Enterprise Business / Architecture Option Decision
The capability was accepted at the Phase 3 Integrated Acceptance Gate. Technology is selected second. No option is preferred because it already exists, was used in the prototype, or is organizationally familiar. No frozen invariant is reopened and no Technical Solution Definition is started here.
Preferred: OPTION C — HYBRID / FEDERATED ENTERPRISE MODEL
Option C preserves every frozen invariant (no-compensation, single mastership per object, fail-closed degradation, evidence lineage, human authorization) while introducing the smallest new enterprise surface. Q4 remains authoritative for validated Control-of-Work objects; Aconex, P6, Smart Completions, HR/Training and Forwood remain authoritative for their own objects; only the integrated decision context — which no system owns today — is newly mastered, under ADR-14 Option C stewardship. Option A is not preferred because it requires Q4 to master data it does not own, which fails the uncontrolled-authority and master-duplication decision conditions regardless of its lower change load or apparent licence cost.
OPTION B is the credible fallback and is functionally equivalent; it differs from C only by owning more of the capability than the object authority map requires. If the enterprise cannot govern object-level authority across the estate, B is preferred over C.
- · No product, vendor, licence or technology stack is selected by this recommendation.
- · No cost figure is asserted; no validated cost baseline exists.
- · No Technical Solution Definition is started. That requires a separate authorization.
- · No frozen structural invariant from A–G, 0B, 0C, H–AE, ADR-14 or Section X is reopened.
Next decision — Enterprise Option Selection → Technical Solution Definition Authorization
HOLD — Technical Solution Definition has not begun and must not begin until the enterprise option is formally selected by the competent authority.
B — Option architecture shapes
Object-level authority across the existing estate (Q4, Smart Completions, Aconex, P6, HR/Training, Forwood). Only the minimum decision-context and orchestration capability is introduced; nothing is re-mastered that an existing system already masters well.
OBJECT AUTHORITY MAP (each object has exactly one master)
Permits/Isolations -> Q4 Documents/Rev -> Aconex Schedule -> P6
Completions/ITR -> SC Competency -> HR/Trng CritCtrl -> Forwood
Location register -> Canonical Location Register (ADR-14 Option C, stewarded)
|
+----------------v-----------------+
| MINIMAL DECISION-CONTEXT LAYER |
| IRDE verdict + pinning + audit |
| (no re-mastering, no shadow SoR) |
+----------------+-----------------+
| verdict consumed by Q4 / field UXRequired option register
No weighted scoring is applied. No approved enterprise decision weights have been issued by a competent authority, so any numeric total would be an invented preference. Options are compared on qualified evidence per dimension and on the mandatory disqualification tests, which are pass/fail and cannot be offset by advantage elsewhere.
| Dimension | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alternative platform |
|---|---|---|---|---|
| CapabilityFit | PARTIAL Q4 natively supports safety documents, permits, isolations, competency checks at issue and work packs. Location Operational Context as a cumulative SIMOPS container, forecast readiness, PACE applicability composition and cross-source continuity are not native and require substantial customization outside Q4's transactional model. | STRONG Full accepted capability set (Functional + Preventive Readiness, Location context, Job Cards, current/forecast, SIMOPS pairwise + cumulative, critical control, continuity, fail-closed, reconstruction) is implemented where it belongs — upstream of authorization — as demonstrated by the Phase 1/2/2A prototype evidence. | STRONG Same functional coverage as B, with a deliberately smaller footprint: only IRDE verdict, decision pinning and location/SIMOPS context are new. Fit depends on each retained source exposing the attributes the ECE needs; unvalidated adapters are the residual gap. | PARTIAL Any capable platform could in principle host the capability, but no evidence has been produced showing capability advantage over B or C; low-code hosts additionally strain under deterministic engine and evidence-lineage requirements. |
| AuthorityIntegrity | WEAK Forces Q4 to become de-facto master of location, competency, schedule and forecast data it does not own. That is silent parallel mastership — explicitly rejected by the decision conditions and by ADR-14 Option C. | STRONG Q4 remains the single master of validated Control-of-Work objects; the readiness layer masters only integrated decision context and never writes authorization. Preserves 'System prepopulates, humans authorize'. | STRONG Object-level authority is explicit and stewarded; the Canonical Location Register is the only new master and it is governed under ADR-14 Option C with named stewards. | WEAK Most credible variants duplicate permit/competency/location masters or ambiguously overlap Q4's write authority. Cannot be recommended while that duplication is ungoverned. |
| IntegrationComplexity | PARTIAL Fewer endpoints for the field, but every source feed must be pushed into a vendor product on the vendor's terms; each feed becomes a supported customization and an upgrade liability. | PARTIAL Highest number of read adapters (7+), but all are read-only and independently degradable. Adapter existence for Forwood, HR/Training and Smart Completions is NOT validated and is carried as an open dependency. | ADEQUATE Same adapter surface as B, minus anything the minimal layer does not need. Complexity is bounded by the object authority map rather than by an ambition to centralize. | WEAK Adds a new platform's integration and identity surface on top of the existing estate with no offsetting reduction. |
| OperationalFit | PARTIAL Single tool for the field is a genuine adoption advantage. But readiness latency is bound to Q4's transactional cadence, and workface planning / lookahead is not Q4's design intent. | STRONG Purpose-built lookahead, shift and location-context journeys verified in Phase 2/2A; degraded mode and offline capture are designed in. Cost: two surfaces for supervisors unless embedded. | STRONG Same operational behaviour, and the minimal layer can be surfaced inside existing tools, lowering the two-surface adoption penalty. | PARTIAL Field usability unproven; would restart the Phase 1–2A verification cycle. |
| ControlIntegrity | PARTIAL Q4's own control model is sound, but no-compensation across non-Q4 dimensions (forecast, cumulative SIMOPS, cross-source gaps) would be implemented as customization, i.e. outside vendor-assured behaviour. | STRONG Non-compensable STOP, fail-closed unmapped states, behavioural authority gating and evidence-bearing HUMAN_CONFIRMED records are demonstrated in Phase 2A closure evidence. | STRONG Identical control semantics; the smaller code surface reduces the assurance burden of re-verifying control behaviour after each change. | PARTIAL Deterministic no-compensation and evidence lineage are achievable but unproven on the candidate hosts; low-code platforms typically cannot guarantee deterministic evaluation ordering. |
| Resilience | WEAK Single point of failure: if Q4 is unavailable, both authorization and readiness visibility are lost simultaneously. | STRONG Readiness layer degrades to HOLD/UNRESOLVED on source failure without blocking Q4's own authorization path; source failure is a fail-closed input, not an outage. | STRONG Failure is isolated per object master; the decision layer withholds a verdict rather than guessing. | PARTIAL Depends entirely on the chosen platform's SLA; no evidence available. |
| DataGovernance | WEAK Data ownership becomes implicit inside a vendor product; export and reconstruction depend on vendor data model stability. | ADEQUATE Explicit contracts and pinned decision snapshots; the readiness store holds derived context, not duplicated masters — but its retention and lineage policy must be formally issued. | STRONG Object authority map makes governance auditable by construction; the only new governed dataset is the Canonical Location Register. | WEAK New governance regime for a new estate, with duplication risk. |
| LifecycleCost | PARTIAL Lowest apparent licence delta, offset by vendor customization rates and recurring re-certification of customizations at every Q4 upgrade. No verified vendor quotation exists; no cost figure is asserted. | PARTIAL Highest build and run cost of the three credible options: a full capability to develop, host, support and evolve, plus 7+ adapters to maintain. No cost figure is asserted. | ADEQUATE Lowest total lifecycle exposure of the credible options on qualitative evidence: minimal new build, no re-mastering, reuse of existing licensed estate. Not quantified — no validated cost baseline exists. | WEAK New licences, new build, new support, plus migration of what already works. |
| TechnicalDebt | WEAK Customization debt accrues inside a vendor product — the least controllable form of debt, and it compounds at every upgrade. | PARTIAL Owned debt: modifiable, but the full capability plus adapter estate must be carried indefinitely. | ADEQUATE Smallest owned surface; existing systems continue to be maintained by their existing owners under existing contracts. | WEAK Debt of a parallel estate plus the debt of what it fails to replace. |
| Scalability | PARTIAL Scales where Q4 is deployed; projects and JVs without Q4 cannot use the capability at all. | STRONG Source-agnostic by construction; a project with different sources needs new adapters, not a new capability. | STRONG Same source-agnostic scaling, with the lowest per-project onboarding cost because the layer is thin. | PARTIAL Scales only as far as the new platform's licensing and deployment model allows. |
| ChangeImpact | ADEQUATE Lowest surface change for users already in Q4 — the one clear advantage of Option A. | WEAK New tool, new roles, new stewardship, new daily rituals; requires funded organizational change (P3-TRN-01). | PARTIAL Moderate: new stewardship roles and a new decision ritual, but users largely stay in the tools they know. | WEAK Maximum change: new platform plus migration plus retraining. |
C — Capability-to-option fit matrix
| Accepted capability | A | B | C | D | Evidence note |
|---|---|---|---|---|---|
| Functional Readiness (scope, materials, access, permits, schedule) | ADEQUATE | STRONG | STRONG | PARTIAL | Q4 sees permits and work packs, but not P6 float, Aconex revision state or completions status without new feeds. |
| Preventive Readiness (PACE applicability & composition) | PARTIAL | STRONG | STRONG | PARTIAL | Composition of the preventive package from hazard × task × location × equipment is not a Q4 native construct. |
| Location Operational Context (canonical register, inheritance) | WEAK | STRONG | STRONG | PARTIAL | ADR-14 Option C requires a federated canonical register with stewardship; embedding it in Q4 creates a shadow master. |
| Job Cards as the decision context | ADEQUATE | STRONG | STRONG | PARTIAL | Q4 work packs are close but transactional; the job card must aggregate non-Q4 sources. |
| Current + Forecast Readiness (weather, competency expiry, document expiry) | WEAK | STRONG | STRONG | PARTIAL | Forecast is a planning-horizon construct; Q4 evaluates at issue time, not across a lookahead window. |
| SIMOPS pairwise + cumulative (CUM-1…CUM-7) | WEAK | STRONG | STRONG | PARTIAL | Cumulative evaluation across concurrent job cards at one location has no Q4 equivalent. |
| Critical Risk / Critical Control verification | PARTIAL | STRONG | STRONG | PARTIAL | Requires Forwood (or equivalent) integration in every option; adapter not yet validated. |
| Discipline continuity across shifts and handovers | WEAK | STRONG | STRONG | PARTIAL | Continuity spans permits, personnel and location state simultaneously. |
| Fail-closed behaviour on unmapped / missing source state | PARTIAL | STRONG | STRONG | PARTIAL | Phase 0C determinism must hold for all sources, not only the host platform's own data. |
| Evidence reconstruction of any past decision | PARTIAL | STRONG | STRONG | WEAK | Requires pinned versions of every consumed input, including those mastered elsewhere. |
D — Authority / system-of-record comparison
Any option requiring a silent parallel master is rejected on that basis alone.
| Object | Master today | Option A | Option B | Option C | Risk |
|---|---|---|---|---|---|
| Permit to Work / Isolation / Safety Document | Q4 | Q4 (unchanged) | Q4 (unchanged) — readiness layer reads only | Q4 (unchanged) | None in A/B/C. Option D risks displacing an assured authorization record. |
| Engineering document + revision state | Aconex | Copied into Q4 → shadow master | Aconex, pinned by version at decision time | Aconex, pinned by version at decision time | Version pinning is mandatory; a copied revision that drifts silently invalidates every past decision. |
| Schedule / lookahead window | P6 | Copied into Q4 → shadow master | P6 | P6 | Duplicated schedule masters produce contradictory lookaheads between planning and field. |
| Competency / training / medical fitness | HR / Training / Health | Q4 holds its own competency lists → duplication (already a known Q4 pattern) | HR/Training remains master; Q4 competency use is reconciled, not replaced | HR/Training remains master; explicit reconciliation contract | This duplication exists today and must be governed under CA-03 in whichever option is selected. |
| Critical control verification | Forwood (or equivalent) | Feed into Q4 | Forwood | Forwood | Adapter not validated in any option — open dependency, not an option discriminator. |
| Location canonical identity + operational context | None (fragmented across systems) | Q4 becomes de-facto master — not its role | Canonical Location Register inside the readiness capability, stewarded | Canonical Location Register as a governed federated register, stewarded | ADR-14 Option C requires named stewardship; unstaffed stewardship ⇒ AuthorityResolutionState = UNRESOLVED, capabilities DISABLED_SAFE. |
| Integrated readiness verdict + pinned decision snapshot | None | Q4 (mixed with transactional records) | Readiness capability | Minimal decision-context layer | Must never be writable by a source system, and must never itself authorize work. |
Critical decision conditions (pass/fail — cannot be offset)
| Test | A | B | C | D |
|---|---|---|---|---|
| Weakens no-compensation | No — but the rule would be implemented as customization, weakening its assurance. | No | No | Unproven on candidate hosts |
| Creates uncontrolled authority | Yes — Q4 becomes de-facto master of location, schedule and competency context it does not own. | No | No | Likely |
| Requires non-governed master duplication | Yes | No | No | Likely |
| Cannot preserve evidence lineage | Partially — lineage to non-Q4 sources depends on copies rather than pinned source versions. | No | No | Unproven |
| Cannot operate safely under source failure | Q4 outage removes both authorization and readiness simultaneously. | No — degrades fail-closed | No — degrades fail-closed | Unproven |
H — Open ADR / dependency treatment
No unresolved decision is hidden inside the recommendation. Each remains visible and owned.
| Dependency | Question | A | B | C | Blocking status |
|---|---|---|---|---|---|
| ADR-03 | Canonical identity + semantic reconciliation across sources | Resolved implicitly by absorbing everything into Q4 — i.e. resolved by duplication, which is not acceptable. | Must be resolved explicitly as part of the readiness capability's contract set. | Resolved by the object authority map; this option forces the answer into the open rather than hiding it. | Must be resolved as part of the selected enterprise option (Phase 3 condition). |
| ADR-13 / CA-01 | Legal/regulatory status and binding of an authorization record | Q4 already carries the record; binding question narrows but does not disappear. | Q4 remains the authorization record holder; readiness records are advisory and must be labelled as such. | Same as B, with explicit object-level statement of which record is legally operative. | Must be resolved before any real (non-synthetic) authorization record is created — all options. |
| ADR-15…24 | Controlled open architecture decisions | Several become vendor-constrained rather than enterprise-decided. | Remain enterprise-decidable and visible. | Remain enterprise-decidable and visible. | Visibility must be retained in all options (Phase 3 condition); Option A degrades that visibility. |
| CA-03 | Competency mastership duplication | Worsens: Q4 competency lists become the operative set. | Addressed by reconciliation contract; duplication remains until closed. | Addressed by the object authority map with a named master. | Closure required as part of the selected enterprise option. |
| CA-04 | Cross-source gap attribution and ownership of remediation | Attribution collapses into 'Q4 says no' with weak upstream traceability. | Fully attributable — demonstrated in Phase 2A F-02 closure. | Fully attributable via the object authority map. | Not gating for option selection; gating for solution definition. |
| OfflineAuthorization | Deterministic offline capture and reconciliation without stale authorization | Bounded by Q4's own offline model; unverified for readiness context. | Designed for: offline captures, never authorizes against stale context (CF-03). | Same as B, with a smaller offline payload. | Deterministic offline reconciliation must be demonstrated before implementation — all options. |
| Stewardship staffing (ADR-14) | Are location and SIMOPS stewards named and funded? | Still required; Q4 does not supply governance roles. | Required; capability enforces DISABLED_SAFE when vacant (G-01). | Required; same enforcement. | Mandatory in all options. Not an option discriminator — it is an organizational precondition. |
| Organizational change | Is adoption funded and led? | Lowest change load. | Highest change load. | Moderate change load. | Must be funded before implementation (Phase 3 condition). |
| Enterprise IAM binding | Authority and delegation bound to enterprise identity | Q4 IAM binding; delegation model may not match ADR-14 stewardship. | Must bind to enterprise IAM; currently prototype-session only. | Must bind to enterprise IAM; currently prototype-session only. | Gating for implementation in all options (P3 High finding). |
I — Residual risk comparison
Adapter availability for Forwood, HR/Training and Smart Completions is asserted, not validated. No API has been confirmed.
Treatment — Integration feasibility spike per source before Technical Solution Definition. Any source without a validated read path is carried as fail-closed (HOLD), never assumed available.
Vendor extension of Q4 would place mandatory control logic under vendor release control.
Treatment — Not accepted; contributes to Option A not being preferred.
A separately-built capability could drift from Q4's evolving CoW semantics, producing readiness verdicts based on stale assumptions about permit states.
Treatment — Versioned interface contract with Q4 state mapping; unmapped Q4 state ⇒ fail-closed (already demonstrated in the Q4-unmapped scenario).
The 'minimal' layer in Option C erodes over time into a de-facto second platform if scope is not governed.
Treatment — Object authority map is a controlled artefact; any proposal to master a new object in the decision layer requires design-authority approval.
No validated cost baseline exists for any option. Economics are qualitative only.
Treatment — Costed business case required as an input to Technical Solution Definition Authorization. No cost or saving is invented at this gate.
Stewardship roles remain unstaffed; capability enters DISABLED_SAFE and delivers no operational value.
Treatment — Phase 3 mandatory condition; organizational commitment required before implementation start.
J — Preferred option, across the full enterprise lifecycle
Why Option C works — every accepted capability is delivered, each object keeps exactly one governed master, degradation is fail-closed per source, and evidence lineage is reconstructible because decisions pin source versions rather than copies.
Why it is preferable over the alternatives — it delivers the same functional and control outcome as Option B with the smallest new enterprise surface, the lowest owned technical debt, no vendor release dependency on mandatory control logic, and the ability to onboard projects whose source estate differs. It reuses the licensed estate instead of displacing it, and it forces the open architecture decisions (ADR-03, CA-03) into an explicit object authority map rather than resolving them by silent duplication.
K — Why the other options are not preferred
Fails two mandatory decision conditions: it creates uncontrolled authority and requires non-governed master duplication (location, schedule, competency). It also places non-compensation logic under vendor release control and couples authorization availability to readiness availability. Its genuine advantages — lowest change load, single field tool, existing licences — cannot offset a pass/fail condition.
Not rejected; architecturally sound and the credible fallback. It is not preferred only because it owns more capability than the object authority map requires, carrying higher build, run, adoption and lifecycle cost for no additional control or capability benefit over C.
No evidence in the accepted baseline demonstrates material advantage over A, B or C. It adds a new estate, new integration and identity surface, migration of systems that already work, and duplication risk. It is retained in the register only as a tested and rejected alternative, not for completeness.
PHASE 4 REV.2 — ACCEPT (2026-08-30). Option C selected as governing Enterprise Option; Option B controlled fallback (explicit architecture decision required to move C→B); A and D rejected under non-compensable §18. Phase 5 Technical Solution Definition requires separate disposition — no API, database, deployment, pilot, or live integration authorized.
Selected: Option C — Hybrid / Federated Enterprise Model
Option B — Q4 + Integrated Readiness Capability, retained as a live fallback contingent on mapping-stewardship staffing
Option C is not selected for greater functional capability: Option B and Option C are materially capability-equivalent. Option C is preferred because its federation model provides a structurally stronger enterprise lifecycle position — the added federation burden is accepted only because it improves AuthorityIntegrity, SourceOwnershipPreservation, EnterpriseScalability, Cross-SystemDecisionContext, and ArchitectureFlexibility. No implementation team may silently simplify Option C into Option B.
Preserved as Controlled Open (Option C selection closes none): ADR-03; ADR-13 / CA-01; ADR-15…24; CA-03; CA-04; OfflineAuthorization; ADR-14 stewardship staffing; P3-TRN-01 organizational change.
Every accepted capability is delivered, each object retains exactly one governed master, degradation is fail-closed per source, authority is enforced server-side across all six verbs, and evidence is reconstructible because decisions pin source versions rather than copies.
Location remains the context container and never the authorizer; SIMOPS is evaluated cumulatively across concurrent job cards; functional and preventive readiness stay non-compensable; the system prepopulates and humans authorize.
The object authority map is an explicit deliverable rather than an emergent property. No silent parallel master is created, and unresolved mappings fail closed instead of resolving to the most recent value.
It requires read-dominant reference integration and one verdict reference back to the transactional authority. It does not require a canonical master to be invented beyond the ADR-14 location register already authorized.
Same capability and control outcome as B with the smallest owned logic surface, the lowest owned technical debt, no vendor release dependency on mandatory control logic, localized failure, and project onboarding as a mapping exercise rather than capability rework.
- · No platform, product, vendor or licence model is selected.
- · No API, database, middleware, cloud service or deployment technology is chosen.
- · No cost, effort or schedule figure is asserted.
- · No ADR is closed by this recommendation.
- · No pilot or live integration is authorized.
B — Capability fit matrix (classified)
"Possible to customize" is not equated with "architecturally suitable".
| Capability | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform | Evidence note |
|---|---|---|---|---|---|
| WorkDemand | EXTENSION_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | Demand originates upstream of Control-of-Work; no evidenced native demand object in the CoW estate. |
| JobCard | NATIVE | NATIVE | NATIVE | EXTENSION_REQUIRED | Job Card / work item exists natively in the transactional estate; readiness layer references, never re-masters it. |
| WorkPackage | CONFIGURABLE | CONFIGURABLE | CONFIGURABLE | EXTENSION_REQUIRED | IWP/WorkPackage is mastered in planning/completions systems; CoW consumes it as reference. |
| Location Operational Context | NOT_CREDIBLY_SUPPORTED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | ADR-14 Option C requires a stewarded canonical location register with cumulative context; no evidenced native equivalent. |
| Functional Enabling Conditions | EXTENSION_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | ECE spans documents, schedule, completions and engineering state — outside any single platform's governed objects. |
| Preventive Applicability (PACE) | NOT_CREDIBLY_SUPPORTED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | Applicability/composition over cross-source attributes is not a Control-of-Work function. |
| IPERC | CONFIGURABLE | CONFIGURABLE | CONFIGURABLE | EXTENSION_REQUIRED | Risk-assessment registers exist natively; continuity/reassessment triggers require external decision context. |
| PETAR / Work Control | NATIVE | NATIVE | NATIVE | EXTENSION_REQUIRED | High-risk permit routing is the native strength of the CoW platform and must remain there. |
| Critical Control | EXTENSION_REQUIRED | CONFIGURABLE | CONFIGURABLE | EXTENSION_REQUIRED | Critical-control verification is mastered in the CCM estate (Forwood or equivalent); mapping only. |
| CurrentReadiness | EXTENSION_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | Deterministic non-compensable verdict over federated inputs; must sit where all inputs are visible. |
| ForecastReadiness | NOT_CREDIBLY_SUPPORTED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | NOT_CREDIBLY_SUPPORTED | Forecast requires validity horizons, expiry projection and environmental prediction; no evidenced native support. |
| SIMOPS (pairwise + cumulative) | NOT_CREDIBLY_SUPPORTED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | NOT_CREDIBLY_SUPPORTED | CUM-1…7 are cumulative location-scoped rules across concurrent job cards, not per-permit checks. |
| Location Continuity (Section X) | NOT_CREDIBLY_SUPPORTED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | NOT_CREDIBLY_SUPPORTED | Continuity across shift/discipline handover is a decision-context property, not a permit property. |
| Change / Reassessment | EXTENSION_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | Selective vs broad reassessment depends on pinned source versions held by the decision layer. |
| Assurance | EXTENSION_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | Cross-source assurance cannot be produced by a system that sees only its own objects. |
| Evidence Reconstruction | EXTENSION_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTERNAL_CAPABILITY_REQUIRED | EXTENSION_REQUIRED | Source → version → rule → decision → validation → authorization chain must be pinned at decision time. |
C — Object-level authority comparison
| Object | Master today | A | B | C | D | Note |
|---|---|---|---|---|---|---|
| ControlledDocument | Aconex | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Revision authority must never leave the document system; A copies revisions into CoW. |
| Requirement | Engineering / spec estate | UNRESOLVED | FEDERATED | FEDERATED | UNRESOLVED | Requirement mastership is an open enterprise question (CA-03). |
| P6Activity | P6 | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Schedule dates re-keyed into CoW create silent divergence. |
| WBS | P6 / Project Controls | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Same divergence class as P6Activity. |
| IWP | Smart Completions / BCSTools | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | IWP composition is a completions function. |
| WorkPackage | Planning / completions | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Readiness layer holds a projection keyed to the master, never a rival record. |
| JobCard | Work management / CoW | PRESERVED | PRESERVED | PRESERVED | DUPLICATED | All credible options keep the job card where execution happens. |
| Location | None — ADR-14 canonical register required | UNCONTROLLED | FEDERATED | FEDERATED | UNCONTROLLED | A and D make the platform an unstewarded de-facto location master. |
| Equipment | Asset / engineering register | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Tag authority stays with the asset register. |
| Person | HR / IAM | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Local person records in CoW drift from HR terminations. |
| Competency | Training system | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Expiry must be read from the training master or declared UNVERIFIABLE. |
| Fitness | Health | UNCONTROLLED | FEDERATED | FEDERATED | UNCONTROLLED | Health data requires purpose-bound federation, never copy. |
| Restriction | Health / HR | UNCONTROLLED | FEDERATED | FEDERATED | UNCONTROLLED | Restrictions govern assignment eligibility; copy is both stale and a privacy exposure. |
| RiskAssessment | CoW / IPERC register | PRESERVED | PRESERVED | PRESERVED | DUPLICATED | Stays transactional in all credible options. |
| CriticalControl | CCM (Forwood or equivalent) | DUPLICATED | FEDERATED | PRESERVED | DUPLICATED | Verification events are owned by the CCM estate. |
| Permit | Q4 | PRESERVED | PRESERVED | PRESERVED | DUPLICATED | Authorization must remain in one transactional authority. |
| PETAR | Q4 | PRESERVED | PRESERVED | PRESERVED | DUPLICATED | As permit. |
| Isolation | Q4 | PRESERVED | PRESERVED | PRESERVED | DUPLICATED | As permit. |
| SanctionToTest | Q4 | PRESERVED | PRESERVED | PRESERVED | DUPLICATED | As permit. |
| TemporaryModification | Engineering / MOC | UNRESOLVED | FEDERATED | FEDERATED | UNRESOLVED | MOC mastership remains an open enterprise decision. |
| ReadinessDecision | None — new object | UNCONTROLLED | PRESERVED | PRESERVED | UNCONTROLLED | New governed object; must be mastered by the readiness capability with pinned inputs. |
| EvidenceEvent | None — new object | UNCONTROLLED | PRESERVED | PRESERVED | UNCONTROLLED | Immutable evidence including denied attempts. |
Any option requiring UNCONTROLLED authority or material DUPLICATED MASTER to function is structurally unacceptable unless a competent enterprise authority explicitly redesigns that ownership model. Lower cost, faster deployment or organizational familiarity cannot compensate.
- · A — FAIL — 5 UNCONTROLLED and 11 DUPLICATED masters are load-bearing, not incidental.
- · B — PASS — no UNCONTROLLED pattern; duplication avoided by read-only federation.
- · C — PASS — every object keeps exactly one governed master; new objects are explicitly mastered.
- · D — FAIL — reproduces A's pattern while adding a migration of systems that already work.
D — Federation / identity viability
| Federated key | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform | Common-key availability |
|---|---|---|---|---|---|
| Project_ID | Local re-key | Mapped, stewarded | Mapped, stewarded | Full re-key on migration | Present in most sources, inconsistent format |
| Location_ID | Invented inside platform, unstewarded | Canonical register, stewarded | Canonical register, stewarded | Invented inside platform | No common key today (ADR-14 gap) |
| Equipment_ID | Local copy | Mapped with conflict queue | Mapped with conflict queue | Migrated copy | Tag exists; format varies by discipline |
| P6_Activity_ID | Re-keyed manually | Direct reference | Direct reference | Re-keyed | Stable in P6 |
| WBS_ID | Re-keyed manually | Direct reference | Direct reference | Re-keyed | Stable in P6 |
| IWP_NO | Free-text field | Direct reference | Direct reference | Migrated | Stable in completions |
| WorkPackage_ID | Platform-local | Mapped projection | Mapped projection | Platform-local | Varies by project |
| JobCard_ID | Native | Native + referenced | Native + referenced | Migrated | Owned by work management |
| Person_ID | Local user list | IAM-federated | IAM-federated | Local user list | HR/IAM authoritative |
No enterprise common key exists today for Location. Nothing in this phase invents a canonical master; ADR-14 Option C already authorizes a stewarded canonical Location register, and that is the only new register assumed.
Options B and C require named mapping stewards per source (Phase 3 residual P3-EA-01). A and D assume mapping is a technical import, which is exactly how unresolved mappings enter operational decisions.
Unresolved or conflicting mappings must fail closed (UNVERIFIABLE → HOLD), never resolve to the most recent value.
Mappings are versioned and effective-dated so a historical decision resolves against the mapping in force at decision time.
Project scoping is mandatory: identical tags across projects must not collide.
- · A — OPTION_DEPENDENT_RISK — resolves ADR-13/CA-01 by fiat inside one platform, which is the failure mode CA-01 was raised against.
- · B — ENTERPRISE_DECISION_REQUIRED — forces the mapping authority question into the open and requires a named steward.
- · C — ENTERPRISE_DECISION_REQUIRED — same, plus an explicit object authority map as a deliverable.
- · D — OPTION_DEPENDENT_RISK — migration hides the mapping decision inside a data conversion.
E — Integration viability map
No API is assumed to exist. Where no interface is evidenced, the option carries the cost of establishing one, and the affected inputs are treated as UNVERIFIABLE until an interface is proven. Counts of interfaces are comparable only within the same dependency class: a read/reference dependency is not equivalent to a write or transactional dependency.
| System | Dependency class | A | B | C | D | Why |
|---|---|---|---|---|---|---|
| Q4 (Control of Work) | Transactional + event | LOW | HIGH | MODERATE | VERY_HIGH | B needs bi-directional prepopulate/verdict exchange; C consumes state and returns a verdict reference only; D must replace it. |
| Aconex | Read / reference + version pinning | HIGH | MODERATE | MODERATE | HIGH | Revision-level pinning is required; A additionally has to store copies it must then keep current. |
| P6 | Read / reference | HIGH | MODERATE | MODERATE | HIGH | Schedule windows drive forecast; read-only reference is sufficient for B and C. |
| Smart Completions / BCSTools | Read / reference | HIGH | MODERATE | MODERATE | VERY_HIGH | ITR/IWP completion state feeds functional enabling conditions. |
| Engineering systems | Read / reference | VERY_HIGH | HIGH | HIGH | VERY_HIGH | Heterogeneous estate; no assumed API. Treated as evidence-bearing reference only. |
| HR / RRLL | Read / reference | HIGH | MODERATE | MODERATE | HIGH | Person, assignment and restriction data; privacy-bounded projection only. |
| Training | Read / reference | HIGH | MODERATE | MODERATE | HIGH | Competency validity and expiry horizon for forecast. |
| Health | Read / reference (purpose-bound) | VERY_HIGH | HIGH | HIGH | VERY_HIGH | Fitness/restriction must be consumed as eligibility flags, never as clinical data. |
| Forwood or equivalent CCM | Read / event | HIGH | MODERATE | MODERATE | HIGH | Critical-control verification events; mapping to job card scope is the hard part, not transport. |
| IAM | Transactional (authN/authZ claims) | MODERATE | MODERATE | MODERATE | HIGH | Server-side authority enforcement depends on it in every option; Phase 3 gating action. |
| Analytics | Read (derived) | LOW | LOW | LOW | MODERATE | Consumes decisions; never a source of authority. |
F — Authority enforcement comparison
| Capability verb | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform |
|---|---|---|---|---|
| CanView | Role-based, platform-native | Server-side, IAM-claims | Server-side, IAM-claims | Platform-native |
| CanPropose | Not distinguished from approve in evidenced configuration | Distinct verb, enforced in decision layer | Distinct verb, enforced in decision layer | Not evidenced |
| CanValidate | Approximated by workflow step | Distinct, attributable | Distinct, attributable | Not evidenced |
| CanApprove | Native | Native in Q4 | Native in Q4 | Requires build |
| CanAuthorize | Native | Native in Q4 | Native in Q4 | Requires build |
| CanAdminister | Native but coarse | Split: rule admin ≠ transaction admin | Split: rule admin ≠ transaction admin | Requires build |
| Role × Area × Activity × Shift × Risk × RegisterType | Not credibly supported without extension; risk of collapse to role-only | Supported by design as an ABAC decision | Supported by design as an ABAC decision | Not demonstrated |
UI hiding is not authority enforcement. Phase 2A already demonstrated behavioural denial with sideEffect = NONE and a recorded denied-attempt event; any option that can only restrict at the presentation layer is flagged. Option A is flagged on the six-dimensional ABAC test; Option D is flagged as not demonstrated.
G — Offline / resilience comparison
| Option | Capture | Decision | Authorization | Reconciliation | Verdict |
|---|---|---|---|---|---|
| OPTION A | CREDIBLE WITH DEPENDENCY | Offline decision would be computed against platform-local copies — the copies are the stale risk | Structurally tempting to allow, because the platform is also the authorization authority | Conflict detection limited to objects the platform masters | HIGH RISK |
| OPTION B | CREDIBLE | Decision recomputed on reconnect against pinned source versions | Never offline — authorization stays a Q4 online transaction | Immutable pending events, explicit recovery verification | CREDIBLE WITH DEPENDENCY |
| OPTION C | CREDIBLE | Same as B; decision layer holds the pin | Never offline — same rule | Per-source reconciliation with per-source staleness state | CREDIBLE WITH DEPENDENCY |
| OPTION D | NOT DEMONSTRATED | No evidence in the accepted baseline | No evidence | No evidence | NOT DEMONSTRATED |
| Fail-closed / resilience test | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform |
|---|---|---|---|---|
| CURRENT / STALE / UNVERIFIABLE preserved per source | Collapses to one platform availability state | Preserved per source | Preserved per source | Not demonstrated |
| Mandatory input missing → HOLD | Possible but bypassable by the copy that is still present | Enforced | Enforced | Not demonstrated |
| Authority unresolved → DISABLED_SAFE | Not evidenced | Enforced (G-01 demonstrated) | Enforced (G-01 demonstrated) | Not demonstrated |
| Technology failure never becomes operational authorization | At risk — readiness and authorization share one availability envelope | Held — separate envelopes | Held — separate envelopes per source | Not demonstrated |
| Silent stale-data use for critical decisions | Structurally possible | Rejected by design | Rejected by design | Not demonstrated |
H — Rule / configuration governance comparison
| Rule set | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform |
|---|---|---|---|---|
| Applicability | Vendor-release coupled | Governed in readiness capability | Governed in readiness capability | Vendor-release coupled |
| Frequencies / validity | Partially configurable | Versioned, effective-dated | Versioned, effective-dated | Unknown |
| Q4 state mappings | Implicit — no mapping object | Explicit, versioned, fail-closed on unmapped | Explicit, versioned, fail-closed on unmapped | N/A — new state model |
| No-compensation classifications | Under vendor release control | Under project governance | Under project governance | Unknown |
| SIMOPS CUM-1…7 | Not credibly supported | Configurable, approved, versioned | Configurable, approved, versioned | Not demonstrated |
| Inheritance (context, never authorization) | Risk of inheriting authorization with context | Explicit separation | Explicit separation | Not demonstrated |
| Authority rules | Coarse role model | ABAC, versioned | ABAC, versioned | Not demonstrated |
| Critical-control mappings | Local copy | Mapped to CCM master | Mapped to CCM master | Local copy |
ADR-16 (rule/configuration governance) is REQUIRES_PHASE_5 under B and C: both make rules first-class governed artefacts — versioned, project-scoped, approved, effective-dated and auditable — but neither designs the rule engine here. Under A, ADR-16 becomes OPTION_DEPENDENT_RISK because mandatory control logic sits inside vendor release cycles, so project-scoped effective-dating cannot be guaranteed. Under D it is CONTROLLED_OPEN with no evidence.
I — Evidence / reconstruction comparison
| Reconstruction aspect | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform |
|---|---|---|---|---|
| Source → version pinning at decision time | Copies, not pins — the copy can be overwritten | Pinned reference to source version | Pinned reference to source version | Not demonstrated |
| Rule version recorded with decision | Not evidenced | Recorded | Recorded | Not demonstrated |
| Decision explanation (which input drove the verdict) | Partial | Full, per-condition | Full, per-condition | Not demonstrated |
| Human validation attribution (who, role, when, context) | Native for permits only | Full across readiness and authorization | Full across readiness and authorization | Not demonstrated |
| Denied-attempt evidence | Not evidenced | Recorded (Phase 2A F-05) | Recorded (Phase 2A F-05) | Not demonstrated |
| Immutable historical baseline reconstruction | Compromised by mutable copies | Credible | Credible | Not demonstrated |
J — Operational fit
| Operational aspect | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform |
|---|---|---|---|---|
| Field usability | Best — one tool, already adopted | Two surfaces; field still authorizes in Q4 | Two surfaces; verdict surfaced inside the field tool | New tool, full re-adoption |
| Superintendent decision clarity | Permit-centric, not location-centric | Location-centric readiness view | Location-centric readiness view | Not demonstrated |
| Lookahead use | Weak — no forecast object | Strong | Strong | Not demonstrated |
| Location context | Not credibly supported | Supported | Supported | Not demonstrated |
| Multi-discipline concurrent work | Per-permit view only | Supported | Supported | Not demonstrated |
| SIMOPS cumulative | Not credibly supported | Supported | Supported | Not demonstrated |
| Blocker ownership | Ownership implicit in workflow step | Explicit owner + action + evidence ref | Explicit owner + action + evidence ref | Not demonstrated |
| Forecast | Not credibly supported | Supported | Supported | Not demonstrated |
| Continuity across handover | Not credibly supported | Supported | Supported | Not demonstrated |
| Change / reassessment scope control | Broad reassessment only | Selective, version-driven | Selective, version-driven | Not demonstrated |
Option A forces operations to adapt to the software structure: the operating model becomes permit-centric because that is what the platform masters. Options B and C preserve the accepted location- and readiness-centric operating model. Option D forces adaptation to an unevidenced structure and additionally discards adoption already achieved.
K — Supportability / technical-debt preview
| Dimension | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform |
|---|---|---|---|---|
| CustomizationBurden | VERY_HIGH — core control logic becomes customization | MODERATE — logic in a purpose-built capability | MODERATE — smallest owned surface of the credible options | VERY_HIGH |
| IntegrationBurden | HIGH — every source must be imported, not referenced | HIGH — full source set plus bi-directional Q4 | MODERATE/HIGH — full source set, read-dominant | VERY_HIGH |
| ConfigurationBurden | MODERATE | HIGH — rules are first-class and must be governed | HIGH — same, plus the object authority map | HIGH |
| VendorDependency | VERY_HIGH — mandatory control logic under vendor release control | MODERATE | LOW/MODERATE | VERY_HIGH |
| UpgradeRisk | VERY_HIGH — customization vs upgrade path conflict | MODERATE | MODERATE | HIGH |
| SupportComplexity | MODERATE — one platform to support | HIGH — two governed surfaces | HIGH — two surfaces plus federation adapters | VERY_HIGH |
| SpecialistSkillDependency | HIGH — vendor specialists | HIGH — internal capability team | HIGH — internal capability team plus mapping stewards | VERY_HIGH |
| ArchitectureDriftRisk | VERY_HIGH — every unmet need becomes another local master | MODERATE — boundary must be actively policed | MODERATE — object authority map is the control | HIGH |
Qualitative only. No verified quantitative cost, effort or licence evidence exists in the accepted baseline, so no monetary values are manufactured. Note honestly: A has the lowest support complexity of all options — one platform, one support contract — and that advantage is real. It simply cannot offset a pass/fail authority failure.
L — Organizational / change impact
| Change aspect | A — Extend Q4 | B — Q4 + Readiness | C — Hybrid federated | D — Alt platform |
|---|---|---|---|---|
| Stewardship staffing (ADR-14) | Unstaffed and unacknowledged — worst case | Required and explicit | Required and explicit, plus mapping stewards per source | Required, unspecified |
| New decision rights | Few new rights; existing rights silently widened | Propose/validate/authorize split must be socialized | Same, plus object authority ownership per source | Full redefinition |
| Configuration ownership | Vendor + platform admin | Project rule governance body required | Project rule governance body required | Unknown |
| User adoption | Lowest — familiar tool | Moderate — second surface for supervisors | Moderate — verdict surfaced in the existing tool reduces the delta | Highest — full replacement |
| Field change | Minimal | Moderate | Moderate | Severe |
| Training | Incremental | New readiness concepts + roles | New readiness concepts + roles | Complete re-training |
| Governance overhead | Understated — governance moves to vendor cycles | Explicit and ongoing | Explicit and ongoing | Explicit and largest |
| Bypass / workaround risk | HIGH — a permit-centric tool invites offline readiness spreadsheets | MODERATE — two surfaces invite short-cutting the upstream one | MODERATE — mitigated by surfacing the verdict where work is authorized | HIGH |
Phase 3 finding P3-TRN-01 (organizational change load) is carried forward unchanged and is NOT closed by any option. B and C both require a funded change programme, named stewards and a governance body before implementation. Neither is presented as low risk: their adoption model is the largest non-technical exposure in this decision, and C's advantage over B on adoption is marginal, not decisive.
M — Open ADR treatment matrix
| ADR / CA | Question | A | B | C | D | Note |
|---|---|---|---|---|---|---|
| ADR-03 | Requirement / engineering mastership boundary | OPTION_DEPENDENT_RISK | ENTERPRISE_DECISION_REQUIRED | ENTERPRISE_DECISION_REQUIRED | OPTION_DEPENDENT_RISK | A and D resolve it by absorption, which is not a decision. |
| ADR-13 / CA-01 | Federated identity and mapping authority | OPTION_DEPENDENT_RISK | ENTERPRISE_DECISION_REQUIRED | ENTERPRISE_DECISION_REQUIRED | OPTION_DEPENDENT_RISK | Mapping stewardship must be named; no option closes it. |
| ADR-15 | Decision pinning and baseline immutability | CONTROLLED_OPEN | REQUIRES_PHASE_5 | REQUIRES_PHASE_5 | CONTROLLED_OPEN | Mechanism is Phase 5; the obligation is accepted now. |
| ADR-16 | Rule and configuration governance | OPTION_DEPENDENT_RISK | REQUIRES_PHASE_5 | REQUIRES_PHASE_5 | CONTROLLED_OPEN | See ADR-16 impact statement. |
| ADR-17…24 | Remaining structural decisions | CONTROLLED_OPEN | REQUIRES_PHASE_5 | REQUIRES_PHASE_5 | CONTROLLED_OPEN | Carried visibly; none is made easier-therefore-closed. |
| CA-03 | Object mastership closure across the estate | OPTION_DEPENDENT_RISK | ENTERPRISE_DECISION_REQUIRED | ENTERPRISE_DECISION_REQUIRED | OPTION_DEPENDENT_RISK | C makes the map an explicit deliverable; it still needs an enterprise owner. |
| CA-04 | Cross-source assurance obligations | CONTROLLED_OPEN | REQUIRES_PHASE_5 | REQUIRES_PHASE_5 | CONTROLLED_OPEN | |
| OfflineAuthorization | Interim rule: offline never authorizes | OPTION_DEPENDENT_RISK | CONTROLLED_OPEN | CONTROLLED_OPEN | CONTROLLED_OPEN | Interim rule stands under every option; A is flagged because the structure invites relaxing it. |
| ADR-14 Stewardship | Who staffs location stewardship | ENTERPRISE_DECISION_REQUIRED | ENTERPRISE_DECISION_REQUIRED | ENTERPRISE_DECISION_REQUIRED | ENTERPRISE_DECISION_REQUIRED | Unresolved in all options; fail-closed behaviour (G-01) is the interim control. |
| OrganizationalChange | Adoption, training and governance load | OPTION_DEPENDENT_RISK | ENTERPRISE_DECISION_REQUIRED | ENTERPRISE_DECISION_REQUIRED | OPTION_DEPENDENT_RISK | P3-TRN-01 carried; funding decision required. |
No ADR is marked closed because an option makes it easier.
N — Option C vs Option B pre-escape test
| Criterion | Option B | Option C | Advantage | Material? |
|---|---|---|---|---|
| CapabilityCoverage | Full — the capability owns readiness end to end | Full — identical accepted capability set | NEUTRAL | not material |
| AuthorityClarity | Clear, but the readiness capability holds more objects than it must | Clearer — an explicit object authority map is a deliverable, one master per object | C | MATERIAL |
| IntegrationCount | Same source set, plus a bi-directional transactional link to Q4 | Same source set, read-dominant, one verdict reference back | C | not material |
| CrossSystemDecisionCapability | Full | Full | NEUTRAL | not material |
| CustomLogic | Larger owned logic surface (composition, projection, some re-mastering) | Smallest owned logic surface consistent with the capability | C | MATERIAL |
| FailureDependencies | Readiness depends on the capability plus Q4 availability | Per-source degradation states; failure is localized | C | MATERIAL |
| SupportBurden | Two governed surfaces | Two governed surfaces plus federation adapters and mapping stewards | B | MATERIAL |
| TechnicalDebt | Moderate; grows if the capability keeps absorbing objects | Lower owned debt; debt shifts to mapping governance | C | MATERIAL |
| EnterpriseScalability | Onboarding a project with a different source estate needs capability rework | Onboarding is a mapping exercise against the authority map | C | MATERIAL |
| ChangeImpact | Second surface for supervisors | Verdict surfaced in the tool already used; marginally lower delta | C | not material |
Qualified yes — but not on capability.
On capability coverage and cross-system decision capability the two options are equivalent; C offers no capability advantage and must not be selected on that basis. C's justification is structural: a smaller owned logic surface, localized per-source failure, an explicit one-master-per-object map, and project onboarding as a mapping exercise rather than capability rework. Those are material lifecycle advantages. Against them, C carries a genuine and non-trivial penalty — federation adapters and named mapping stewards per source, which is a staffing dependency, not a build item. The judgement is that C's federation burden is justified because that burden purchases authority clarity that B achieves only by owning more, and owning more is precisely the debt this programme is trying not to accrue. If the mapping stewardship cannot be staffed, C's advantage disappears and Option B becomes the correct selection — which is why B is retained as a live fallback, not a courtesy.
P / Q — Preferred option and why each alternative was not selected
Same capability and control outcome as B with the smallest owned logic surface, the lowest owned technical debt, no vendor release dependency on mandatory control logic, localized failure, and project onboarding as a mapping exercise rather than capability rework.
Architecturally sound and functionally equivalent. Not selected only because it owns more capability than the object authority map requires, carrying higher owned logic, debt and lifecycle cost for no control benefit over C. It remains a live fallback if mapping stewardship cannot be staffed.
Fails non-compensable §18 conditions: uncontrolled authority, material duplicated masters, authority not enforceable beyond role/UI on the six-dimensional test, and evidence reconstruction compromised by mutable copies. Its genuine advantages — lowest change load, one field tool, existing licences — cannot offset a pass/fail failure.
No evidenced enterprise capability advantage exists in the accepted baseline. It reproduces Option A's authority pattern after a migration of systems that already work, without A's adoption advantage. Retained in the register only as a tested and rejected alternative.
S — Phase 4 decision assurance register
R — Required competent decision authority
- · Enterprise Architecture — object authority map and federation model
- · Digital / IT-IM — integration and identity ownership
- · ES&H — non-compensation and critical-control integrity
- · Construction / Commissioning — operating-model fit
- · Project Controls — schedule and completions source authority
- · Transformation / Change — adoption and stewardship staffing (P3-TRN-01)
- · Project Management — funding and mandate
HOLD POINT — no Technical Solution Definition, API design, database design, physical deployment architecture, pilot or live integration. Next hold point: Enterprise Option Selection → Technical Solution Definition Authorization.