Appendix C — Page Definition
C.1 Overview
This appendix specifies the formal schema and structural requirements for page definitions within the Digital Experience Platform (DXP) architecture. Page definitions are declarative artefacts that describe the composition and access constraints of user-facing surfaces. All page definitions are governed by deterministic structure and are strictly separated from business logic, data processing, and workflow orchestration.
C.2 Structural Model
A page is defined by the following elements:
- Page identity
- Layout
- Slot configuration
- Access rules
No additional semantics or embedded logic are permitted.
C.3 Schema Definition
Page definitions SHALL conform to the following canonical schema:
{
"pageId": "string",
"title": "string",
"route": "/path",
"layout": "layoutId",
"requiredCapabilities": ["capability.id"],
"slots": [
{
"slotId": "header|main|sidebar|footer",
"component": "AdaptiveCardHost",
"capability": "capability.id.v1"
}
]
}
C.4 Element Specifications
C.4.1 Page Identity
pageId: Stable, unique identifier for the page.title: Human-readable label for governance and navigation.route: Deterministic route pattern. No business semantics.
Example:
{
"pageId": "case-overview",
"title": "Case Overview",
"route": "/cases/:caseId"
}
C.4.2 Layout
layout: Enumerated value. Permitted values:single-column,two-column,three-column,dashboard,modal.- Layouts are finite and centrally governed. No per-page custom layouts.
Example:
{
"layout": "two-column"
}
C.4.3 Slots
slots: Array of slot definitions. Each slot is a named contractual placeholder for a single capability output.slotId: Stable identifier for the slot region.component: Host component for rendering (e.g.,AdaptiveCardHost).capability: Capability identifier (versioned).- Slots SHALL NOT contain logic, data binding, or conditionality.
Example:
{
"slots": [
{
"slotId": "header",
"component": "AdaptiveCardHost",
"capability": "case.summary.v1"
},
{
"slotId": "main",
"component": "AdaptiveCardHost",
"capability": "case.timeline.v1"
},
{
"slotId": "sidebar",
"component": "AdaptiveCardHost",
"capability": "case.actions.v1"
}
]
}
C.4.4 Access Rules
requiredCapabilities: Array of capability identifiers required for page visibility and navigation inclusion.- Access rules are coarse-grained. Fine-grained filtering, tool access, and business rules are externalised.
Example:
{
"requiredCapabilities": ["case.view"]
}
C.5 Full Example
{
"pageId": "case-overview",
"title": "Case Overview",
"route": "/cases/:caseId",
"layout": "two-column",
"requiredCapabilities": ["case.view"],
"slots": [
{
"slotId": "header",
"component": "AdaptiveCardHost",
"capability": "case.summary.v1"
},
{
"slotId": "main",
"component": "AdaptiveCardHost",
"capability": "case.timeline.v1"
},
{
"slotId": "sidebar",
"component": "AdaptiveCardHost",
"capability": "case.actions.v1"
}
]
}
C.6 Constraints and Governance
- Page definitions SHALL NOT embed logic, data queries, workflow, or conditional expressions.
- If a page definition contains
if,else, orwhen, it is invalid. - All behaviour, data resolution, and flow control are external to the page definition.
- Slot outputs are resolved at runtime via capability invocation. The page definition is agnostic to execution strategy (deterministic, AI-assisted, hybrid).
- Layouts and slot regions are centrally governed and versioned.
C.7 Runtime Model
At runtime, the following sequence applies:
- The router resolves the route and loads the page definition.
- The layout renders static regions.
- Each slot invokes its declared capability.
- The capability resolver returns output (e.g., Adaptive Card JSON, confidence, provenance).
- The slot host component renders the output.
Pages are passive artefacts. They reflect state; they do not control it.
C.8 Illustrative Example: Case Overview Page
C.8.1 Page Frame (DXP-owned, Deterministic)
The DXP renders the page frame and slot regions prior to capability resolution. No data or AI involvement occurs at this stage.
┌──────────────────────────────────────────────────────────────┐
│ Global Header │
│ ────────────────────────────────────────────────────────── │
│ Logo Case Management [User] [Help] │
├──────────────────────────────────────────────────────────────┤
│ Breadcrumbs: Home > Cases > Case 12345 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────┐ ┌─────────────────────────┐ │
│ │ HEADER SLOT │ │ SIDEBAR SLOT │ │
│ │ (Capability: summary) │ │ (Capability: actions) │ │
│ │ │ │ │ │
│ └───────────────────────────┘ └─────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ MAIN SLOT │ │
│ │ (Capability: timeline / detail) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
├──────────────────────────────────────────────────────────────┤
│ Footer │
└──────────────────────────────────────────────────────────────┘
No slot contains data or logic at this stage. The structure is deterministic and centrally governed.
C.8.2 Slot Rendering (Capability Output)
Each slot is populated by the output of its declared capability, rendered as an Adaptive Card. The content may be resolved deterministically or via AI, as indicated by the capability contract.
Header Slot — case.summary.v1
┌──────────────────────── Case Summary ───────────────────────┐
│ Case: 12345 │
│ Status: In Progress │
│ Owner: Legal Services │
│ │
│ ⚠ Risk: Medium — likely SLA breach in 3 days │
│ │
│ Confidence: ●●●○○ │
│ │
│ Why? │
│ Based on case age, current workload, and past resolution │
│ patterns in similar cases. │
└─────────────────────────────────────────────────────────────┘
- Content may be AI-resolved (e.g., risk assessment, explanation, confidence).
- Fallback is deterministic, with reduced insight.
Sidebar Slot — case.actions.v1
┌────────────────────── Recommended Actions ──────────────────┐
│ • Request SLA Extension │
│ • Reassign Case │
│ • Add Internal Note │
│ │
│ [ Request Extension ] │
│ │
│ Confidence: ●●●○○ │
└─────────────────────────────────────────────────────────────┘
- Actions are rendered as UI elements. Navigation and workflow are externalised.
- Confidence and recommendations may be AI-assisted.
Main Slot — case.timeline.v1
┌────────────────────── Case Timeline ────────────────────────┐
│ │
│ 12 Jan ─ Case Created │
│ Source: Public Portal │
│ │
│ 13 Jan ─ Assigned to Legal Services │
│ │
│ 15 Jan ─ Additional information requested │
│ │
│ 17 Jan ─ Awaiting response │
│ │
│ ⚠ No update in last 5 days │
│ │
│ Confidence: ●●●●○ │
└─────────────────────────────────────────────────────────────┘
- Timeline events are typically deterministic.
- Interpretive insights (e.g., "No update in last 5 days") may be AI-resolved.
C.8.3 Degraded Mode (AI Unavailable)
If AI-based resolution is unavailable, slot content is simplified. The page structure and slot regions remain unchanged.
Header Slot (Fallback)
┌──────────────────────── Case Summary ───────────────────────┐
│ Case: 12345 │
│ Status: In Progress │
│ Owner: Legal Services │
│ │
│ Confidence: ●○○○○ │
│ │
│ Limited information available │
└─────────────────────────────────────────────────────────────┘
- No alternate page or UI is introduced.
- All slots remain present; only content is reduced.
C.9 Slot Determinism and Capability Resolution
Each slot is governed by three architectural questions:
- What capability is rendered?
- What is the output schema (Adaptive Card)?
- What mechanism resolves the content (deterministic or AI)?
If these cannot be answered concretely, the slot is invalid.
C.10 User Experience and Governance
- The user interface is stable and consistent, regardless of capability execution mode.
- Confidence and provenance are surfaced to the user as defined by the capability contract.
- No alternate navigation or layout is introduced for degraded or fallback modes.
- All page definitions and slot configurations are subject to architectural review and governance.