The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface

Agree the decisions your reporting architecture must support before choosing a tool. Trace the source events, transformations, definitions, access controls and reconciled totals. A decision-maker should be able to follow a reported figure back to its evidence and understand its limits.

1. The Market Connection Context

Customers and operating teams create the events from which management intelligence is built: an enquiry, order, fulfilment, contact, complaint, renewal, payment or service outcome. Every capture rule, join, transformation, semantic choice and access control can preserve or distort what leadership believes about those events. A polished interface can therefore amplify a weak architecture rather than repair it.

This playbook designs a bounded path:

Decision demand → business event → authoritative source → controlled movement
→ tested transformation → governed semantic contract → authorised interface
→ reconciliation → named human decision → monitored operation

By [decision date], the CIO will classify the proposed architecture ACCEPT WITHIN LIMIT, VALIDATE, CHANGE, DEFER, RETIRE or STOP. Acceptance applies to named decisions, sources, transformations, semantic versions, access boundaries and interface consumers. It is not universal certification of the enterprise data estate or permission to implement every component.

The Data Strategy and Investment Portfolio: A Leadership Playbook from Decisions to Architecture owns strategy and investment sequencing. The Metric Contract and Semantic Model Standard: One Definition, Known Limits and Accountable Ownership owns metric meaning and semantic contracts. The Executive Reporting and Review-Cadence Standard: Turning Dashboards into Decision Systems owns executive interface, narrative and review cadence. The Data Governance, Access and Privacy Operating Standard: Making Control Usable owns enterprise governance, access and privacy operation. The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface connects those decisions into a source-to-interface architecture, tests the chain and produces a bounded implementation decision without making a technology brand the starting point.

Working files

• Architecture Charter and Decision Demand Register
• Source, Transformation and Semantic Map
• Security, Interface and Reconciliation Test Ledger
• Architecture Decision and Transition Register

The W3C PROV-O recommendation provides a formal vocabulary for entities, activities and agents used to express provenance. The W3C Data on the Web Best Practices addresses metadata, provenance, versions, quality and machine-readable access. The UK Government Data Quality Framework treats quality as fitness for purpose and assigns accountable roles. NIST SP 800-207 Zero Trust Architecture supports explicit, resource-centred access decisions rather than assumed trust by network location. The W3C WCAG 2.2 recommendation supplies the accessibility criteria for decision interfaces. These are VERIFIED primary standards or official guidance. Their application here is INFERRED; the Abrasim sequence and controls are PROPOSED, and local architecture fitness REQUIRES VALIDATION.

2. The Leadership vs. Delegation Boundary

The reader recognises that credible delivery spans business decisions, data engineering, semantic modelling, security, report design, testing and adoption.

An internal team can run the method when it has cross-system access, qualified engineering and control owners, business-definition authority, independent challenge and power to stop unsafe movement or release. External support is justified where suppliers obscure logic, access crosses entities, legacy knowledge is missing or investment options are commercially conflicted.

Stop when the design depends on prohibited data, fabricated lineage, shared privileged identities, invisible manual overrides, unversioned semantic changes, unreconciled totals or a predetermined product. A reference architecture is not evidence that an organisation can operate it. A successful pipeline run is not evidence that meaning survived. Technical funding remains separate from architecture acceptance.

When a narrower specialist or simpler intervention is sufficient

Use a data-engineering specialist for one governed pipeline defect, a semantic specialist for one metric binding or reconciliation issue, an accessibility specialist for one decision task, or a security/privacy specialist for a qualified control question. Use a simpler source or interface correction when the architecture boundary and decision are already accepted. Do not commission a full architecture engagement to avoid a bounded source-owner decision.

Questions for evaluating a provider

Ask how the provider will preserve source, metric, security and privacy authority; distinguish observed operability from semantic and permitted-use fitness; test failure and edge cases; document transformations and versions; leave reusable architecture and control artefacts; and return all material trade-offs, access exceptions, funding and risk decisions to the named internal authority. Reject designs that treat a successful pipeline or product preference as architecture acceptance.

3. The Step-by-Step Execution Standard

Step 01: Charter the architecture decision

Purpose and decision served Bound one source-to-interface architecture around named management decisions and consequences.

Accountable owner CIO.

Delegated lead and contributors Architecture Lead with CDO, CFO, decision owners, Security Owner and Independent Challenger.

Preconditions, inputs and access Accepted decision demand, current reporting context, investment boundary and authority to inspect systems.

Actions

1. Name the decisions, users, populations and periods.
2. State current failure and consequence.
3. Bound sources, interfaces and exclusions.
4. Record conflicts, constraints and stop conditions.

Evidence to retain Signed charter, decision references, current diagrams, constraints and conflict record.

Decision or scoring rule Proceed only when the architecture serves bounded decisions rather than a generic modernisation objective.

Output and template Charter row in the Architecture Charter and Decision Demand Register.

Acceptance gate ARCHITECTURE QUESTION ACCEPTED or RE-CHARTER.

Leadership checkpoint The sponsor confirms the business decision and excluded ambitions.

Human control point Only the accountable sponsor accepts the value and risk boundary.

Failure modes and safeguards Reject tool-led scope and lists of features without decision demand.

Change, stop or escalation condition Stop if authority or an important decision cannot be named.

Handoff to the next step Transfer accepted demand to authority and control mapping.

Step 02: Establish architecture authority and control ownership

Purpose and decision served Assign responsibility across source, movement, transformation, meaning, security, interface and operation.

Accountable owner CIO.

Delegated lead and contributors Architecture Lead with system owners, Data Steward, Security, Privacy and Interface Owner.

Preconditions, inputs and access Charter, delegations, supplier contracts, access policies and specialist mandates.

Actions

1. Assign an owner to every architecture layer.
2. distinguish approval, operation and challenge rights.
3. Record access and evidence permissions.
4. Define exception, dissent and stop routes.

Evidence to retain Authority matrix, access approvals, supplier responsibilities, conflicts and escalation map.

Decision or scoring rule No layer advances without one accountable owner and a qualified challenge route.

Output and template Authority rows in the Architecture Charter and Decision Demand Register.

Acceptance gate OWNERSHIP COMPLETE or HOLD.

Leadership checkpoint The CIO tests cross-boundary gaps and retained supplier obligations.

Human control point Specialist authority cannot be delegated to a diagram or vendor.

Failure modes and safeguards Prevent collective ownership and unowned transformations.

Change, stop or escalation condition Escalate unresolved responsibility or denied evidence access.

Handoff to the next step Give accepted ownership to event and source discovery.

Step 03: Map decision-critical events and sources

Purpose and decision served Trace each required signal to the event, record and authoritative source that created it.

Accountable owner CDO or Data Owner.

Delegated lead and contributors Data Architect with process owners, system owners, analysts and Data Steward.

Preconditions, inputs and access Decision demand, source inventories, schemas, event definitions and representative records.

Actions

1. Name the real-world event and business meaning.
2. Identify systems of entry and authoritative record.
3. Record grain, keys, timestamps, ownership and history.
4. Mark duplicates, manual capture and unknown origins.

Evidence to retain Event catalogue, schema evidence, sample lineage, source-owner confirmation and gaps.

Decision or scoring rule Trace to an authoritative origin or mark REQUIRES VALIDATION; do not infer authority from availability.

Output and template Source rows in the Source, Transformation and Semantic Map.

Acceptance gate SOURCES TRACEABLE or VALIDATE.

Leadership checkpoint The CDO accepts which sources may support which decisions.

Human control point Business owners confirm event meaning and known capture limitations.

Failure modes and safeguards Avoid treating extracts, caches or convenience tables as original evidence.

Change, stop or escalation condition Stop a signal path whose origin or permitted use cannot be established.

Handoff to the next step Pass authorised sources to movement design.

Step 04: Design controlled data movement

Purpose and decision served Move required records with explicit latency, completeness, identity and failure controls.

Accountable owner Engineering Owner.

Delegated lead and contributors Data Engineer with Source Owner, Security Architect, Platform Owner and Operations.

Preconditions, inputs and access Source map, permitted use, volume profile, availability needs and interface demand.

Actions

1. Choose bounded batch, event or request movement by decision need.
2. Preserve source identifiers and event times.
3. Define retries, duplicates, late records and rejection handling.
4. Instrument completeness, latency and failure evidence.

Evidence to retain Movement specification, threat inputs, failure routes, monitoring plan and test fixtures.

Decision or scoring rule Prefer the least complex movement that satisfies evidence latency and control needs.

Output and template Movement rows in the Source, Transformation and Semantic Map.

Acceptance gate MOVEMENT CONTROLLED or REDESIGN.

Leadership checkpoint The Architecture Lead confirms complexity and operating cost are justified.

Human control point Security and source owners approve movement across trust boundaries.

Failure modes and safeguards Control silent loss, replay, duplication, clock drift and unmonitored extracts.

Change, stop or escalation condition Escalate movement that exceeds permission, recovery or operating capability.

Handoff to the next step Transfer movement contracts to transformation design.

Step 05: Specify transformations and provenance

Purpose and decision served Make every material filter, join, derivation, override and aggregation reproducible.

Accountable owner Transformation Owner.

Delegated lead and contributors Analytics Engineer with Metric Steward, Data Engineer, Finance and Quality Lead.

Preconditions, inputs and access Source and movement contracts, transformation code, manual procedures and expected outputs.

Actions

1. List transformations in execution order.
2. Record inputs, outputs, logic, owner and version.
3. Expose manual adjustments and exception paths.
4. Bind tests to material invariants and totals.

Evidence to retain Transformation specification, code reference, provenance map, test evidence and exception log.

Decision or scoring rule Another qualified person must reproduce material outputs from controlled inputs.

Output and template Transformation rows in the Source, Transformation and Semantic Map.

Acceptance gate TRANSFORMATIONS REPRODUCIBLE or VALIDATE.

Leadership checkpoint The Data Owner accepts visible gaps and manual dependencies.

Human control point Human approval is required for meaning-changing logic and overrides.

Failure modes and safeguards Prevent opaque scripts, undocumented spreadsheets and destructive corrections.

Change, stop or escalation condition Stop where a material total cannot be reproduced or explained.

Handoff to the next step Pass reproducible outputs to semantic binding.

Step 06: Bind the semantic layer

Purpose and decision served Ensure transformed outputs preserve approved business definitions, relationships and limits.

Accountable owner Metric Definition Owner.

Delegated lead and contributors Metric Steward with Semantic Modeler, Finance, decision owners and Analytics.

Preconditions, inputs and access The Metric Contract and Semantic Model Standard: One Definition, Known Limits and Accountable Ownership contracts, transformation outputs, dimensions, relationships and consumer needs.

Actions

1. Link every material measure to its approved contract version.
2. Define dimensions, grain, joins and allowed aggregations.
3. Encode exclusions and comparability limits.
4. Record breaking-change and consumer-impact rules.

Evidence to retain Semantic map, contract links, edge-case tests, version record and consumer inventory.

Decision or scoring rule Return disputed meaning to The Metric Contract and Semantic Model Standard: One Definition, Known Limits and Accountable Ownership; architecture cannot resolve semantics by implementation convention.

Output and template Semantic rows in the Source, Transformation and Semantic Map.

Acceptance gate SEMANTICS BOUND or RETURN TO METRIC CONTRACT AND SEMANTIC MODEL STANDARD.

Leadership checkpoint The CFO accepts meaning, exclusions and historical-comparison effects.

Human control point Code deployment cannot authorise a semantic change.

Failure modes and safeguards Control ambiguous joins, double counting and labels reused across incompatible grains.

Change, stop or escalation condition Hold interface work when a material semantic contract is missing.

Handoff to the next step Give the governed semantic surface to security design.

Step 07: Design security, privacy and permitted use

Purpose and decision served Protect each resource according to identity, purpose, sensitivity and operating risk.

Accountable owner Security Owner.

Delegated lead and contributors Security Architect with Privacy Owner, Data Owner, Identity Team and Operations.

Preconditions, inputs and access Classifications, user roles, permitted purposes, retention needs, threat analysis and legal advice where required.

Actions

1. Map resource, identity, role and permitted action.
2. Apply least privilege and separation of duties.
3. Define secrets, encryption, monitoring and exception controls.
4. Test revocation, export, service identities and incident routes.

Evidence to retain Access matrix, threat record, privacy decision, security tests, exceptions and response plan.

Decision or scoring rule Access is explicitly granted for a purpose and reviewed; network location alone is insufficient.

Output and template Security rows in the Security, Interface and Reconciliation Test Ledger.

Acceptance gate CONTROLLED WITHIN LIMIT or HOLD.

Leadership checkpoint Qualified authorities accept residual risk and exceptions.

Human control point Only authorised specialists approve sensitive use or exceptional access.

Failure modes and safeguards Prevent shared privileged accounts, uncontrolled exports and permanent emergency grants.

Change, stop or escalation condition Stop any path without lawful, secure and purpose-bounded use.

Handoff to the next step Transfer authorised semantic views to interface integration.

Step 08: Connect the decision interface

Purpose and decision served Expose only the governed evidence and context required by the accepted decision design.

Accountable owner Reporting Product Owner.

Delegated lead and contributors BI Engineer with Report Designer, Metric Steward, Security Owner and Accessibility Specialist.

Preconditions, inputs and access The Executive Reporting and Review-Cadence Standard: Turning Dashboards into Decision Systems page specification, authorised semantic views, identity controls and refresh contracts.

Actions

1. Bind interface elements to semantic objects and versions.
2. Surface freshness, limitations and applicable filters.
3. preserve accessible reading and interaction order.
4. Define export, cache, refresh and failure behaviour.

Evidence to retain Binding map, interface tests, accessibility evidence, refresh status and failure-state screenshots.

Decision or scoring rule The interface may simplify presentation but may not silently change meaning or security.

Output and template Interface rows in the Security, Interface and Reconciliation Test Ledger.

Acceptance gate INTERFACE BOUND or REMEDIATE.

Leadership checkpoint Decision owners confirm the evidence supports their The Executive Reporting and Review-Cadence Standard: Turning Dashboards into Decision Systems review task.

Human control point Representative users and accessibility specialists inspect consequential tasks.

Failure modes and safeguards Control hidden defaults, stale caches, insecure exports and inaccessible interaction.

Change, stop or escalation condition Return interface and cadence changes to The Executive Reporting and Review-Cadence Standard: Turning Dashboards into Decision Systems.

Handoff to the next step Give the integrated chain to reconciliation testing.

Step 09: Reconcile source to interface

Purpose and decision served Prove that representative and edge-case records survive the complete chain within stated tolerances.

Accountable owner Quality Owner.

Delegated lead and contributors Reconciliation Lead with source, engineering, semantic, Finance and interface owners.

Preconditions, inputs and access Integrated environment, controlled test data, authoritative totals, edge cases and tolerance rules.

Actions

1. Trace selected records from source event to displayed result.
2. Reconcile counts, values, exclusions and periods.
3. Test late, duplicate, corrected and missing records.
4. Classify every variance by cause and decision impact.

Evidence to retain Trace records, reconciliations, variance ledger, defect evidence and owner acceptance.

Decision or scoring rule Material variance must be explained and accepted; averages cannot conceal mandatory failure.

Output and template Reconciliation rows in the Security, Interface and Reconciliation Test Ledger.

Acceptance gate CHAIN RECONCILED, VALIDATE or FAIL.

Leadership checkpoint The CFO and CIO accept financial and operational reconciliation boundaries.

Human control point Human owners classify whether a variance changes the decision.

Failure modes and safeguards Avoid happy-path-only testing and self-reconciliation to the same derived source.

Change, stop or escalation condition Hold release for unexplained material variance.

Handoff to the next step Transfer reconciled evidence to resilience and operating tests.

Step 10: Test resilience and operational ownership

Purpose and decision served Establish how the architecture detects, contains, recovers and communicates failure.

Accountable owner Operations Owner.

Delegated lead and contributors Reliability Lead with Engineering, Security, Source Owners and Reporting Support.

Preconditions, inputs and access Service dependencies, recovery requirements, observability, support model and safe test environment.

Actions

1. Test source delay, transformation failure and access revocation.
2. Verify alerts, ownership, recovery and data correction.
3. rehearse stale-interface and partial-failure communication.
4. Record capacity, supplier and manual-recovery constraints.

Evidence to retain Test plans, incident timeline, recovery evidence, status communication and residual risks.

Decision or scoring rule Operate only when material failure becomes visible before leaders rely on unsafe evidence.

Output and template Resilience rows in the Security, Interface and Reconciliation Test Ledger.

Acceptance gate OPERABLE WITHIN LIMIT or REMEDIATE.

Leadership checkpoint The CIO accepts recovery, capacity and supplier risk boundaries.

Human control point Operations owns incident disposition and return-to-service acceptance.

Failure modes and safeguards Prevent silent stale reporting, alert floods and recovery that rewrites evidence.

Change, stop or escalation condition Stop if unsafe evidence cannot be withdrawn or clearly marked.

Handoff to the next step Provide complete architecture evidence to option decision.

Step 11: Decide the architecture and transition gate

Purpose and decision served Choose a bounded architecture disposition and fund only evidence-backed transition gates.

Accountable owner CIO with investment authority.

Delegated lead and contributors Architecture Lead prepares; CFO, CDO, Security, Procurement and Independent Challenger advise.

Preconditions, inputs and access Architecture evidence pack, options, dependencies, risks, operating implications and dissent.

Actions

1. Compare options against non-compensating controls.
2. Review dependencies and migration consequences.
3. Choose one permitted disposition.
4. Record funding gate, owner, evidence condition and stop route separately.

Evidence to retain Decision record, option comparison, dissent, residual risk, resource decision and conditions.

Decision or scoring rule Use ACCEPT WITHIN LIMIT, VALIDATE, CHANGE, DEFER, RETIRE or STOP; one material failure can hold the option.

Output and template Decision row in the Architecture Decision and Transition Register.

Acceptance gate ARCHITECTURE DISPOSITION RECORDED.

Leadership checkpoint Leadership states what is accepted, excluded, funded and still uncertain.

Human control point Architecture acceptance, risk acceptance and funding remain distinct human decisions.

Failure modes and safeguards Reject weighted scores that hide security, meaning or operability failure.

Change, stop or escalation condition Stop if a product choice precedes evidence or conflicts are hidden.

Handoff to the next step Transfer accepted gates to controlled transition and review.

Step 12: Transition, monitor and re-charter

Purpose and decision served Move in bounded increments, preserve continuity and reopen the decision when material conditions change.

Accountable owner CIO.

Delegated lead and contributors Transition Lead with all layer owners, Change Lead, Support and Independent Challenger.

Preconditions, inputs and access Signed disposition, transition sequence, rollback plan, monitoring contracts and consumer communication.

Actions

1. Release only accepted increments and consumers.
2. Parallel-reconcile where decision risk requires it.
3. monitor lineage, freshness, access, semantics and interface incidents.
4. Retire replaced paths and review architecture fitness.

Evidence to retain Release record, parallel reconciliation, rollback evidence, monitoring results, retirement proof and review decision.

Decision or scoring rule Continue only while evidence, ownership and controls remain within the accepted boundary.

Output and template Transition and review rows in the Architecture Decision and Transition Register.

Acceptance gate CONTINUE, VALIDATE, CHANGE, ROLL BACK, RETIRE or STOP.

Leadership checkpoint The CIO accepts each material expansion and retirement.

Human control point No automated deployment expands permitted use, meaning or decision scope.

Failure modes and safeguards Prevent permanent parallel systems, undocumented bypasses and incomplete retirement.

Change, stop or escalation condition Return to Step 01 when decisions, sources, semantics, control context or consumers materially change.

Handoff to the next step Archive controlled evidence and open a new charter when required.

4. The Evidence & Measurement Checklist

Preflight and authority

• Named management decisions bound the architecture. Evidence: accepted charter. Owner: CIO.
• Each architecture layer has one accountable owner. Evidence: authority matrix. Owner: Architecture Lead.
• Specialist approval and challenge rights are preserved. Evidence: delegation record. Owner: Governance Lead.
• Supplier responsibilities and evidence access are explicit. Evidence: contract responsibility map. Owner: Procurement.
• Conflicts, exclusions and stop routes are recorded. Evidence: boundary register. Owner: Executive Sponsor.

Evidence access and quality

• Decision-critical events trace to authoritative sources. Evidence: source-event map. Owner: Data Owner.
• Source grain, keys, timestamps and history are documented. Evidence: source contract. Owner: Data Steward.
• Movement records completeness, latency and failure. Evidence: movement test. Owner: Engineering Owner.
• Material transformations are reproducible. Evidence: provenance and test pack. Owner: Transformation Owner.
• Unknown origin or quality is visibly classified. Evidence: validation-gap register. Owner: Quality Owner.

Method execution

• The least-complex fit architecture was considered. Evidence: option rationale. Owner: Architecture Lead.
• Every material metric links to a version of the Metric Contract and Semantic Model Standard. Evidence: semantic binding map. Owner: Metric Steward.
• Interface elements bind to authorised semantic objects. Evidence: interface map. Owner: BI Engineer.
• Edge cases reconcile from source to interface. Evidence: reconciliation ledger. Owner: Reconciliation Lead.
• Resilience tests cover partial and stale states. Evidence: resilience pack. Owner: Operations Owner.

Governance, privacy, security and risk

• Access is resource, identity and purpose specific. Evidence: access matrix. Owner: Security Owner.
• Sensitive movement and export have approved controls. Evidence: security test. Owner: Privacy Owner.
• Privileged and service identities are separately controlled. Evidence: identity review. Owner: Identity Owner.
• Exceptions expire and retain human approval. Evidence: exception register. Owner: Risk Owner.
• Incident, revocation and stop procedures are tested. Evidence: response rehearsal. Owner: Security Owner.

Deliverables and acceptance

• All four working files are complete and consistent. Evidence: controlled architecture pack. Owner: Architecture Lead.
• Current and target chains show owners and evidence. Evidence: architecture views. Owner: CIO.
• Material limitations sit near the accepted design. Evidence: limitation register. Owner: Independent Challenger.
• The architecture disposition is signed and bounded. Evidence: executive decision. Owner: CIO.
• Funding conditions remain separate from evidence status. Evidence: investment record. Owner: CFO.

Measurement

• Source-to-interface traceability has a defined denominator. Evidence: traceability contract. Owner: Quality Owner.
• Reconciliation measures preserve material segments. Evidence: reconciliation contract. Owner: Finance Lead.
• Freshness and failure detection use decision-relevant limits. Evidence: operating contract. Owner: Operations Owner.
• Access exceptions have expiry and review. Evidence: security measure. Owner: Security Owner.
• Outcome attribution remains bounded. Evidence: learning statement. Owner: Independent Challenger.

Decision and handover

• Every accepted increment names an owner and gate. Evidence: transition register. Owner: Transition Lead.
• Rollback and evidence-correction routes are ready. Evidence: release plan. Owner: Engineering Owner.
• Consumers receive version and limitation notices. Evidence: communication record. Owner: Reporting Product Owner.
• Support accepts monitoring and incident ownership. Evidence: operational handover. Owner: Operations Owner.
• Replaced paths have retirement evidence. Evidence: retirement record. Owner: Data Owner.

Review, change and stop controls

• Material semantic change returns to The Metric Contract and Semantic Model Standard: One Definition, Known Limits and Accountable Ownership. Evidence: change-control test. Owner: Metric Steward.
• Interface or cadence change returns to The Executive Reporting and Review-Cadence Standard: Turning Dashboards into Decision Systems. Evidence: consumer-impact record. Owner: Reporting Product Owner.
• Governance and privacy changes return to The Data Governance, Access and Privacy Operating Standard: Making Control Usable. Evidence: control-impact record. Owner: Governance Lead.
• Architecture review has an owner and expiry. Evidence: review register. Owner: CIO.
• Invalid evidence or unsafe control can stop operation. Evidence: stop-test record. Owner: Executive Sponsor.

Measurement contracts

Measure A: Decision-path traceability

Measure B: Source-to-interface reconciliation

Measure C: Decision-relevant freshness

Measure D: Access-control exception exposure

Measure E: Architecture defect learning

Evidence classifications used in this guide

• VERIFIED: directly supported by an inspected controlled record or cited primary source.
• INFERRED: a bounded interpretation whose assumptions and alternatives remain visible.
• PROPOSED: an architecture option, control or sequence awaiting authorised decision.
• REQUIRES VALIDATION: an important claim or link that cannot yet be relied upon.

Source notes

1. W3C PROV-O: normative provenance recommendation used for entity, activity and agent traceability concepts.
2. W3C Data on the Web Best Practices: W3C recommendation used for metadata, provenance, quality, version and access principles.
3. UK Government Data Quality Framework: official framework used for fitness-for-purpose and accountable role principles.
4. NIST SP 800-207 Zero Trust Architecture: official security architecture guidance used for explicit resource and identity access controls.
5. W3C WCAG 2.2: normative accessibility recommendation used for decision-interface acceptance.