← Back to directory

views-and-content.md

architecture/views-and-content.md · 70.3 KB · 2026-11-02 12:48

Views and Content

Status: current architectural direction, 2026-09-11; implementation scope and evidence are tracked separately. Working staging baseline documented in Presentation Grid Architecture Baseline.

Owner: View/UI and Content reusable execution responsibilities, application projections, and human content operation. Examples are illustrative; they do not establish a universal lifecycle or a fixed application sitemap.

Current Dashboard-root presentation contract

The Business has exactly one presentation root: an exact dashboard_ref in its governed presentation configuration. That reference resolves to an ordinary Dashboard Presentation Object whose child references form a recursive persisted Presentation Object graph. Dashboard children are navigation candidates, not automatic menu items; only data-defined navigation.navigable: true children are included in primary navigation.

A dashboard child may declare an optional navigation.target exact Object reference when the navigable child is a dashboard summary surface whose standalone destination is a separate persisted Presentation Object. The target is resolved and authorized through the same exact-reference path as every other Presentation target; an unavailable, stale, cross-Business or unauthorized target fails closed and is not replaced by the summary Object. When the optional target is absent, navigation resolves to the navigable child itself. This permits a dashboard card and a full capability page to remain separate governed Presentation Objects without introducing a second UI model.

The generic projector resolves the graph and the generic renderer consumes the resulting RenderablePresentation. The runtime does not contain People/Marketing/Sales/Projects knowledge and does not require Capability Definitions, Capability Instances or capability-specific renderers.

Verified implementation: The generic Presentation renderer uses a six-column outer body grid for Dashboard, capability and ordinary Object page surfaces. In edit mode, each non-repeated Presentation Object is repositioned with its top-right drag handle and resized with its bottom-right resize handle; order, outer span and height are persisted as governed user preferences. Each grid-level PO owns a generic surface and recursive content remains inside that surface. See Presentation Grid Architecture Baseline for the implementation evidence.

Presentation Object lifecycle and ownership

A Presentation Object is an ordinary persisted Object with the Presentation semantic role. Its identity, Object revision, Type revision, Business scope, provenance and authorization are governed by the universal Object model. A Presentation Object is not a PHP-only card descriptor, a capability-specific record, a renderer registry entry or a copied source of business data.

The authoritative lifecycle is:

1. A Business presentation configuration stores an exact Dashboard Presentation Object reference. 2. The Dashboard and its descendants store exact Presentation Object references with mandatory object identity and revision. 3. Governed provisioning creates or revises the graph through the existing Object and Command mechanisms. It validates node identity, containment, exact references and cycle freedom. 4. The authorized projector resolves each exact reference and its permitted Presentation Definition/content bindings in the active User and Business context. 5. The projector produces the renderer-neutral RenderablePresentation representation, retaining Presentation Object identity and parent containment metadata. 6. The generic renderer serializes that authorized representation. It may provide HTML, CSS and browser interaction mechanics, but it does not authorize, select arbitrary business records or become a second persistence authority.

Presentation Definitions own declarative structure, bindings, ordering, content and permitted presentation affordances. Business Objects and related Objects remain authoritative for values, relationships and lifecycle state. User preferences may own local layout choices only when they are represented by the governed generic preference Object and exact context/Presentation references; they do not revise Presentation Objects or business records.

Independent layout contract

Presentation delivery has four separate concerns:

available PO width and content priority. Responsive adaptation must not overwrite a persisted user preference.

The generic User Presentation Preference Type remains revision 2. It persists only outer order, span and height through the existing governed Command path, keyed by exact User, Business, Presentation context and Presentation Object references. Compact/Regular/Expanded mode and internal content columns are derived at projection time and are never exposed as a user-facing selector or persisted preference. Responsive CSS may reduce the effective internal count without mutating the saved outer layout.

Projection failures and empty data

Projection must remain fail-closed. Invalid, stale, cross-Business, unauthorized, unavailable, cyclic or incompatible exact references must not be replaced with fabricated Presentation Objects, generic placeholder links or latest-revision fallbacks. A genuinely empty authorized collection is a different condition from a branch suppressed during resolution or authorization. The runtime must preserve that distinction in its diagnostic evidence and user-visible error/empty-state behavior where the delivery contract exposes it.

Data-defined display declarations

Presentation Objects may declare renderer-neutral display metadata when a visual treatment needs more structure than ordinary text, containers, collections or navigation can express. The declaration remains part of the persisted Presentation graph; it is not a PHP component registry, a capability-specific branch or a second source of business data.

The initial generic display vocabulary is:

governed.

Record-derived display declarations use an authorized_records source with an exact Type identity and bounded page size. The projector obtains records through the active User and Business authorization path, selects only declared fields, and retains available, unavailable and invalid_source states. It must not infer relationships, fabricate values, silently convert missing data to zero, or resolve an omitted revision to a different object. Aggregates and charts are therefore honest projections of the authorized records available at render time; historical trends require an authoritative measurement source and are not implied by a current record count or sum.

An authorized_records source may also declare filters and a sort_field with sort_direction. filters is a list of {field, in: [strings]} clauses that are ANDed and applied to the authorized records before aggregation, charting and record selection, so a metric, a chart and a list can describe the same bounded slice. sort_field must be one of the selected fields. A malformed filter or sort declaration yields invalid_source; it is never ignored.

Display declarations carry presentation semantics in display, which is a renderer-neutral pass-through of the persisted node. Beyond the vocabulary above, the generic renderer interprets these optional declarations:

(table columns and toolbar), display.summary (title, secondary, meta fields and status for a compact row) and display.detail (eyebrow, title, summary, status and sections of labelled fields, optionally wide). The projector supplies only the fields those declarations name as display.data.record, from the authorized record. The collection page renders one table instead of one card per record, and the detail page renders header, sections and detail-context relationship collections. Fields not declared are not displayed.

A root Presentation Object composes its page from explicit constituents. The runtime must render every embeddable_only constituent of the selected root; independent selection applies to choosing a page-level Presentation Object, not to the constituents of the root that was chosen.

Display declarations do not change navigation. A record summary becomes a link only when its Presentation Object contains an explicit authorized target; ordinary display values remain text. Empty and unavailable states are rendered as distinct, accessible messages. Responsive sizing, surfaces, typography and HTML mechanics remain owned by the UI system and generic renderer.

record_summary is context-aware without duplicating the underlying business Object. Its child fields retain their persisted semantic roles (for example primary, body, secondary and status) and its action is rendered only from the exact record target. Child declarations may specify contexts: ["detail"] for related collections that belong on a standalone record view but must not be expanded inside a collection summary. The generic renderer must not add a literal action link, infer a field role, or flatten detail-only collections into a repeated record card.

Presentation display scope and composition

Display scope is a property of the authoritative persisted Presentation Object declaration. It is independent of navigation metadata, page-level selection, outer layout, adaptive mode, internal content layout and responsive delivery. The canonical vocabulary is:

constituent of a parent that explicitly references it.

The declaration is a single constrained semantic value, not a set of user-controlled flags. A missing value on a legacy persisted Presentation Object is interpreted as standalone_and_embeddable for compatibility; new profiles and definitions must declare the value explicitly.

Composition remains an exact persisted children[] reference graph. A parent renders every authorized, valid constituent it explicitly references, including embeddable_only constituents. Independent selection is the only path that applies display-scope filtering. The delivery boundary selects the exact references for the current page or level, and the projector admits only references whose scope permits independent display. A child is never selected independently because it shares a Business, Type, label or visual structure with another Presentation Object.

Provisioning rejects a graph edge to a standalone_only child and rejects an independent root declared embeddable_only. It validates the scope vocabulary before mutation and retains the existing exact revision, Business, authorization and cycle checks. Direct object routes apply the same independent-display rule; an embedded child is rendered only through its authorized parent composition. Scope filtering does not change outer-grid packing, adaptive mode, internal content layout, preference persistence or responsive reflow.

Canonical Prerequisites

The core object model and authority contract distinguishes actual model condition and authoritative business State from intended configuration and local interaction state.

Applications as Projections

An application is a projection of the business model into an experience for a particular business and audience. It is not a new foundational data model, a provider-generated codebase, or a compulsory module boundary. The same Customer object can appear in CRM, sales, marketing, projects, support, reporting, and website-form workflows. Each view selects permitted information and actions appropriate to its task while retaining underlying identity and relationships. Navigation, forms, lists/tables, cards, detail pages, dashboards, reports, portals, and website pages are supported projection forms. An application's name or menu position must not decide who owns the underlying objects or business rules. Changing a permitted customer property through one view must not require synchronising a separate CRM copy with a marketing copy.

Canonical object presentation boundary

/objects is the canonical URL family and entry point for presentation of every persisted core Object, including User (legacy Type name Principal), Business, Person, Organisation, Project, Definition, Logic, Workflow, Presentation and future Business-derived objects. The canonical object identity surface is /objects/{id}; collection and creation/editing forms are subordinate query or operation surfaces of that same global object interface. Object lists, details, creation forms, editing forms, revision/history views and relationship views resolve through the same generic Object, Type, Definition, Presentation, authorization and Command mechanisms. No library, capability, semantic-role or entity-specific URL may render or mutate an Object.

Capabilities may provide semantic grouping and navigation to relevant Object Types or Definitions, but they have no object route. Capability navigation must link directly into /objects; it must not own entity-specific detail templates, creation forms, edit handlers or persistence paths. Workflow, Logic, Presentation and Definitions remain data-defined semantic roles represented by ordinary generic Objects and are opened through /objects/{id}. The product's scope and capability compositions belong to Definition, Capabilities, and Roadmap.

Generic Object creation and editing are View-driven presentation surfaces. They use the exact persisted View/Presentation binding to determine the editable fields and continue through the governed object.create and object.update Command effects. A separate Form Definition Object is not mandatory for these generic surfaces. The binding must still resolve the exact View and Type revisions under Business scope and authorization; a missing or incompatible binding fails explicitly. A Business record catalogue, catalogue key or current-revision lookup is never a runtime substitute for that binding.

Presentation Definitions, Bindings and Projection

The cross-cutting meaning of Object Presentation is owned by Core Object Model and Platform Authority. Presentation is the fourth semantic Object role alongside Data, Logic and Workflow; it is not a second Object model or a domain-specific UI subsystem. A Presentation Object is an ordinary generic Object whose role is to define a configured visual representation.

A Business-scoped Presentation Definition is a reusable persisted Object that declares the fields, explicit references, collections, ordering and permitted presentation affordances for an Object type. A Presentation Object is a first-class persisted Object whose semantic role is Presentation; it uses the generic Object, Revision, Relationship and Authorization model rather than a PHP-only descriptor. A Presentation Instance may remain a binding to one Business Object, while independently identifiable Presentation Objects may define reusable presentation structure and content without becoming a copied second source of business data.

The current implementation may retain legacy storage and PHP identifiers while this contract is established, but View Definition is not a separate semantic layer. The existing Business-scoped reusable field configuration is the implementation surface for Presentation Definition. Future Standard Presentation Definitions and Business-derived Presentation Definitions may be introduced through the same generic Definition/Object mechanisms without replacing this model.

Presentation-definition identity ownership

A Business-scoped Presentation Definition Object has one authoritative configuration owner for a given identity. A release declaration that resolves to a Business-scoped View Definition Object must not share that Object identity with a core or HTML provisioning profile that writes a different value. Configuration reconciliation must reject competing semantic writers rather than silently choosing the last writer or treating a runtime-provisioned value as the approved declaration.

Core Presentation provisioning may create or reconcile only identities owned by its declared profile. IDY-008 declaration identities remain owned by the trusted release and its governed installer. A presentation startup, page-load or provisioning path must not update an IDY-008-owned View Definition. If historical identity allocation has already caused an overlap, the condition is configuration drift requiring an explicitly authorized declaration-level reconciliation; it is not permission to overwrite the Object or to add a parallel View Definition store.

Object exploration therefore resolves:

/objects/{object-id}
        -> authorized core Object (User, Business or Business-owned Object)
        -> optional Presentation Instance
        -> Business-scoped Presentation Definition
        -> explicit projection
        -> generic renderer

The Business Object remains authoritative for business data. Presentation Instances may reference it and other permitted Objects, but must not duplicate its value, relationships or authority as presentation content. An empty binding-only Presentation Instance is not required for ordinary object rendering; the Business Presentation Definition governs directly unless explicit presentation-specific instance state or an independently addressable Presentation Instance binding is required.

Business applications bind presentation through exact persisted Presentation Object references. The recursive Presentation Object graph declares the presentation structure, content bindings, targets and layout; runtime projection supplies authorised values without a domain- or capability-specific card or summary model.

Each Business is associated with exactly one persisted Dashboard Presentation Object through the generic Object/reference/relationship model. The Dashboard is the root of the Business presentation graph; its recursive descendants are ordinary Presentation Objects and are not a Business-level collection:

Business
└── Dashboard PO
    ├── People PO
    ├── Marketing PO
    ├── Sales PO
    └── Projects PO

Clicking Dashboard renders that same Dashboard PO. The Dashboard's direct children provide the candidate primary navigation destinations, but child status does not intrinsically mean menu item. Navigability, label, order, visibility, icon, target and other behavior are data-defined PO properties. Non-navigable dashboard content remains part of the rendered Dashboard body without becoming a menu entry. No Capability layer, menu-item Type, collections[], items[], view_refs or configured_view_refs structure is required or authoritative for this model.

Recursive Presentation Object Contract

The existing Business-scoped View/Presentation Definition mechanism is the canonical owner of generic presentation composition. It may reference a recursive graph of persisted Presentation Objects and, where the applicable generic contracts support it, Data, Logic and Workflow constituents. This contract refines that mechanism; it does not create a second presentation model, a Capability UI engine or a registry of visual components.

Presentation-role Object
        ↓
recursive generic Object composition
        ↓
Presentation, Data, Logic and Workflow constituents
        ↓
authorized projection
        ↓
RenderablePresentation
        ↓
one generic renderer
        ↓
HTML

The parent Presentation Object may define structure or containment. A Presentation-role child defines visible composition; a Data constituent supplies authoritative business information; a Logic constituent may derive, filter, aggregate or resolve values relative to the current Object context; and a Workflow constituent may expose governed actions or process behavior. These remain ordinary Objects with exact identity, revision, authorization and provenance. A collection or repeated-record projection is an available generic resolution mechanism where configured, not the ontological definition of a Presentation Object or a mandatory PO -> collection -> record template hierarchy. Child Presentation Objects provide presentation content. Traversal is recursive with no arbitrary implementation-defined presentation depth limit; persisted graph termination and cycle detection are the safety boundary.

Relationship-backed collection bindings

The generic collection element may bind either to a Type/View-backed object collection or to an explicitly configured relationship-backed collection. A relationship-backed binding does not infer membership from names, labels, Business ownership or shared Types. Its persisted source declares exact revisioned references for the relationship Type, target Type and target View, the relationship direction, the record-template Presentation Object and a bounded page size:

collection
└── binding
    ├── kind: object_collection
    ├── source
    │   ├── kind: relationship_reference
    │   ├── relationship_type: exact Object reference
    │   ├── direction: outgoing|incoming
    │   ├── target_type: exact Type Object reference
    │   └── view_reference: exact View Definition reference
    ├── record_template: exact Presentation Object reference
    └── page_size

The source parent is the currently projected Object. Resolution first checks the parent identity and Business scope, then reads only authorized active relationship endpoints through the existing relationship reader. The declared direction is applied before endpoint projection. Each endpoint is enriched with the exact target View context and is projected through the explicitly referenced record template; View fields do not become Presentation children automatically.

Relationship Type, target Type, target View and record-template references must include positive revisions. Missing, stale, invalid, unauthorized, cross-Business or incompatible references fail closed. An authorized relationship with no visible endpoints is an empty collection, not a projection error. Endpoint Object identity, current revision, Type binding, Business and provenance remain in the renderer-neutral projection. Collection expansion is bounded by the persisted page size and the existing recursive Presentation traversal safeguards; a relationship source cannot create a new independent page surface or outer-layout item.

This binding extends the existing generic collection mechanism. It does not introduce a Project, Milestone, People or other capability-specific semantic kind, renderer branch, persistence model or authority source. Type/View-backed collections retain their existing contract and behavior.

A Presentation Definition may declare a recursive element tree using a bounded generic vocabulary:

Presentation Definition
└── elements[]
    ├── element_id
    ├── kind
    ├── role
    ├── content/value
    ├── children[]
    ├── order
    ├── layout
    ├── behavior
    └── target

The initial generic kind vocabulary is:

text
container
collection
navigation
action

The initial semantic role vocabulary is:

primary
secondary
secondary_label
body
status

These are generic presentation meanings, not HTML elements or domain concepts. For example, a secondary visual label is represented as kind: text and role: secondary_label; the renderer must not require or know a Capability-specific name such as eyebrow.

element_id is a stable identity scoped to the Presentation Definition or its parent. It is unique among siblings and carries no visual or Capability-specific meaning. A persisted Presentation Object supplies independent Object identity where independent reuse, provenance, history, lifecycle or authorization is required.

Element content is declarative and must be supplied by one of the governed sources below:

An element may contain recursively ordered child Presentation Objects. Child order is explicit and deterministic. Exact referenced revisions are resolved through the authorized runtime boundary; missing, unauthorized, invalid, unavailable and cyclic branches are suppressed rather than exposed to the renderer. Elements may be removed, added or reordered through the Presentation Definition without a PHP template change.

Layout is semantic rather than CSS-specific. Ordering is part of the element contract. CSS grid spans, HTML classes, pixel dimensions and browser mechanics are delivery concerns or user preference data, not Presentation Definition meaning.

An action element references an existing governed Operation mechanism. Events, Commands, Action Executions and Outcomes retain their existing execution and evidence meanings; presentation does not create a second action system or grant authority.

When an action presents a distinct transition Form Definition, the persisted action/affordance owns an exact form_reference using the canonical Object reference shape:

{
  "kind": "object_reference",
  "id": "<form-definition-object-uuid>",
  "revision": 3
}

The Form reference is independent of the action target. An action that invokes a persisted Operation Contract retains its exact operation_reference separately. An action that invokes the foundation object.transition Command effect does not manufacture a revisioned Operation Object. The persisted action binding must also declare the compatible target Type and invocation context; those semantics are not inferred from a Form label, target_type_id, operation_id or first-match enumeration. The persisted action binding validator accepts this optional Form binding and validates its exact Type/context contract within the existing universal Object and Presentation mechanisms; it does not create a new semantic Type, store or authority model. Malformed, unavailable, unauthorized, cross-Business, stale or incompatible bindings fail closed. The foundation object.transition effect continues through the governed Command boundary rather than a manufactured Operation Object.

RenderablePresentation is not the authoritative Presentation Definition or Presentation Object graph. It is the authorized, renderer-neutral delivery projection produced after persisted Presentation Object traversal. The generic renderer consumes this projection and is not an authorization mechanism.

Page selection is established by the delivery boundary that owns the current Business or Object page. Only the exact Presentation Object references selected for that page are page surfaces. Recursive child references are content composition and reachability; they do not by themselves select another page surface, enumerate a collection or create another layout context. The delivery projection may mark selected page surfaces and repeated collection records for layout while retaining recursively resolved children as content. This marker is projection state, not a persisted property or a new Object type.

Navigation and action targets remain semantic:

target
    ├── kind
    ├── exact Object/Type reference
    ├── exact revision where required
    └── optional exact View reference/revision

An object_collection target identifies the authoritative Type and optional View Definition. It must not persist an HTML URL as its meaning. The delivery boundary may serialize the authorized target into an appropriate URL.

For a Business-scoped configured Object, the intended binding is:

Business-scoped Object
    ↓ exact Presentation Definition/View reference and revision
Business-scoped Presentation Definition
    ↓ elements[]
authorized presentation projection

The existing Presentation Object remains a binding to the parent Object and is not a content container. Existing constituent View references remain available for nested Object collections; a root Capability Presentation Definition reference must be explicit and exact rather than inferred from a constituent.

The authorized projector resolves exact Definitions, Objects, Types, Views and Operations, applies Business scope and authorization, and suppresses invalid or unauthorized configured elements. It must not invent elements, labels, targets, relationships or visual roles.

The renderer receives generic projected elements and may translate them to HTML, CSS and browser behavior. It must not know Capability, Project, More, key, label, count_label, badges, items, navigation, actions or eyebrow concepts. A diagnostic Object/Type/Definition footer is a separate development aid and is not normal presentation content.

The generic recursive delivery path is implemented for persisted Presentation Object references. Collection cardinality is derived from authorized projected children rather than persisted as a domain count. Navigation targets retain exact authorized Object or View references; the delivery boundary may derive a URL. Action targets retain exact Operation identity and revision after existing Operation resolution and authorization; projection never executes an Operation. RenderablePresentation.elements is the target delivery path.

Layout remains semantic on the persisted Presentation Object (preferred_span, preferred_order and optional height). Delivery applies the configured six-column packing policy as derived layout.delivery state. Sparse user overrides are keyed by Presentation context and Presentation Object identity through the existing user-preference Object mechanism. Defaults, preferences and derived delivery layout are separate, and projection never mutates the shared Presentation Object.

The legacy collections[], items[] and fields[] arrays remain compatibility data for unmigrated internal callers only. They are not authoritative for the generic recursive graph, are not extended by this mechanism and are not rendered or made inspectable by the generic HTML boundary. The exact derived-value source contract and root binding field remain separate implementation work.

Generic collection and record projection

A persisted Presentation Object may declare a bounded object_collection binding in its persisted value. The binding contains an exact, revisioned Business-scoped View reference, a persisted Presentation Object record_template reference and a page size. The View is resolved through the existing PresentationCatalog; the collection is acquired through AuthorizedObjectReader, so the binding adds no second authorization path.

The runtime projects each authorized result into an ephemeral record context. The context retains the exact object ID, current object revision, Type identity, Type revision and Business identity. It does not copy the Business value into the Presentation Object. A record template is projected once per record using the same recursive persisted PO mechanism. Its record_field content binding may read only a field exposed by the resolved View, and its record_object target retains the exact record identity for generic /objects/{id} delivery.

Presentation Object
    ↓ object_collection binding
exact View Definition
    ↓ existing authorization and bounded list
record contexts
    ↓ repeated persisted record_template
RenderablePresentation
    ↓
generic renderer

Collection acquisition and layout remain separate. A collection is enumerated only when the selected page operation requests list projection; resolving a collection binding as reachable content does not enumerate it. Repeated record templates are explicit collection result surfaces, while their recursively resolved fields and content remain internal to each record surface. Selected page surfaces and top-level repeated record surfaces receive the same six-column packing and persisted layout rules; recursively resolved content does not create an additional outer-grid context. A nested collection owns its internal record list, so its repeated summaries are full-width collection items rather than columns inherited from the containing surface. When a repeated record is delivered inside another surface, it is a nested record summary rather than a second standalone card. Its record template retains an exact record_object target for an intentional record route, but the delivery boundary must expose that route as a separate accessible link, not as an anchor around the summary or its descendants. A field is ordinary text unless its own persisted target explicitly makes it navigable. This keeps nested anchors invalid by construction while preserving standalone record navigation and the exact authorized target. An empty authorized collection renders an empty collection element. Invalid or unauthorized bindings produce no projected records and never bypass the existing View/Object authority. Missing or newly inaccessible records are omitted. The initial runtime uses a bounded page size of 1–100 and does not persist a copied collection in the PO.

Historical Capability Presentation Direction (non-normative)

The following section preserves superseded design lineage. It is not current architecture, runtime authority or implementation guidance. Current presentation uses ordinary recursively persisted Presentation Objects and data-defined navigation under the Business Dashboard root.

The presentation contract is established: a projection starts from the object and its context, provides a useful holistic interpretation of the condition contributed by its constituents, surfaces relevant attention, exposes only permitted capability actions, and allows deliberate movement into explanation, investigation and configuration. This is not merely summary-first presentation; the user should normally understand the parent's current condition without inspecting every constituent. Capability composition may contain or reference presentation configuration, but presentation remains part of the existing View/projection model and does not become a Capability UI engine. The View/UI layer is not an execution or authority layer.

Presentation bindings and configuration participate in the same recursive universal composition as Data, Workflow and Logic. A binding or configuration Object may be contained or independently addressable when reuse, provenance, history or lifecycle requires it; neither case creates a separate presentation Object system, duplicate business model or new mandatory semantic Type. Release/publication identity and provenance remain distinct from the semantic Object and revision being projected.

The principle is settled while implementation remains evolvable: the exact constituent information for each projection, calculation method, layout, component, navigation, interaction detail, visual treatment and information depth remain open to exploration and testing. Future capability discovery is likewise an important area for that exploration. An unavailable or not-yet-defined capability may be described as informational context, but must not be presented as a functional placeholder action or imply implementation evidence.

Capability objects and definitions may exist independently of subscription status or a User's authority to perform a particular operation against them. A projection should expose useful, holistic Business and capability information where the viewer is permitted to see it, while deeper objects, configuration, initiation, approval and operational effects remain separately constrained by server-resolved authority and Policy. In the intended future architecture (not implemented; all Businesses are currently treated as active), Business-scoped operational use is additionally gated by the Business's entitlement; see Subscriptions and Entitlements. The platform should hide mechanical complexity without deleting the underlying model or replacing it with a conventional feature-paywall representation. A visible capability is not an available operation, and an unavailable operation is not evidence that the capability or its Business information does not exist.

Capability presentation is a projection of authoritative objects, Definitions, constituents and relationships. It must not manufacture a capability flag, adoption state or UI availability state as architectural authority. The underlying objects and relationships determine what exists; derived presentation may explain permitted capability context and actions, while the shared Data, Workflow and Logic mutation path determines what can change.

In that historical model, Available Actions were derived from the exact published Capability Definition and its referenced Operation Contracts. This paragraph is retained as historical evidence only; the current runtime derives actions from generic persisted Presentation Object configuration and governed Operation identity/authorization.

Object Presentation Routing

The canonical Object Presentation contract is owned by Core Object Model and Platform Authority. This document owns the View/UI-specific configuration, projection and composition mechanisms that implement that contract. The Object remains the business authority; Presentation Configuration declares bounded intent; Runtime Projection resolves authorised information; and the Renderer provides visual composition only.

The model may contain identity, type, status, fields, sections, items, collections, references, badges, actions and navigation. These are available composition members, not a mandatory fixed schema. Project, Dashboard and Capability presentations may compose them differently without creating separate presentation systems.

Presentation is not authority. Projection must use the applicable Business isolation, authorization, Policy, entitlement and revision rules. Renderers must not calculate business values, discover relationships, bypass authorization, invent links or infer business semantics from an Object Type. Mutations remain behind the governed Operation/Command boundary.

/objects is the canonical Object exploration surface. Routing resolves request, User, Business context, Object/binding and explicit specialised interaction target; presentation resolution and projection supply the model. History, revisions, relationships, graphs, transition forms and operation forms may remain specialised compositions, but do not create another primary Object Presentation contract.

Historical example (non-normative)

Dashboard PO
    ↓ child Presentation Object reference
Projects PO
    ↓ projection
Projects presentation
    ├── Project Count
    ├── Active Projects
    └── Project Types

The Dashboard → Projects example preserves historical terminology; the current contract is the generic recursive Presentation Object graph above.

Implementation route

The current mechanism and evidence are intentionally separated:

The current implementation may retain multiple projectors and visual compositions. Do not consolidate or delete them until their common model, legitimate composition differences and accidental duplication are separately verified.

Progressive Disclosure and Holistic Presentation

The default projection should answer the most valuable business question with the least necessary cognitive load and provide a useful holistic interpretation rather than only a summary. Complexity is progressively disclosed and hidden from the ordinary view, not removed from the model or made inaccessible to an authorized investigator.

The presentation depth is:

1. Holistic: what is happening, current state, key information, attention, important changes, significant activity and immediate actions. 2. Context: why it is happening, including relevant constituents, relationships, calculations, recent history, explanation, provenance and supporting information. 3. Mechanics: how it works, including workflow and logic definitions, object configuration, relationships, authority, revisions and detailed history.

A higher-level object should act as a useful projection of the objects beneath it. Users should not normally need to navigate into every constituent simply to understand the parent's current condition. The primary view should present what the object is and what matters about it before exposing how it is mechanically constructed. A complex Operation should normally appear first as its meaningful outcome, with the causal chain available through deliberate expansion.

Attention-First Operation

The primary operational view should answer What matters now? before presenting static reports or a catalogue of mechanisms. Attention is contextual to the object, relevant Business, current state/activity/consequences, logged-in user and that user's authority and permissions: what is relevant here, now, for this user, given what they are permitted to see and do? It may prioritize attention, current business state, significant changes, actionable work, recommendations, opportunities, useful automation summaries and deeper information in that order. Attention semantics can be supplied by workflow, state, events, activity, watched subjects, analytics and external outcomes; this presentation contract does not create a separate attention store, notification subsystem or permission model.

Attention is a derived presentation/action layer, not a replacement for object State and not a universal persisted attention_status. A determination such as awaiting human action, critical issue, recommended action, unresolved condition, newly changed information or watched object requiring review must retain or link to the underlying evidence that caused it. Ranking, notification delivery, dismissal behavior and a complete attention vocabulary remain future product work; they must not be inferred from this principle alone.

Permitted information, permitted initiation and permitted approval remain distinct. A user may see the state or consequence of an action without being allowed to initiate or approve it, and a Workflow or Operation that the current user cannot initiate or approve must not be presented as an actionable available action. Existing identity, authority, permission, approval and visibility mechanisms remain authoritative.

Automation should be visible without becoming noise. Exceptions, consequential changes, failures, approvals and useful completed operations belong near the operational surface; routine successful activity remains available through appropriate activity and history projections. Watching controls may be explicit, contextual or defaulted, but a watch or notification is never the authoritative business event, approval or permission.

Outcomes, Explanations and Certainty

Presentation should lead with outcomes before mechanisms. For example, show Customer status changed, then explain the relevant criteria, and only then expose the detailed chain of inputs, Logic, Workflow, result and provenance. Explanations should disclose basis, evidence, source, qualification and whether human confirmation is required at the depth appropriate to the user's question.

Facts, deterministic calculations, inferences, suggestions and unknowns must remain distinguishable in the UI. A suggestion must communicate what is proposed, why, its evidence or basis, material consequence, qualification and required action; it must not be phrased as a completed fact. A calculated or inferred value must not silently replace an authoritative value, and an unknown or reconciliation-required result must not be rendered as success.

Where relevant, the presentation should distinguish known fact, derived conclusion, interpretation, suggestion, uncertainty, incomplete information, source/evidence, confidence and human determination. Confidence describes support or uncertainty; it does not substitute for authority, provenance or evidence. AI-generated suggestions remain suggestions until accepted through the applicable governed path.

Configuration and deep inspection are deliberate modes. Ordinary users should work with business concepts and outcomes; authorized users can descend into object definitions, relationships, Logic, Workflow, authority, revisions, rules, history and provenance. View/Form definitions shape presentation and affordances only and cannot grant authority, broaden access or turn a visible control into a committed action.

Model and Responsibility Boundaries

View, form, navigation, content, media, template, and independently addressable block/variant definitions use the universal primitive. Their types, configuration, permissions, and relationships are addressable same-model data, not opaque frontend-only configuration. Nested field settings or scalar content remain valid values where independent identity is unnecessary. View/UI interprets model declarations and authorised data to render usable interfaces and submit permitted actions. Content manages reusable authored material, its variants, media associations, and declared lifecycle operations. Each engine is a reusable execution responsibility; the two responsibilities do not mandate two services or a service per view. Neither a renderer nor a content editor owns permission evaluation, canonical type validity, approval meaning, or generic time semantics. Server-side/runtime checks remain authoritative even when a form has client-side validation or hides a button. A view may suggest or preview a definition/configuration change, but rendering or approving an affordance does not adopt the definition or grant authority.

Business-scoped View and Form Definitions shape human-readable presentation and operation affordances only. They cannot grant or broaden authorization, bypass Policy, broaden Business scope, or grant traversal or mutation authority. Machine-readable inspection uses the governed object reader and its canonical projection without requiring a View Definition.

View/UI Contract

Definition-driven initialization uses the same projection boundary as other model-driven forms. The View/UI layer reads the applicable Definition revision and Workflow Execution requirement evidence to render labels, controls, required/optional status, current value and the permitted input action. It does not contain a Business-specific initialization schema or direct repository mutation. Server-side authority, validation, expected-version checks and Command settlement remain authoritative.

Inputs include authorised model/type declarations, view configuration, retrieved objects, user context, and available actions. Configuration describes the intended selection, fields, navigation, relationships, display, and action affordances. Outputs are projections and explicit action requests, not silent changes to business meaning. The established presentation principles are object/context-first interpretation, holistic -> context -> mechanics disclosure, attention-first operation, outcome before mechanism, business language, relevant permitted capability actions in context, preserved epistemic/certainty distinctions, ordinary-operation simplicity and deliberate authorized inspection of deeper mechanics. Concrete components, layouts, navigation and detailed interaction patterns remain open to exploration. An edit, relationship selection, submission, or workflow command must reference an approved Operation Contract revision where applicable and pass through the responsible platform action boundary. Human users need readable labels and meaningful business terminology, not database structure or prompt-engineering requirements. Forms expose required/optional information and validation feedback derived from the applicable type and action contract. Relationship selectors use authorised retrieval rather than a copied global list of object labels. Empty, loading, saving, saved, denied, unavailable, and failed states must be distinguishable where relevant. The interface must not present an unavailable backend or placeholder action as functional merely because it is visible. Concurrent edits and stale data need clear feedback; expected-version checks reject stale incompatible mutations under the settled execution contract. The first UI/login foundation is part of the initial runtime milestone. Login establishes identity, Business selection establishes a requested context subject to authority, and object views project permitted model data. A state-changing UI action references an exact approved Operation Contract revision where applicable and submits the resulting Command through the same boundary used by API, Workflow and AI adapters; it cannot mutate authoritative state directly or alter Operation semantics. Forms, navigation, editing, and important actions must be keyboard-accessible, labelled, and usable across supported screen sizes. UI system owns concrete tokens, typography, layouts, AJAX/fallback patterns, and component behaviour.

<a id="principal-profile-and-authenticated-shell"></a>

User Profile and Authenticated Shell

The authenticated User profile is a direct projection of the authorized User object (the persisted account record; legacy Type name Principal), its confirmed identity association and any authorized Media/Asset reference. A User is the authenticated, platform-scoped account; it is distinct from a Person, which is an individual profile within one Business, and neither implies or requires the other (see User account and Person profile and User Profile and Account Control). The profile is not a legacy users record, a Business contact copy or a second mutation system. The initial form may edit display name and permitted personal fields, show the verified email as identity metadata, and attach, replace or remove an optional profile image. Email editing is not presented as ordinary profile editing until an approved re-verification Operation exists.

The profile form binds to the authenticated User resolved by the server and submits an exact profile Operation revision through the existing Command boundary. It must preserve field values on validation failure, distinguish denied, stale, invalid, unavailable and unknown outcomes, and never accept User, Business, authority, credential or storage identifiers as client-defined security fields. Image controls use the media contract: upload/replace/delete is authorized server-side, bytes are protected, and the projection exposes only a safe authorized rendition/reference.

While authenticated, the application shell renders one persistent User account control in the top-right region. It is the single User control: it contains the available profile image or an accessible fallback, identifying display information, a link to the User profile and the existing logout action. It is omitted or replaced by unauthenticated admission actions outside an authenticated session. The control remains keyboard-operable at desktop and mobile widths, manages menu focus and dismissal, and never represents Business authority, Business context or a Person profile. The authenticated navigation also exposes Businesses, which lists only server-resolved authorized Business identities, provides an empty state when none exist, and offers business.create when the active platform grant and Policy permit it. business.create is free and is not gated by entitlement; Business-scoped operational use is intended to be gated by the Business's entitlement in the future architecture (not implemented; all Businesses are currently treated as active).

Unsubscribed Preview and Guest Presentation (intended future architecture)

Two distinct experiences are intended: an unsubscribed Business's promotional preview, and a Guest User's presentation of a Business (see Subscriptions and Entitlements and Licensed and Guest Users). Presentation is not authority: showing, hiding or simplifying content never grants or removes the ability to execute a Business operation, and a hidden control is not security.

Synthetic promotional content must never become genuine Business data in the authoritative Business Graph and must be labelled illustrative. The storage mechanism for such content is unresolved (PRR-065); no second data model is introduced by this document. Guest access must be enforced at retrieval, authorization and projection boundaries, including aggregates, counts, search, relationship existence, caches, exports and API responses, and must be revocable. None of this is implemented.

Interaction State and Business State

UI/interaction state is not authoritative business State. Selected tabs, filters, focus, expanded nodes, navigation, loading indicators and unsaved form edits describe an interaction, not a committed lifecycle change. A primitive UI flag or display label is not an addressable State definition, nor an occurrence of a business transition.

The projected interface can depend on Business, Identity, Authority, object, business State and Workflow context. Changing a local selection or displayed control cannot establish authority, change that context's permissions, certify commit or decide an Action's outcome. UI visibility is not enforcement.

An edit becomes a business mutation only through the normal Command -> Validation -> Authority/Policy -> Commit path. Update the displayed committed business State only from an authoritative confirmed result; retain pending, failed, stale and Unknown/Reconciliation distinctions. An optimistic preview may show proposed values, but must not present them as committed state or silently retry an uncertain effect.

If preferences or drafts are persisted as platform data, their own mutations follow the same governed path. Saving them does not implicitly transition the subject business object, approve it or publish it. Local interaction state can remain transient without manufacturing a business Event for every click.

Conversational AI is another interface to this same runtime. It may prepare an interaction or propose a Command, but it does not supply alternative business semantics, authority or a commit boundary.

Human-Operated Editing and Preview

Human operation comes first: create/edit pages, choose templates and blocks, attach media, review, and request publication without AI. Rich text, plain text, structured fields, and permitted markup are editing modes, not substitutes for type validation. Draft autosave and resuming incomplete work are useful requirements, not evidence that every editor already supports them. Preview should show relevant content and variant context without invoking publication or treating preview as approval. Untrusted markup needs an appropriate isolated preview and safe rendering, with security mechanisms owned by Security and operations. A local preview must state material fidelity limits when it cannot reproduce backend/theme rendering accurately. Forms rendered inside content need explicit permitted submission targets and business actions; visual form markup alone is not an operational workflow. Generated content enters the same review/editing surface; it must not have stronger action authority than human-authored content. The existing WordPress editor's title, page/post choice, selected site, markup input, sandboxed preview, saved work, and remote draft result are reusable interaction examples. They are not implementation evidence for a generic View/UI Engine, normalized tool validator, approval queue, or publishing engine.

Content and Variants

Content covers website pages, marketing material, reusable sections, templates, documents, and other authored business material. Classification may include topic, product, campaign, category, and content type such as social, blog, email, or advertisement. Classification relationships must preserve shared identity where reuse matters rather than create disconnected tag universes per application. A base content item can support destination-specific variants with text, media, hashtags, and call-to-action overrides. Preserve the selection principle: use an applicable variant if one exists; otherwise use the base content. That selection does not bypass destination validation or silently invent a missing required field. The relevant type/configuration must make partial override and fallback behaviour explicit; this document does not prescribe an implicit field-merge algorithm. For example, a social variant can shorten text while an email variant supplies a different CTA and media selection. Human preview and delivery must agree on which base/variant material and target context they are evaluating. Character limits, required media, allowed formatting, and available backend tools constrain valid delivery under the integration contract. Content changed after scheduling and variants missing required destination fields must be surfaced, not hidden behind a successful save.

Media and Asset Management

Assets include images, video, documents, logos, font resources, and other permitted files, reusable beyond marketing campaigns. Addressable metadata and relationships connect an asset to content, brand guidance, a product, or a knowledge source. File bytes may need specialised storage, but their platform identity does not become a competing object model. Required operations include authorised upload, discovery, preview, association, tagging, and reuse; processing may include resizing, compression, conversion, and metadata extraction. Useful interaction patterns include grid/list views, drag-and-drop, filtering, in-place previews, renaming, notes, bulk upload, and download where permitted. File notes can provide contextual knowledge; they are not automatically executable settings. Large files, unsupported formats, duplicate assets, processing failures, and assets removed after assignment need explicit handling. An asset's presence in the library does not guarantee it meets a target channel's dimensions, format, or availability requirements. Referencing content must not silently render an unrelated replacement when an assigned asset becomes unavailable. Upload size, detected MIME validation, generated storage names, output handling, and access protection belong to operational security. CDN use, automated tagging, and asset-performance tracking remain scope choices, not foundational requirements.

Documents and Knowledge

A Document can represent an uploaded PDF or authored deliverable; content concerns its representation, editing, presentation, and use. Knowledge concerns what the business knows from it, its provenance, authority, applicability, and explanation. A document may be a source for multiple knowledge items, while a knowledge item may relate to multiple documents or observations. The identities and relationships should remain inspectable rather than equating a file path with all knowledge derived from it. The pricing-policy case owns the full extraction-to-history example. Likewise, Brand Voice text or guidance about typography can remain knowledge alongside structured palette/font configuration. Rendering that guidance must not silently convert its prose into an enforced constraint.

Lifecycle and Collaboration

Content lifecycle and permitted transitions come from the relevant type/configuration; there is no single lifecycle for all content or objects. Illustrative editorial sequence: draft -> review -> approved -> scheduled -> published -> archived. Illustrative alternatives include rejected or needs_changes; these labels are not mandated platform states. Approval is a governance decision, scheduling is a timing concern, and publication is an external or internal delivery operation. A WordPress draft result must not be presented as live publication or approval merely because remote creation succeeded. Editor attribution, timestamps, revision inspection, and restoring prior material are required considerations under canonical Time and Events decisions. Restoration, editing after approval, and editing after scheduling require explicit rules about authority and which content is affected. Comments, inline discussion, approval requests, notifications, and activity views should retain links to their relevant subjects. Notification display/read state is not the authoritative approval decision or event history. Permission conflicts, concurrent edits, external revision changes, and unavailable assets need visible resolution paths. Real-time editing and portals are possible capabilities, not assumed MVP infrastructure.

Positive and Negative Examples

Positive: the same Customer is projected into an internal sales form and a restricted portal, with different permitted fields and actions. Positive: an editor selects a site-valid heading tool, previews the result, saves local work, and separately requests a remote draft. Positive: a product image is reused in a page and email variant, with target-specific validation before either is delivered. Negative: a generated dashboard creates its own customer store to avoid shared-model permissions. Negative: a hidden Publish button is treated as access control while direct action requests remain unchecked. Negative: a well-rendered preview is treated as proof of policy approval, complete backend fidelity, or successful publication. Negative: sanitised markup is assumed to satisfy model validity and business permissions merely because scripts were removed.

Implementation and Acceptance

UI architecture is settled. Implementation architecture specifies server-rendered model projections and shared Commands; UI system specifies the first shell/login/object forms. Stale versions are rejected; restoration is a new governed mutation referencing old material, not rewriting history. Advanced editing, portals and native/WordPress publishing are later capability depth, not architecture decisions needed before login and object inspection work.

Acceptance checks: configure usable views without AI; reuse objects across applications; enforce field/action access; validate variants and assets; distinguish preview/draft/approval/publication; demonstrate document-to-knowledge links; expose editing/delivery failures. Implementation architecture, WordPress, and Implementation status own mechanisms, adapter detail, and verified implementation evidence.

Source Lineage

Source map and documentation ownership govern traceability and canonical changes. 02 technical architecture, application generation; 03 engines and MVP, interface/content responsibilities and human operation; 01 product and principles, ease of use and business ownership; 00 combined handoff, corresponding sections provide the foundation. Older content-system, media-management, user-collaboration, UI Structure, asset-library UI, CMS strategy, and application Automations sources contribute variants, lifecycle examples, file interactions, preview, and collaboration details; their schemas, fixed sitemap, and deployment/customer assumptions are not carried forward.