Andalusia Group · Business Intelligence (BI) Team · Enterprise Reporting Programme
Canonical governance, diagnostic reporting, metadata, Power BI design, and decision-intelligence operating guidance. v3.9 makes Input → Process → Output → Outcome the primary diagnostic structure and requires D1 Descriptive + D2 Diagnostic capability for performance reporting.
Current governed scope: Refer to Enterprise Reporting Hierarchy v3.8 for current report count, business function count, source system count, status, and coverage figures. This HTML is a fixed standards reference — it does not hold live operational counts.
Four distinct artifacts govern the enterprise reporting programme. Each has a defined authority, scope, and ownership. None replaces the others.
Ownership principle: The Enterprise Reporting programme and reporting lifecycle are owned and governed by the BI Team. This includes the governance model, operational registers, KPI governance, KPI Bindings, Diagnostic Relationship Maps, report and dashboard assets, Power BI standards, reusable components, certification, deployment, monitoring, adoption telemetry, change control, and reporting-learning orchestration. Business roles participate as domain validators, Decision Owners, Action Owners, and target / value sign-off authorities; these remain business-accountability roles within the decision cycle, while the reporting architecture and reporting products are governed by the BI Team.
Owner: BI Team.
Authority: Operational system of record.
Contains: Live governance registers — process register, process output register, KPI catalog, KPI binding records, report register, decision product contracts, role assignments, validation status, operational state, adoption telemetry, open gaps, and all live records.
Owner: BI Team.
Authority: Canonical standards and interpretation reference.
Contains: Governing model, schemas, layer definitions, classification rules, metadata relationships, Power BI design standards, lifecycle rules, implementation sequence, LLM operating rules, and anti-patterns.
Owner: BI Team; business functions validate domain meaning and decisions.
Authority: Domain-level execution design.
Contains: Domain report inventory, process-to-output mapping, KPI certification workings, report disposition decisions, role-action-SLA mapping, dashboard design, build specification, and prototype documentation for one business function.
Owner: BI Team.
Authority: Technical implementation standards.
Contains: Theme JSON (andalusia-report-theme.json), PBIX templates (all six zones), reusable component library, KPI card templates, Action panel template, AI insight container, Arabic/RTL template.
Non-negotiable rule: Enterprise Reporting Hierarchy v3.8 is the single operational system of record for all live governance registers. This HTML explains the governing model and schemas. Domain Function Packs handle domain execution. Do not create a second register that overlaps with or may drift from v3.8.
The governance backbone remains three-layered. v3.9 changes the analytical classification model: Business Measurement (Input → Process → Output → Outcome) is now also the primary diagnostic navigation structure for reports and dashboards. DDPP describes analytical maturity. CDE is no longer a mandatory user-facing hierarchy.
Defines the governed business and measurement context required for diagnostic reporting.
Requires descriptive + diagnostic completeness before a performance Decision Product is certified.
Closes the loop from diagnostic signal to decision, action, evidence, value, and learning.
Active classification views: Business Structure defines the business home; Business Measurement defines the four stages Input / Process / Output / Outcome and the diagnostic drill path; DDPP defines analytical capability D1–D4. Existing CDE fields may be retained temporarily for backward compatibility only and must not drive report design, navigation, colour, or certification.
Every Decision Product traces a complete chain from strategic intent to measurable learning. Performance reporting must expose both the forward value-production chain and the backward diagnostic chain.
Diagnostic direction: the business produces value forward as Input → Process → Output → Outcome. When a variance occurs, the report investigates backward as Outcome Variance → Output Attribution → Process Diagnostics → Input / Constraint Diagnostics → Management Action.
Every production performance report is governed as a Decision Product. v3.9 adds a mandatory diagnostic contract: performance reporting must not stop at description or categorical breakdown.
Dashboard vs Report vs Decision Product: Dashboards may monitor and navigate, but when they surface performance they must expose a diagnostic route. Decision Products own the full chain: descriptive signal, stage-based diagnosis, decision, action, evidence, value and learning. A Domain Hub remains a federated navigation surface and does not create new KPI logic.
| Field | Status | Description |
|---|---|---|
| Decision Product ID | Required | Unique code linked to the Reports Register. |
| Source Report ID | Required | Canonical report / dashboard governed by this contract. |
| Decision Question | Required | One primary management question. |
| Primary Outcome / Decision KPI | Required | Primary performance result whose variance initiates diagnosis. |
| Primary KPI Bindings | Required | Bound certified KPI signals used by the Decision Product. |
| Diagnostic Stage Coverage | Required | Coverage of Outcome, Output, Process, Input. Performance reports must cover all relevant stages or explicitly document a source gap. |
| Minimum Analytical Capability | Required | D1 Descriptive + D2 Diagnostic for performance reports. D3/D4 are optional extensions. |
| Diagnostic Relationship Map | Required | Governed links used to trace Outcome → Output → Process → Input. |
| Decision Owner | Required | Named role accountable for the management decision. |
| Action Owner | Required | Named role responsible for execution. |
| Consumer Roles | Required | Roles monitoring and investigating the Decision Product. |
| Trigger Condition | Required | Variance / event activating investigation and decision. |
| Expected Action | Required | Corrective or escalation action when the trigger is confirmed. |
| Evidence Required | Required | Evidence needed to confirm execution and result. |
| Value at Stake | Conditional | Estimated revenue, cost, efficiency, clinical or compliance value. |
| Native / Reporting Currency | Conditional | ISO currency codes where financial value applies. |
| Review Forum / Cadence | Required | Operational governance rhythm. |
| Action Tracker | Required | Linked action tracking mechanism. |
| Escalation Path | Required | Role hierarchy and trigger for unresolved decisions. |
| Learning Loop | Required | Mechanism to validate diagnostic assumptions and update targets. |
| Certification Status | Required | Draft / In Review / Certified / Deprecated. |
| Operational State | Required | D0–D6. |
| Data Domain / Value Type | Required | Governed data and benefit context. |
| Next-Cycle Target Owner | Required | Role responsible for revised target / threshold. |
Every domain executes the following sequence. Do not begin with page count, report layer, or visuals. Begin with business structure, measurement stages, certified KPIs, the decision question, and the diagnostic chain.
Inventory existing reports, dashboards and manual outputs with source, owner, cadence and usage.
Map reports to Org Outcome, Org Output, Departmental Output, Process and Process Output.
Classify relevant measures as Input, Process, Output or Outcome. Confirm the primary Outcome / performance result.
Confirm source system, entity, grain, refresh SLA and readiness for each stage.
Certify KPI definition, formula, target / baseline requirements, source and owner in the KPI Catalog.
Bind certified KPIs to Process Outputs, report components, measurement stages and decision context.
Define the governed backward path Outcome → Output → Process → Input, including attribution method, evidence status and known source gaps.
Reuse certified components before building new ones.
Keep · Merge · Retire · Reuse · Convert to Drill-through · Federated Consumer.
One decision question, primary Outcome, D1+D2 requirement, Decision Owner, Action Owner, trigger, evidence and value.
Define how the user moves from Outcome variance to Output attribution, Process diagnosis and Input / constraint diagnosis. A breakdown alone does not count as diagnostics.
Map decision authority, execution owner, SLA and escalation path.
Assign forum, cadence, chair and action-tracking mechanism.
Pass all mandatory diagnostic, governance, data, design and security gates.
Design navigation after Decision Products and diagnostic relationships are defined.
Validate D1 descriptive summary and D2 stage drill end-to-end with business users.
Document semantic model, measures, stage relationships, DAX, security, refresh, performance and action integration.
Deploy after business acceptance and BI Team production approval.
Track decisions, actions, evidence, realized value, failed diagnostic assumptions and next-cycle targets.
Diagnostic investigation follows the four business measurement stages in reverse. Escalation follows organizational authority. They are separate mechanisms.
Start with a material Outcome variance. Attribute it to the Outputs that contributed, diagnose the Processes explaining those Output gaps, then inspect the Inputs / constraints explaining the Process gap.
Diagnostics require evidence. A category breakdown is not a root-cause conclusion unless the relationship is governed and supported.
Escalation occurs when the action cannot be resolved at the current authority, the SLA is breached, or the value / risk threshold exceeds authority.
Escalation does not use diagnostic drill-through. It is logged in governance operations.
Two separate fields. Never combined into one status. Certification answers governance questions; Operational State answers execution questions.
Answers: "Is this governed and approved?"
Answers: "What is happening now?"
Rule: No Decision Product is used for production decisions until Certification Status = Certified. Operational State tracks what is happening during the process — it does not gate certification.
No performance Decision Product is certified unless D1 descriptive and D2 diagnostic requirements are demonstrably satisfied or a documented data-readiness exception is approved.
A Decision Product is not considered operational until it has a defined review forum and cadence. The forum closes the loop between the analytical signal and the governance action.
| Field | Status | Description |
|---|---|---|
| Forum ID | Required | Unique ID (e.g. FRM-INS-01) |
| Forum Name | Required | Name of the governance forum (e.g. Insurance Weekly Sprint) |
| Cadence | Required | Daily Huddle · Weekly Sprint · Monthly Steering · Quarterly Review |
| Chair | Required | Named role chairing the forum |
| Linked Decision Products | Required | List of Decision Product IDs reviewed at this forum |
| Decision Output | Required | What the forum produces: a resolution, escalation, or target revision |
| Action Tracker | Required | Where actions from this forum are logged and tracked |
| Escalation Mechanism | Required | When and how unresolved decisions escalate to the next governance level |
Value is not realized merely because a report was published. Value requires evidence, owner sign-off, and confirmation through the learning loop.
| Measure | Definition |
|---|---|
| Decisions Triggered | Count of times the trigger condition fired for this Decision Product in the period |
| Actions Opened | Count of actions opened in the Action Tracker as a result of this Decision Product |
| Actions Closed | Count of actions with confirmed evidence recorded |
| Closure Rate | Actions Closed / Actions Opened × 100 (%) |
| Time to Close | Average days from action opened to evidence confirmed |
| Value Hypothesis | The estimated value at stake stated in the Decision Product Contract |
| Value Realized | Confirmed value from closed actions, signed off by the Decision Owner. Currency per Native Currency Code. |
| Evidence Source | System or register where the evidence was recorded |
| Owner Sign-off | Formal confirmation by the Decision Owner that value was realized |
| Usage / Adoption | Active users, view frequency, and engagement by Consumer Role |
| Next-Cycle Target | Revised KPI target for the next review cycle, set by the Next-Cycle Target Owner |
The BI Team owns the governed reporting logic, metadata, implementation, certification, and lifecycle for every domain. Business functions validate business meaning and participate through Decision Owner / Action Owner accountability roles. No business function or parallel technical team rebuilds certified KPI logic.
Federation rules: Domain Hubs consume certified components and Decision Products — they are navigation surfaces, not sources of new KPI logic. Cross-domain reports must declare one primary Process Output ID (accountability anchor) and may declare secondary output bindings through a Report-Output Map. Primary accountability determines the Decision Owner; secondary mappings support federation and cross-domain consumption.
| Field | Status | Description |
|---|---|---|
| Primary Process Output ID | Required | The single output node this report primarily measures and is accountable to |
| Secondary Output Bindings | Optional | Additional Process Output IDs this report serves, managed through the Report-Output Map |
| Report-Output Map | Conditional | Required for cross-domain reports. Maps secondary output bindings and identifies the consuming functions. |
| Federation Type | Conditional | Provider (BI-governed logic) · Consumer (uses certified output) · Joint (shared business accountability with named primary) |
| Joint KPI Resolution | Conditional | Required when two functions share a KPI. Records the agreed definition, owner, and arbitration rule. |
Every Decision Product and KPI has a managed lifecycle. Lifecycle stage is separate from Certification Status and Operational State.
| Field | Status | Description |
|---|---|---|
| Version | Required | Version number of the Decision Product or KPI definition |
| Next Review Date | Required | Scheduled date for the next governance review |
| Revision Trigger | Conditional | Event that triggered this revision (threshold change, process change, ownership change) |
| Change Approval | Required | Named approver and date of change approval |
| Impact Assessment | Conditional | Required for changes affecting shared KPIs or cross-domain Decision Products |
| Retirement Criteria | Conditional | Defined conditions under which this Decision Product may be deprecated |
Coverage measures are maintained in v3.8. v3.9 replaces CDE coverage with diagnostic-stage and D2 completeness measures.
| Measure | Definition | Owner |
|---|---|---|
| Reports Inventoried | Total reports identified in current-state inventory | BI Team |
| Decision Products Defined | Reports with completed Decision Product Contract | BI Team |
| KPIs Certified | Certified KPI Catalog records | BI Team |
| Bindings Completed | Active KPI Binding records linked to components | BI Team |
| Diagnostic Relationships Mapped | % of performance Decision Products with governed Outcome→Output→Process→Input relationships | BI Team |
| Four-Stage Coverage | % of performance reports covering all relevant Input, Process, Output and Outcome stages or documenting approved source gaps | BI Team |
| D1 Coverage | % with Actual, Target/Baseline, Variance and Trend | BI Team |
| D2 Diagnostic Coverage | % passing Output attribution, Process diagnostics and Input/constraint diagnostics | BI Team |
| Reports Certified | Reports passing all validation gates | BI Team |
| Reports Live | Live reports in Reports Register | BI Team |
| Owners Assigned | % with Decision Owner and Action Owner | BI Team |
| Actions Configured | % with action routing and tracker configured | Function Head |
| Value Measured | % with closed action and confirmed value | BI Team |
| Open Diagnostic Gaps | Count of missing stage relationships / source blockers by priority and owner | BI Team |
Section 01
Every Power BI performance experience is governed as part of a Decision Product and must be useful for both monitoring and diagnosis. The standard is diagnostic-first: the report should expose what changed and why without forcing the user to leave the analytical journey.
Start from Outcome, Output, Process and Input context. Do not start from available measures or desired chart types.
Performance reports require D1 Descriptive + D2 Diagnostic. D1-only output is not decision-ready unless explicitly classified as reference / informational.
Reuse certified KPI Definitions, Bindings, diagnostic relationships and components. Do not create local copies of logic.
Core diagnostic contract: Outcome Variance → Contributing Outputs → Process Performance → Input / Constraint Drivers → Management Action. This is the default analytical path for new and in-progress performance reports.
Operating ownership: The BI Team owns the reporting architecture, semantic/report implementation, certification, production rollout, operational monitoring, and lifecycle governance end-to-end. Business participants validate definitions and execute the management decisions and actions governed through the Decision Product.
Section 02
Every KPI component is assigned one Business Measurement / Diagnostic Stage: Input, Process, Output, or Outcome. A Decision Product may contain all four. The stage describes the KPI's role in the business value flow and determines the preferred diagnostic drill direction.
Capacity, manpower, demand, budget, stock, policy, contract, system availability, readiness or other conditions entering a process.
Efficiency, quality, compliance, TAT, throughput, conversion, utilisation and process execution measures.
What the process directly produced: approved requests, submitted claims, bookings, completed visits, dispensed prescriptions, recovered claims.
Revenue, collection, quality, patient outcome, cost avoidance, satisfaction or strategic performance result.
Do not map stages mechanically. Diagnostic navigation is evidence-based. An Outcome can be explained by multiple Outputs across processes; a Process gap can be explained by several Input / constraint dimensions. Where the relationship is not supported, show a diagnostic gap rather than inventing a cause.
Section 03
The enterprise palette is now stage-oriented. Stage colours are navigation cues for Input, Process, Output and Outcome. Action and AI retain their existing reserved treatments. Colour is never the only classification signal.
Legacy CDE colours are retired as a visible classification contract. Existing reports may retain them temporarily until controlled alignment. New / redesigned reports use stage colours only.
Section 04
Used once per report for the report name. Paired with the Decision Question / Diagnostic Coverage header context.
Visual groupings within a report page (e.g. "Revenue Summary", "Claims Detail").
Large metric display. Always accompanied by a unit label and trend indicator.
Table rows, axis labels, tooltips. Minimum 10 pt for printed/paginated reports.
Section 05
The standard layout is structured around the management question and the four diagnostic stages. Users should be able to move from the Outcome signal to the underlying business constraint without interpreting a second analytical hierarchy.
Decision question, owner, primary Outcome, source, refresh, certification and diagnostic coverage.
Actual, Target / Baseline, Variance, Trend and RAG. No bare KPI without context.
Rank the Outputs materially contributing to the Outcome variance. Contribution / attribution should be explicit.
Process KPIs that explain the selected Output gap: TAT, throughput, compliance, conversion, utilisation, backlog, quality.
Demand, manpower, capacity, stock, policy, contract, system, training, readiness or other upstream constraints.
Decision and Action routing. AI content may appear only in the reserved AI container and must remain evidence-aware.
Section 06
Required for performance KPI cards: Stage badge · Value · Unit · Period · Target/Baseline · Variance · Trend · diagnostic drill state.
Use variance bars, waterfall, contribution bars, decomposition views or ranked tables to show which Outputs / categories materially explain a gap.
Use trend + target bands, scatter where analytically appropriate, heatmaps for capacity/demand, and matrices for process-step breakdowns.
Use capacity-demand views, manpower gap, stock/readiness, payer/contract constraints, system availability, or reason distributions with evidence context.
A chart showing KPI by specialty, branch, payer, doctor or category is descriptive segmentation unless it quantifies material contribution and connects to an explanatory stage.
Section 07
Reports that surface AI output from the Copilot Agent Architecture (forecasts, anomaly alerts, recommendations, or a Copilot entry point) must apply the DotCare AI design-token set defined in §8 of the AI Interface Standard. The same tokens that govern DotCare modules govern the BI layer — one AI feel, everywhere.
| Token | Power BI implementation |
|---|---|
| ai.accent | Violet-blue (#4F46E5→#7C3AED) on AI visuals only |
| ai.glyph | ✦ sparkle character in AI card header |
| ai.container | Custom visual container: gradient border, labelled header |
| ai.confidence | Colour-coded badge: green/amber/orange/grey |
| ai.badge.predicted | "AI" pill next to forecast values |
| ai.nudge | Ambient highlight row in tables where AI flagged an anomaly |
Section 08
The header must tell the user what decision is being supported, what Outcome is being monitored, whether data is fresh, and whether D2 diagnostic coverage is complete.
| Field | Format | Example |
|---|---|---|
| Report title | Plain-language, decision-oriented | Claims Rejection & Revenue Protection |
| Decision question | One sentence | Where is rejection increasing, why, and what requires action? |
| Primary Outcome / KPI | Certified KPI | Rejected Amount / Revenue Leakage |
| Diagnostic coverage | I / P / O / Oc | Oc ✓ · O ✓ · P ✓ · I partial |
| DDPP capability | D1 + D2 minimum for performance | D1 + D2 |
| Decision Owner | Role title | Revenue Cycle Director |
| Source system(s) | APP-ID | APP-01 DotCare |
| Refresh schedule | Frequency + timestamp | Daily · 06:00 AST |
| Certification / Operational State | Separate fields | Certified · D3 Needs Decision |
| Decision Product ID | DP-xxx | DP-INS-004 |
Section 09
Actionability remains a separate score from diagnostic capability. A report can be D2 Diagnostic but still fail to close the action loop. Both are required for a mature Decision Product.
Section 10
All reports that have an Arabic audience (primarily KSA sites: AKW, JDC, SNB, CHT) must have an Arabic language variant that:
Respect reduced-motion: AI containers in embedded Power BI should not use shimmer/skeleton animations when the OS prefers-reduced-motion setting is active. Use a static "Loading…" label instead. This is non-negotiable — clinical settings have many users who find motion distracting.
Section 11
Every performance report must pass technical, business and diagnostic checks before production certification.
Section 12
v3.9 replaces CDE layer tokens with diagnostic-stage tokens for new and redesigned reports. Legacy layer tokens may remain temporarily in existing reports during migration.
| Token | Value | Usage |
|---|---|---|
| stage.input | #2C5F8A | Input / constraint classification and accents |
| stage.input.bg | #EBF2F8 | Input component background |
| stage.process | #1A6B4A | Process diagnostic classification |
| stage.process.bg | #E8F4EE | Process component background |
| stage.output | #9A6415 | Output attribution classification |
| stage.output.bg | #FFF4D8 | Output component background |
| stage.outcome | #9D174D | Outcome / variance classification |
| stage.outcome.bg | #FDF2F8 | Outcome component background |
| decision.action | #5B3D8A | Decision / action utilities |
| ai.accent.primary | #4F46E5 | Runtime AI only |
| ai.accent.secondary | #7C3AED | Runtime AI only |
| status.live | #15803D | On-target / live |
| status.watch | #B45309 | Watch |
| status.behind | #DC2626 | Behind / alert |
| ink | #0D1117 | Primary text |
| surface | #F5F4F0 | Canvas |
The target is not a better descriptive dashboard. It is a governed reporting system that shows what changed, diagnoses why through the business flow, routes the management decision, and proves value after action.
Data availability → KPIs → charts → dashboard. Useful for monitoring but often weak for management diagnosis.
Business structure → Outcome variance → Output attribution → Process diagnostics → Input constraints → decision / action / value.
D1 + D2 from the start. Descriptive reporting is necessary but not sufficient for performance reports.
One visible structure: the business runs forward Input → Process → Output → Outcome. Diagnostics trace backward from the material Outcome variance through Outputs, Processes and Inputs. Users should not need a competing CDE navigation model.
v3.9 simplifies the analytical model. Business Measurement is now the primary diagnostic stage model. DDPP remains analytical maturity. CDE is deprecated for new user-facing design.
Diagnostic navigation: Outcome Variance → Output Attribution → Process Diagnostics → Input / Constraint Diagnostics.
Critical rule: KPI Definition is not linked directly to Process Output. KPI Binding / Context is the linking object. One KPI Definition may have multiple Bindings in different Process Outputs, stages and Decision Products.
| Level | Definition | Example | Governance field |
|---|---|---|---|
| Org Outcome | Highest-level strategic result. | Financial Sustainability | OUT-ID root |
| Org Output | Enterprise deliverable contributing to Org Outcome. | Optimized Revenue Cycle | OUT-ID + Parent |
| Departmental Output | Function-level deliverable. | Low Preventable Insurance Rejection | OUT-ID + Function Owner |
| Process | Operational activity producing an output. | Claim Preparation & Validation | PRC-ID |
| Process Output | Specific result delivered by a process. | Clean Validated Claim | OUT-ID |
| KPI Binding | Connects KPI Definition to Process Output, stage, component and decision context. | BND-INS-042-001 | BND-ID |
| Diagnostic Relationship | Connects a downstream bound KPI to an upstream explanatory bound KPI. | REL-INS-042-019 | REL-ID |
| Report Component | Visual surface using the bound KPI. | Rejection Variance card | CMP-ID |
The same four stages describe how the business produces value and how performance is diagnosed. Forward flow creates the result; backward flow investigates a material variance.
Resource, demand, capacity, stock, policy, contract, system, readiness or precondition entering the process.
Efficiency or quality of operational execution: TAT, conversion, throughput, compliance, utilisation, backlog.
What the process directly delivered.
Business, financial, operational or clinical result.
Diagnostic completeness is not the same as displaying all four stages. The report must connect them through governed relationships for the selected variance. If an Input is merely shown on the page without explaining the Process gap, it does not satisfy D2.
Cause / Driver / Effect was previously used as the primary report-layer and drill model. Under v3.9 it is retired from user-facing design and certification. It may remain temporarily in existing metadata to avoid breaking current assets while the four-stage diagnostic model is adopted.
Deprecated for new design: report-level Cause / Driver / Effect badges, CDE-driven colour, CDE page hierarchy, Effect→Driver→Cause mandatory drill, Primary CDE Layer as a certification requirement, and component CDE as a mandatory visible badge.
Do not rebuild immediately. Preserve current delivery and align in controlled review.
CDE fields may remain as legacy fields until v3.8 schema migration. They must be marked deprecated / compatibility-only.
Use Business Measurement stages and Diagnostic Relationship Map. Do not create new CDE-dependent navigation.
Historical interpretation: CDE values in older Function Packs or reports should be treated as legacy analytical annotations, not as the active report architecture.
| Level | Definition | v3.9 Requirement | AI Container? |
|---|---|---|---|
| D1 · Descriptive | What happened: actual, target/baseline, variance, trend, segmentation. | Mandatory foundation. | No. |
| D2 · Diagnostic | Why: Output attribution, Process diagnostics, Input/constraint diagnostics, ranked evidence. | Mandatory minimum with D1 for performance reports. | No. |
| D3 · Predictive | What may happen. | Optional extension after D1+D2 are sound. | Only if runtime model / AI-generated. |
| D4 · Prescriptive | What should be done: ranked actions / optimisation. | Optional extension; must not bypass governance decision rights. | Only if runtime model / AI-generated. |
D1-only performance reporting is not decision-ready. It may be published only as an explicitly informational / reference output or under an approved temporary diagnostic-data gap.
What the KPI is: name, definition, formula, grain, unit, source, target/baseline, RAG, default Business Measurement Stage and DDPP capability.
Where the KPI applies: Process Output, Report Component, stage override, DDPP override, Decision Owner context and optional KPI weight.
How a downstream Binding is analytically connected to an upstream Binding across Outcome → Output → Process → Input.
How child outputs contribute to parent output where an approved weighted roll-up exists.
Optional relative weighting of multiple KPIs measuring the same Output.
| Field | Status | Description |
|---|---|---|
| KPI ID / Name / Definition / Formula | Required | Certified metric identity. |
| Unit / Grain / Frequency | Required | Measurement context. |
| Business Measurement Stage (default) | Required | Input / Process / Output / Outcome. |
| DDPP Capability (default) | Required | D1 / D2 / D3 / D4 capability. |
| Data Source / APP-ID | Required | Certified source. |
| Target / Baseline | Conditional | Required for certified performance KPIs; descriptive counts may use approved exception. |
| RAG Thresholds | Conditional | Required where decision triggers depend on performance threshold. |
| Primary Owner Role | Required | Definition accuracy owner. |
| Catalog Status | Required | Draft / In Review / Certified / Deprecated. |
| Field | Status | Description |
|---|---|---|
| Binding ID / KPI ID | Required | Binding identity and certified KPI. |
| Process Output ID | Required | Business output context. |
| Report Component ID | Conditional | Component consuming the Binding. |
| Business Measurement Stage | Required | Input / Process / Output / Outcome for this context. |
| DDPP Level / Capability | Required | Analytical capability for this component. |
| Decision Owner Role (context) | Required | Decision owner in this context. |
| KPI Weight within Output Score | Optional | Only for approved composite output score. |
| Binding Status | Required | Active / Suspended / Deprecated. |
| Field | Status | Description |
|---|---|---|
| Relationship ID | Required | REL-xxx. |
| Downstream Binding ID | Required | The variance / result being explained. |
| Upstream Binding ID | Required | The explanatory Output, Process or Input Binding. |
| Downstream Stage / Upstream Stage | Required | Expected sequence: Outcome←Output←Process←Input. Same-stage relationships are allowed where justified. |
| Relationship Type | Required | Contribution · Attribution · Process Explanation · Input Constraint · Reference / Context. |
| Attribution Method | Conditional | Variance decomposition, share-of-gap, rule-based mapping, statistical attribution, validated causal model, or qualitative governed mapping. |
| Evidence / Validation Status | Required | Proposed · Business Validated · Data Validated · Model Validated · Deprecated. |
| Diagnostic Strength | Required | Contextual · Associative · Attributive · Causally Validated. Do not overstate. |
| Owner / Review Date | Required | Governance of the relationship itself. |
No false causality: the four-stage diagnostic path is a governance and investigation structure. A relationship is not a causal claim unless it has been separately validated as causal.
| Field | Status | Description |
|---|---|---|
| Decision Question | Required | One management question. |
| Decision Owner Role | Required | Specific role title. |
| Primary Outcome / Decision KPI | Required | Performance result under management. |
| Primary Process Output ID | Required | Accountability anchor. |
| Diagnostic Stage Coverage | Required | Input / Process / Output / Outcome coverage and gap indicator. |
| DDPP Capability | Required | D1+D2 minimum for performance reporting. |
| Escalation Role | Required | Named role + trigger. |
| Native Currency Code | Conditional | ISO 4217 where applicable. |
| Decision Product ID | Required | DP-xxx. |
New and redesigned KPI cards use stage + DDPP metadata. CDE badges are not required or displayed.
Required card elements:
| Governance Asset | Connection | Lives in |
|---|---|---|
| Enterprise Reporting Hierarchy v3.8 | Operational system of record for live governance data. | v3.8 |
| KPI Catalog | Certified definitions and default measurement stage. | Layer A |
| KPI Binding Table | Context-specific stage, DDPP and ownership. | Layer A |
| Diagnostic Relationship Map | Governs Outcome→Output→Process→Input investigation relationships and evidence status. | Layer A |
| Enterprise Output Tree | Business accountability and output relationships. | Layer A |
| Reports Register | Diagnostic coverage, DDPP, Outcome anchor and status. | Layer B |
| Decision Product Contract | D1+D2 requirement, owners, trigger, action, evidence and value. | Layer B |
| Decision Operating Rhythm | Forum and cadence. | Layer C |
| AI Model Governance | Runtime D3/D4 AI outputs and validated model evidence. | Layer C |
Continue delivery: do not stop or rebuild completed reports immediately. Apply v3.9 to new and in-progress work first; align existing reports through a controlled diagnostic review.
| Output | Description |
|---|---|
| Power BI theme JSON v3.9 | Input / Process / Output / Outcome + Action + AI tokens. |
| Diagnostic-first PBIX template | Zones A–F: Header, Outcome, Output, Process, Input/Constraint, Decision/Action. |
| Report header component | Decision Question, Outcome, diagnostic coverage, DDPP, owner, source, certification. |
| KPI card templates (I/P/O/Oc) | Stage, DDPP, target/baseline, variance, contribution/drill, Binding ID. |
| Diagnostic Relationship Map schema | Relationship ID, bindings, stage direction, type, attribution method, evidence strength and status. |
| D1+D2 conformance gate | Validator preventing performance reports from being labelled Diagnostic without required stage coverage. |
| Action panel template | Decision Owner, Action Owner, SLA, evidence, value and escalation. |
| AI insight container | Runtime AI only, with confidence/model/evidence disclosure. |
| Arabic / RTL template | Mirrored diagnostic layout. |
| Updated Definition of Done | Includes D1+D2 completeness and Diagnostic Relationship Map. |
| Domain Function Pack template | Includes four-stage mapping and diagnostic coverage step. |
| Generator policy / machine JSON | New blueprint contract aligned to v3.9. |
Both S11 and E14 must pass for a performance Decision Product.
Actual/Target/Variance/Trend plus Output attribution. Proves D1→D2 transition.
Ranks Output contributions and drills to Process KPIs.
Demand, manpower, throughput, conversion / compliance and Input constraints.
Complete Outcome→Output→Process→Input path + Action / evidence loop.
Only after D1+D2 is stable; runtime model outputs governed separately.
Any LLM or report generator reading this reference must follow these rules.
Parseable summary for LLMs, report generators and future automation.
{
"document": {
"title": "Andalusia Group — Enterprise Reporting Operating Reference v3.9",
"version": "1.3",
"date": "August 2026",
"owner": "Andalusia Group — BI Team",
"revision_from": "v1.2 — July 2026",
"design_direction": "Diagnostic-first"
},
"source_of_truth_rules": {
"v3_8_workbook": "Operational system of record for live governance registers",
"this_html": "Canonical standards and interpretation reference",
"function_packs": "Domain execution design",
"powerbi_assets": "Technical implementation assets"
},
"primary_analytical_structure": {
"forward_business_flow": [
"Input",
"Process",
"Output",
"Outcome"
],
"backward_diagnostic_flow": [
"Outcome Variance",
"Output Attribution",
"Process Diagnostics",
"Input / Constraint Diagnostics",
"Management Action"
],
"rule": "Business Measurement stages are the primary user-facing diagnostic structure."
},
"legacy_cde": {
"status": "Deprecated for new user-facing design",
"allowed_use": "Temporary backward compatibility metadata in existing registers/assets",
"must_not_drive": [
"report hierarchy",
"page names",
"colour",
"KPI badge",
"drill direction",
"certification"
]
},
"ddpp": {
"D1": "Descriptive — What happened",
"D2": "Diagnostic — Why; requires Outcome variance, Output attribution, Process diagnostics, Input/constraint diagnostics",
"D3": "Predictive — What may happen",
"D4": "Prescriptive — What should be done",
"performance_minimum": [
"D1",
"D2"
]
},
"business_structure": [
"Org Outcome",
"Org Output",
"Departmental Output",
"Process",
"Process Output",
"KPI Binding",
"Diagnostic Relationship",
"Report Component"
],
"governance_objects": {
"kpi_definition": "Defines KPI",
"kpi_binding": "Applies KPI in business/report context",
"diagnostic_relationship": "Links downstream and upstream KPI Bindings across stages with evidence and strength",
"output_contribution_weight": "Output Tree relationship only",
"kpi_weight": "Optional inside composite output score"
},
"diagnostic_relationship_schema": {
"fields": [
"Relationship ID",
"Downstream Binding ID",
"Upstream Binding ID",
"Downstream Stage",
"Upstream Stage",
"Relationship Type",
"Attribution Method",
"Evidence / Validation Status",
"Diagnostic Strength",
"Owner",
"Review Date"
],
"relationship_types": [
"Contribution",
"Attribution",
"Process Explanation",
"Input Constraint",
"Reference / Context"
],
"diagnostic_strength": [
"Contextual",
"Associative",
"Attributive",
"Causally Validated"
],
"rule": "Do not claim causality unless separately validated."
},
"decision_product_required": [
"Decision Product ID",
"Source Report ID",
"Decision Question",
"Primary Outcome / Decision KPI",
"Primary KPI Bindings",
"Diagnostic Stage Coverage",
"D1+D2 Capability",
"Diagnostic Relationship Map",
"Decision Owner",
"Action Owner",
"Trigger Condition",
"Expected Action",
"Evidence Required",
"Review Forum",
"Review Cadence",
"Action Tracker",
"Escalation Path",
"Learning Loop",
"Certification Status",
"Operational State",
"Next-Cycle Target Owner"
],
"report_zones": {
"A": "Header",
"B": "Outcome & descriptive summary",
"C": "Output attribution",
"D": "Process diagnostics",
"E": "Input / constraint diagnostics",
"F": "Decision / action / AI"
},
"diagnostic_gate": {
"requirements": [
"Actual + Target/Baseline + Variance + Trend",
"Material Outcome variance",
"Output contribution / attribution",
"Process diagnostic path",
"Input / constraint diagnostic path",
"Ranked evidence / contributors",
"Decision owner + action path"
],
"rule": "A performance report cannot be labelled D2 Diagnostic unless these are satisfied or an approved diagnostic-data gap is documented."
},
"design_tokens": {
"input": "#2C5F8A",
"process": "#1A6B4A",
"output": "#9A6415",
"outcome": "#9D174D",
"action": "#5B3D8A",
"ai_primary": "#4F46E5",
"ai_secondary": "#7C3AED"
},
"end_to_end_chain": [
"Strategy / Org Outcome",
"Org Output",
"Departmental Output",
"Process",
"Process Output",
"Certified Source",
"KPI Definition",
"KPI Binding",
"Diagnostic Relationship",
"Reusable Component",
"Report / Dashboard",
"Decision Product",
"Outcome Variance",
"Output Attribution",
"Process Diagnostics",
"Input / Constraint Diagnostics",
"Decision Owner",
"Action Owner",
"Action",
"Evidence",
"Value Realized",
"Learning",
"Next-Cycle Target"
],
"implementation_constraint": "Continue current transformation; apply v3.9 diagnostic-first standard and BI-Team ownership model to new and in-progress work first; align completed reports through controlled review."
}v3.9 BI Ownership: Enterprise Reporting is owned and governed by the BI Team, covering governance, registers, KPI governance, bindings, diagnostic relationship governance, report/dashboard assets, Power BI implementation, certification, deployment, monitoring, adoption, change control, and lifecycle operations. Business roles remain accountable for validating business meaning and for the management decisions and actions recorded in Decision Products.
| Area | v1.2 | v3.9 — August 2026 |
|---|---|---|
| Primary visible analytical model | CDE report hierarchy + separate Business Measurement taxonomy | Input → Process → Output → Outcome is the single primary visible structure |
| Diagnostic navigation | Effect → Driver → Cause | Outcome Variance → Output Attribution → Process Diagnostics → Input / Constraint Diagnostics |
| Performance maturity | D1 or D2 depending on report/component | D1 + D2 mandatory minimum for performance reports |
| CDE | Mandatory report/component classification; colour and drill contract | Deprecated for new user-facing design; compatibility metadata only during transition |
| Power BI zones | Header, KPI band, main visuals, detail, action, AI | Header, Outcome, Output, Process, Input/Constraint, Decision/Action/AI |
| KPI card | CDE + measurement + DDPP badges | Measurement Stage + DDPP + target/variance + diagnostic contribution/drill |
| Metadata | KPI Definition + Binding with CDE overrides | Adds Diagnostic Relationship Map; removes CDE from active required schema |
| Diagnostic certification | D2 defined as variance/root-cause analysis | Explicit gate requiring Output attribution + Process diagnostics + Input constraints |
| Generator behavior | Assign CDE layer + DDPP + standard zones | Generate D1+D2 stage-based blueprint and block “Diagnostic” label without required evidence |
| Causality wording | CDE terminology could imply causal chain | Diagnostic Relationship has explicit strength: Contextual / Associative / Attributive / Causally Validated |
| Continuity | New/in-progress first; no restart | Unchanged |
| Document / Direction | Authority | Use for | Do not use for |
|---|---|---|---|
| Enterprise Reporting Hierarchy v3.8 | Operational System of Record | Live records, status, assignments, certification evidence | Interpretation / design rules |
| This HTML Reference v3.9 | Canonical Standards Reference | Diagnostic-first model, schemas, Power BI standards, lifecycle, LLM rules | Live operational values |
| Management Diagnostic Direction — Aug 2026 | Current design direction | Four diagnostic stages; D1+D2 from the start; diagnostics as primary objective | Detailed live metadata records |
| Domain Function Packs | Domain Execution Design | Domain inventory, mapping, diagnostic relationship workings, disposition, actions | Group-level standards |
| Power BI Build Assets | Technical Implementation | Theme, templates, reusable components, generator and conformance | Business KPI definitions |
Live KPI, Binding, report, owner, status, action, validation and adoption records.
Diagnostic-first structure, Input/Process/Output/Outcome rules, DDPP, Diagnostic Relationship schema, Power BI design, lifecycle, anti-patterns and LLM rules.
Map business stages, KPIs, diagnostic relationships, Decision Products, role/action/SLA and build specifications per function.
Diagnostic-first PBIX template, stage colour theme, KPI cards, action panel, AI container, RTL and conformance validator.