# AI

Status: current architectural direction, 2026-09-11; provider-independent implementation and output-validation mechanisms remain unverified.
Owner: optional AI/Intelligence responsibility and the boundary between assistance, platform validation, and execution.
Examples are conceptual contracts, not permission to deploy autonomous agents or a particular provider SDK.

## Canonical Prerequisites

- [Objects and types](objects-and-types.md) owns `{id,type,value}`, addressable type definitions, and primitive/type validity.
- [Business model](business-model.md) owns the connected graph and same-model Business DNA/configuration.
- [Semantics](semantics.md) owns Rule, Policy, Constraint, Goal, and Decision meanings.
- [Time and events](time-and-events.md) owns Event, historical identity, provenance-time interpretation, and audit/history distinctions.
- [Identity and governance](identity-and-governance.md) owns permission, policy enforcement, approval, risk, and autonomy decisions.
- [Retrieval](retrieval.md) owns structured-first authorised context assembly; [Knowledge](knowledge.md) owns epistemic provenance and authority distinctions.
- [Workflows and automation](workflows-and-automation.md) owns execution; [Communication and integrations](communication-and-integrations.md) owns normalized tools and backend invocation.

The [core object model and authority](core-object-model-and-authority.md) contract governs the distinction between actual configuration, proposed definitions, derived State and authoritative mutation. AI assistance cannot bypass that distinction.

AI remains optional assistance over the universal Data, Workflow and Logic model. It does not create an AI, Intelligence, Knowledge, Network, Marketing or other semantic role, and it cannot establish a separate architectural path for capability assignment, learning, mutation or authority. AI proposals must use the same validation, authorization, approval, mutation, provenance and history boundaries as human-authored changes; no-AI operation remains required.

## Optional Intelligence, Deterministic Platform

AI supports the business platform; it does not replace its model, state, workflows, validation, or authority.
Core operation must continue when no provider is configured, a provider is unavailable, costs are undesirable, a model changes, or the user declines AI.
Business users must be able to create and inspect model configuration, knowledge, workflows, content, and applications without prompt engineering.
The business representation remains readable, editable, inspectable, exportable, and independent of a particular model.
AI/Intelligence is a reusable execution responsibility, not a fixed software service or an engine per provider.
Business data, knowledge, workflow definitions/nodes, configuration, events, policies, permissions, tool definitions, and saved AI proposals use the universal model when persistent/addressable.
Their types are addressable objects too; provider conversation state, vector stores, or tool schemas cannot establish a competing foundation.
Scalar prompts, parameters, and nested result values remain valid where independent identity is unnecessary.
The platform owns accepted configuration and action execution; a provider's response is not the live business state. A generated definition, relationship, value or workflow remains a proposal until it passes the same deterministic validation, authorization, approval and mutation path as a human-authored change. AI does not select an authoritative definition or adopt it for an existing instance by implication.

AI may interpret a business description, estimate an initial value, identify missing information or propose objects, relationships, workflows and configuration during onboarding. An estimate remains distinguishable from an authoritative value and must be inspectable, accepted, modified, rejected or replaced through the applicable governed path. Every assisted onboarding or configuration route must retain a manual and deterministic route for the same business decision; AI is an accelerator and interface, not a mandatory configuration dependency.

AI-guided configuration operates against the actual model rather than inventing a parallel configuration language. The intended path is: Business description -> known structure and evidence -> applicable Definitions -> unresolved or ambiguous requirements -> targeted questions -> human answers -> deterministic validation -> governed mutation. Questions should arise from actual Definition requirements, missing constituents, conflicting evidence or unresolved model information, not from an unconstrained conversational wizard. The equivalent underlying inspection, decision and mutation path must remain possible without AI; this AI + human parity is a platform acceptance principle, not a future provider feature.

## Responsibilities and Output Forms

AI can assist natural-language interaction, configuration, content creation, analysis, recommendations, summarisation, marketing, and search interpretation.
It can help explain workflows, propose workflows, identify patterns, suggest optimisations, and recognise opportunities to formalise knowledge.
Knowledge assistance includes extracting proposed Assertions, identifying contradictions or missing information, proposing classifications/relationships and answering within authorised context. Interpretation remains distinguishable from accepted knowledge and authority.
Inputs are controlled task context and authorised data, not unrestricted access to the whole platform.
Possible outputs include answers, content, recommendations, configuration changes, workflow definitions, proposed objects/properties, knowledge, and optimisations.
Each output has an expected form and intended use so the platform can validate it before presenting, accepting, or executing it.
An answer, a proposal, approved configuration, and an executed action are different things and must remain distinguishable.
AI may help design new reusable behaviour, but adding engines or production code remains a governed development activity.
Arbitrary runtime code generation or self-rewriting application code is not the normal configuration path.

## Provider-Independent Boundary

The platform defines task intent, input/output contracts, available capabilities, and validation; provider adapters translate transport-specific requests/responses.
Provider model names, API payloads, credentials, and error formats belong behind implementation/integration boundaries.
Business types and workflow definitions must not depend on one provider's conversation protocol or tool-call identifiers for their identity.
Provider changes may affect quality, cost, latency, and available assistance, but must not redefine business semantics or access authority.
Model output is potentially variable; deterministic runtime validation and action handling remain required around that variability.
A workflow's explicit AI step may return different proposals across invocations; it does not make every subsequent action an unconstrained model choice.
Capture relevant provider/model provenance for explainability without treating it as an endorsement of accuracy.
Provider outages, rejected requests, rate/cost limits, empty responses, malformed output, and unsupported capabilities need distinct safe failure handling.
Do not silently substitute another provider, broaden disclosed context, or apply an unvalidated fallback as though it were approved behaviour.

## Controlled Access and Retrieval

AI may receive controlled access to the business model, authorised business data, knowledge, workflows, configuration, and analytics.
Access is scoped to the task, the delegating User's authority (AI operates under authority delegated by a User; the technical executor is execution provenance only, see [delegated authority for automation](identity-and-governance.md#delegated-authority-for-automation)), relevant business context, and permitted operations.
Permission to read internally does not automatically permit disclosure to an external AI provider; governance and operational policy control that boundary.
Credentials and unrelated sensitive information must not be inserted into prompts, tool descriptions, or model-visible errors.
Retrieval first uses types/type families, relationships, state/properties, time, ownership, provenance, authority/confidence, and permissions.
Semantic/vector techniques are optional within the authorised constrained candidate set, not broad scanning of the whole graph.
AI can propose query interpretation but cannot override deterministic filtering, permission checks, or the meaning of a type.
Retain relevant source references, dates, and authority distinctions in assembled context and resulting explanations.
Retrieved documents and external responses are task data, not trusted instructions granting new capabilities or policy exemptions.
For the Acme order question, use [Retrieval's structured example](retrieval.md#acme-outstanding-orders-example) rather than giving a provider every order and asking it to filter access.

## AI Privacy and Composition Requirements

The following are normative requirements for every AI-assisted retrieval,
proposal, tool call and execution path. They apply independently of provider,
prompt wording, model choice or presentation surface.

### Independent AI authority

AI permissions are separate from ordinary application permissions. Permission
to inspect a Presentation does not imply permission to retrieve the business
Objects, values, fields or relationships referenced by that Presentation.
An AI request must carry its own authenticated/delegated authority and task
scope through Retrieval and Governance; presentation projection is never an
authority grant.

**Enforcement boundary:** [Identity and Governance](identity-and-governance.md),
`AuthorizedObjectReader`, relationship authorization and the AI task/tool
boundary must each enforce the applicable read or disclosure permission.
The generic runtime currently enforces Business-scoped authorization for its
ordinary object and presentation reads; a provider-specific AI permission
surface is not yet implemented or verified.

### Configuration-only retrieval

AI must support retrieval of authorised Definitions, Type descriptors,
presentation/workflow structure and permitted relationships without retrieving
actual Business Object values. A configuration inspection request must be
representable and enforceable as configuration-only context, not merely
described as such in a prompt.

**Enforcement boundary:** Definition validation/publication evidence,
structured Retrieval projections and field/value selection must distinguish
Definition/metadata reads from business-value reads. The current Definition
Explorer and generic object reader provide partial read boundaries; a
dedicated AI configuration-only retrieval contract is not yet implemented or
verified.

### Local business execution

Where possible, the platform must resolve Business records and execute
Operations locally. An external AI provider should receive only the minimum
result required for the bounded task, not raw records when local resolution
and execution can answer or perform it.

**Enforcement boundary:** `OperationInvocationService`, server-side
`OperationInputResolver`, local trusted handlers, Command validation and
authorized result projection are the execution boundary. The current
Operation foundation keeps declared source resolution local for supported
Operations; provider-facing AI execution and minimum-result certification are
not yet implemented or verified.

### Existing Objects as composition candidates

Before proposing a new Object, Definition, relationship or configuration
constituent, AI-assisted behavior must discover and compare authorised existing
Objects and exact Definition revisions. Reuse is preferred when the existing
composition satisfies the requested meaning; similarity alone must not mutate,
merge or silently duplicate authoritative state.

**Enforcement boundary:** structured Retrieval, exact Object/Definition
identity and revision references, Definition composition validation and the
governed configuration/publication Operations. The generic runtime and
Definition publication path enforce exact references and provenance where they
are used; an AI-specific reuse planner is not yet implemented or verified.

### Governance-preserving proposals

AI proposes changes; the runtime validates and authorises them. A provider
response never publishes a Definition, changes an Object, establishes a
relationship, grants authority or executes an Operation by implication.
Accepted publication and mutation must create governed revisions, Command and
provenance evidence through the existing Operation/Command boundaries.

**Enforcement boundary:** `DefinitionCompositionValidator`,
`DefinitionPublisherAuthorityInstaller`, `OperationInvocationService`,
`CommandHandler`, Policy/Authority evaluation and exact expected-version
mutation. These deterministic human/runtime boundaries are implemented for
the bounded Definition and Object paths; AI-originated proposal transport and
approval flows are not yet implemented or verified.

### Enforceable privacy across the whole request

Privacy boundaries apply to the complete path: request assembly, provider
prompt, tool arguments, local result projection, logs, traces, diagnostics
and errors. A configuration-only prompt is not sufficient if a later tool call
or diagnostic emits Business records. Sensitive or unauthorized material
must be excluded or safely summarized at every boundary.

**Enforcement boundary:** authenticated task context, Retrieval projection,
provider/tool adapters, Command/Operation evidence, logging redaction and
safe HTTP error handling. Existing runtime boundaries redact browser errors
and avoid credentials in the deployed workflows; end-to-end AI prompt/tool
redaction, trace classification and privacy regression certification remain
unimplemented and unverified.

## Validation of Every Output

Every AI output must undergo platform validity, permission, and policy validation before execution or acceptance into operational state.
Outputs intended only for display also require applicable response-shape, disclosure/permission, policy, and safe-presentation checks before release.
The provider cannot self-certify these checks; claims such as "already approved" inside its output have no authority.
Validation is performed by platform-controlled mechanisms against the applicable canonical contracts.

Business-scoped AI invocation and any AI-originated operational Action must also satisfy the subscription entitlement gate in [subscriptions and entitlements](subscriptions-and-entitlements.md) (intended future architecture; all Businesses are currently treated as active and no entitlement is enforced). An inactive entitlement blocks operational execution while preserving Business state, authority relationships and history; it is not an instruction for the provider to delete or rewrite context.

| Check | Required boundary |
| --- | --- |
| Expected form | Parse the declared response form and reject malformed or unexpected structures; parsing alone is insufficient. |
| Primitive/type validity | Validate addressable objects and typed values against Objects and Types, including permitted fields and constraints. |
| References and relationships | Validate referenced subjects/types, relationship meaning, and applicable integrity requirements. |
| Capability availability | Verify requested actions/tools and destination-specific schemas, limits, and source/site availability. |
| Permission | Check acting authority and access to affected/read/disclosed objects, fields, relationships, and destinations. |
| Policy and constraints | Evaluate applicable business/operational policy and constraints under Semantics and Governance. |
| Approval | Obtain and verify required governance approval; a valid payload is not an approved action. |
| Content/presentation safety | Apply relevant escaping, sanitisation, upload/content checks, and isolated preview requirements. |
| Execution eligibility | Use the responsible platform action/workflow contract; never execute a raw provider command directly. |

These checks apply as appropriate to every output category, not only to workflow definitions or tool calls.
Sanitisation alone is not validation: removing unsafe HTML does not prove type validity, tool availability, business correctness, permission, or approval.
Likewise, well-formed JSON and a human's approval do not cure invalid references or forbidden effects.
An answer citing unavailable or unauthorised evidence must not disclose it; unsupported claims need visible qualification or rejection as appropriate.
Schema validation cannot prove all factual claims true; preserve source evidence and uncertainty rather than claiming automatic truth verification.
Rejected output should expose a useful, non-sensitive reason and remain non-executable; repair/regeneration does not bypass the same checks.
Saving a proposal for review does not activate it or make its proposed business claims authoritative.

## From Proposal to Permitted Action

1. An authorised user or configured workflow requests a bounded assistance task.
2. The platform assembles permitted context and the expected output/tool contract through Retrieval and the relevant engines.
3. A provider returns output that is treated as untrusted proposed material.
4. The platform validates form, model/relationship validity, capability availability, permissions, policy, and content safety as applicable.
5. Any required approval is obtained through Identity and Governance; reviewers see material evidence, effects, and uncertainty.
6. The responsible engine/workflow performs only eligible validated actions, with further applicable checks at the action boundary.
7. The platform records the actual result and links relevant provenance, decision, and outcome under Time and Events.

This sequence uses the settled [commit and recovery contract](workflows-and-automation.md#action-preconditions-and-commit-boundary), including current authority, relevant versions and dependency rechecks. It does not promise exactly-once remote effects.
Approval must cover the current operation; changed inputs/configuration require explicit applicability evaluation, not automatic reuse of earlier approval.
An explicit AI workflow action can fail or produce unusable output without granting permission to invent a business outcome.

## Materialised Validation Determinations

Materialisation preserves the semantic scope established by its underlying validation/reuse chain. It does not broaden object scope, Business scope, temporal scope, Policy scope, Action applicability or authority. Record the exact scope represented and the supporting provenance. Materialisation compresses reasoning; it does not expand meaning.

A determination valid only for `Project:P123 / Specification:v4 / ProposalApproval` cannot become valid for `All Projects / All Actions` merely by being materialised. A broader conclusion requires a new semantic determination under explicit governing validation/reasoning rules, with provenance demonstrating why that scope is justified.

A materialised determination is a normal addressable object with its own State and State Transitions. Illustrative states include Active, Expired, Superseded, Invalidated and Withdrawn; the type declares the supported lifecycle, not a universal enum imposed on all objects.

Its lifecycle is independent of the underlying Validation. Invalidating the determination does not invalidate that Validation. Invalidation of an underlying dependency may make the determination stale or inapplicable, but the transition must be explicitly evaluated and recorded. Every lifecycle change is an addressable [transition occurrence](time-and-events.md#durable-history-and-transition-occurrences).

A superseding determination never erases its predecessor. Committed Actions that relied on it remain historical facts; active dependent workflows are re-evaluated under their dependency rules. Example: Policy P7:v4 changes materially; Determination D88 transitions from Active to Superseded, and D103 becomes Active. D88 remains addressable with the reason for supersession and its historical scope.

This contract does not reconstruct absent earlier validation-chain clauses from transcript numbering. The initial implementation records explicit source/version dependency references, checks them before reuse and requests a new determination when reuse is unsupported. A saved determination never grants itself authority.

## Knowledge, Content, and Evolution Examples

Knowledge: an assistant answers a pricing question using the authorised applicable policy source, distinguishing extracted text from inferred advice.
The [pricing-policy seven-step case](knowledge.md#pricing-policy-pdf-seven-step-case) owns the full document/provenance/history sequence.
Content: an assistant proposes a page using the selected site's normalized tools; users can inspect, edit, and preview it without publishing.
The platform checks schema, site availability, limits, permissions, policy, and safety before any permitted draft/publication action.
Workflow: a user requests three post-sale tasks; AI proposes readable addressable nodes, not custom executable source code.
Evolution: AI may help assess repeated manual activity, but [Analytics and evolution](analytics-and-evolution.md) owns the full Observe -> Understand -> Suggest -> Approve -> Implement -> Measure loop.
None of these examples requires AI for the corresponding human-operated business capability.

## Provenance and Institutional Memory

Distinguish user-entered knowledge, imported source material, observed behaviour, inference, and AI-generated proposals.
Generated content or inferred knowledge must not automatically become approved company policy.
Retain useful task/source references, generated-output identity, relevant provider/model context, decisions, and actual effects under the canonical history contract.
Do not retain full prompts/responses indiscriminately: sensitive content, access, retention, and external disclosure remain governed.
A confidence score is neither evidence of approval nor a replacement for source authority and applicability.
Accepted or rejected suggestions and measured outcomes can contribute to business memory independently of any provider's chat history.
Historical identifiability is required where relevant; replay guarantees and immutable prompt storage are not invented here.

## Positive and Negative Examples

Positive: a malformed proposed workflow is rejected before effects, and a user can still create the workflow manually.
Positive: valid content for Site A is rejected for Site B when the mapped tool is unavailable or the caller lacks destination authority.
Positive: an authorised policy answer preserves its source and explicitly qualifies an inference rather than presenting it as approved fact.
Negative: a system executes a model tool call because the provider marked it safe or because its JSON parses.
Negative: sanitised Gutenberg markup is treated as complete platform validity, permission, and policy validation.
Negative: provider-generated confidence or a proposed risk label grants itself broader autonomy or bypasses approval.
Negative: turning off AI prevents normal enquiry handling, order retrieval, content editing, or approved deterministic workflow execution.

## Current Evidence and Implementation

The inspected WordPress generation path uses provider-specific configuration, resource-label prompting, and block-HTML sanitisation before returning content to the editor.
That is evidence of a bounded existing content feature, not a provider-independent intelligence layer or comprehensive normalized-tool/policy validation.
Its not-configured/connection/rejection/empty-response handling supplies useful failure examples, not proof of the new architecture.

The authority and materialisation contracts are settled under [D01-D10](../governance/decisions.md). The first milestone requires no AI provider, but tests must submit AI-originated proposals through the same authoritative mutation path and reject forged authority. Provider integrations and sophisticated validation reuse are later implementation depth; unsupported reuse is refused rather than assumed valid.

Acceptance checks: operate core capabilities without AI; restrict context and provider disclosure; validate every output category; reject forbidden effects despite valid syntax; preserve generated provenance; exercise provider failure; distinguish proposals, approvals, and actual execution.
[Implementation architecture](../implementation/architecture.md), [Security and operations](../implementation/security-and-operations.md), [Development](../implementation/development.md), and [Implementation status](../implementation/status.md) own mechanisms, tests, and evidence.

## Source Lineage

[Source map](../governance/source-map.md) and [documentation ownership](../governance/documentation.md) govern traceability.
[01 product and principles](../archive/architecture-sources/01-idiosyncrasy-product-and-principles.md), optional AI and business ownership; [02 technical architecture](../archive/architecture-sources/02-idiosyncrasy-technical-architecture-and-data.md), configuration/AI architecture; [03 engines and MVP](../archive/architecture-sources/03-idiosyncrasy-engines-workflows-and-mvp.md), human-operated first and initial exclusions; [00 combined handoff](../archive/architecture-sources/00-idiosyncrasy-combined-handoff.md), corresponding material provide the foundation.
Older WordPress and CMS/tool-definition sources and inspected generation/page-builder code contribute source-specific examples and limitations only; no provider coupling, schema shortcuts, or sanitisation-only validation is promoted into this contract.