# Praxis Platform — Expanded LLM Reference > Referência expandida da plataforma Praxis para LLMs e agentes de documentação. > A fonte machine-readable desta projeção é `/llm-index.json`. ## 1. Purpose and Reading Contract Praxis é uma plataforma enterprise de decisões semânticas governadas e materialização runtime para aplicações internas no stack Java/Spring e Angular da empresa. Promessa: One corporate API. Many governed experiences. Less frontend to maintain. Categoria: Governed semantic decision and runtime materialization platform for enterprise internal applications. Este documento organiza a plataforma pela cadeia: `backend metadata grounding -> governed knowledge and semantic intent -> canonical decision -> simulation/review -> approval/publication -> derived materializations -> runtime observation -> operational proof -> public projection` Regras: - Contratos e owners canônicos vencem resumos editoriais. - O Quickstart prova integração downstream; não redefine os starters. - O corpus HTTP classifica evidência publicada; não se torna owner do contrato. - UI, forms, tables, option sources, workflow actions e manifests são consumidores/materializações, não fontes primárias da regra de negócio. - Patches são uma trilha local de materialização de componente, não a unidade primária da plataforma. ## 2. Commercial and Category Boundary Buyer narrative: - Praxis fits into the company's Spring and Angular stack instead of replacing it with a closed app builder. - The host team keeps domain code, security, routes, theme, Angular Material, providers, reporting, observability, and deployment ownership. - Spring Boot starters publish semantic capabilities that the runtime and AI can understand: schemas, filters, actions, surfaces, rules, and context. - Angular libraries materialize tables, forms, lists, workflows, and assistant surfaces inside the host from governed decisions and approved configuration. - The same corporate API can support multiple governed experiences by tenant, profile, user, operation, or context without duplicating data, business rules, or frontend screens. - AI is positioned as governed authoring over contracts, capabilities, declared tools, and reviewable decisions, not as arbitrary code or JSON generation. Avoid these claims: - Do not say Praxis replaces the engineering team or the enterprise host application. - Do not say Praxis removes all frontend code; say it reduces repeated screen code and manual variation work. - Do not present AI-generated JSON or patches as the primary modeling unit. - Do not turn architectural direction into publicly proved runtime evidence without checking the claim matrix. Praxis não compete na mesma categoria de React, Angular Material, PrimeNG ou bibliotecas de componentes. Essas tecnologias podem continuar como framework e infraestrutura visual do host. Praxis resolve grounding semântico, authoring governado, decisões, materialização runtime e redução de variações implementadas como forks de tela. ## 3. Source-of-Truth Hierarchy ### praxis-metadata-starter - Kind: `canonical-backend-metadata` - Role: Spring Boot starter adopted inside the host Java backend to define canonical backend metadata semantics, x-ui vocabulary, structural schema resolution, and resource-oriented discovery surfaces without moving domain ownership out of the company. ### praxis-config-starter - Kind: `canonical-config-and-decision-governance` - Role: Spring Boot starter adopted inside the host Java backend to define canonical remote UI config, ui_user_config semantics, ai_registry, api_metadata, AI orchestration contracts, and the natural governance boundary for semantic decision authoring, publication, and materialization. ### praxis-ui-angular - Kind: `official-runtime` - Role: Defines the official runtime, cockpit, and public Angular libraries installed inside the customer host app to materialize governed Praxis decisions while the host keeps routes, auth, theme, layout, deploy, and integration ownership. ### praxis-api-quickstart - Kind: `reference-host` - Role: Hosts the canonical starters in a real Spring Boot application and provides downstream integration proof without becoming the owner of metadata, configuration, AI, or decision semantics. ### praxisui-http-examples - Kind: `published-operational-evidence` - Role: Defines what is operational now on the published backend and classifies examples as llmOperational, protectedContract, or referenceOnly. ### praxis-ui-landing-page - Kind: `official-public-docs` - Role: Publishes official public documentation, guides, and LLM-facing entry points, but does not redefine canonical backend or runtime contracts. ### Precedence when sources diverge - Canonical contract beats editorial summary. - Published operational evidence beats site-level extrapolation about what works now. - Aggregated capabilities are snapshots, not a second source of truth for structural schema. - Do not present AI-generated JSON or patches as the primary Praxis modeling unit; use governed semantic decisions and derived materializations. ## 4. Evidence Classes - `confirmed_today`: Supported by current code, runtime, documentation, or local validation. - `publicly_proved`: Demonstrated through the published quickstart, Employee operations — enterprise casework, dynamic-page catalog, or HTTP examples. - `local_authenticated_proof`: Demonstrated locally against the canonical quickstart and Neon with authentication/origin protection, but not safe as a public unauthenticated example. - `architectural_direction`: Canonical platform direction for surfaces that still need repeatable public proof or productized rollout evidence. - `roadmap`: Needs productization, rollout proof, or additional public evidence before becoming sales copy. Nunca promova `architectural_direction` ou `roadmap` a disponibilidade atual. `confirmed_today` não significa automaticamente prova pública. `protectedContract` documenta um contrato protegido e não autoriza execução write safe-first. ## 5. Canonical Platform Lifecycle ### 5.1 Semantic grounding O Metadata Starter publica schema estrutural, discovery, actions, capabilities, queries e option sources. Domain Catalog, Domain Federation e Domain Knowledge acrescentam vocabulário, relações, ownership, evidência, visibilidade e contexto LLM-safe. Essas camadas não executam regras finais. ### 5.2 Semantic intent A intenção primária é resolvida por LLM/contexto governado, catálogos, capabilities, provenance e tools declaradas. Keywords, aliases, normalização e fuzzy matching podem ranquear candidatos somente depois que o escopo semântico foi resolvido. ### 5.3 Canonical decision Políticas reutilizáveis, eligibility, validação, approval e compliance pertencem ao lifecycle de Domain Rules. O intake cria definição governada; simulation diagnostica cobertura, materializações previstas, aprovações e readiness; ela não executa a condição contra registros de negócio. ### 5.4 Governance and publication Definitions passam por transições autorizadas. Publication exige definição persistida e aprovada/ativa. Materializações preservam target, stable key, source hash, validação e outcomes. Collisions ou source drift falham em vez de sobrescrever silenciosamente. ### 5.5 Runtime snapshots Snapshots de RuleSet são imutáveis. Composition manifest, provenance, source approvals e dois composition approvers independentes precedem publication. Initial head usa `If-None-Match: *`; publicações e rollback posteriores usam strong `If-Match`. Content hash e head ETag são distintos para impedir ABA. O host consumidor ainda compila e ativa atomicamente com seu registry executável. ### 5.6 Derived materializations Decisões aprovadas podem materializar `option_source`, `backend_validation`, `workflow_action` e `approval_policy`. O consumidor não vira owner da regra. Targets apenas previstos não devem ser anunciados como persistidos; verifique outcomes e readback. ### 5.7 Runtime observation and explanation Authoring manifest declara operações e boundaries. Execução, state safety, runtime observation e explanation exigem evidência adicional. Uma mensagem de sucesso do assistente não é prova suficiente sem outcome observável aplicável. ## 6. Capability Catalog ### metadata.structural-schema - Canonical owners: `praxis-metadata-starter` - Role: `semantic-grounding` - Evidence class: `publicly_proved` - Summary: Publishes the operation-aware structural schema, x-ui vocabulary, ETag and X-Schema-Hash used for runtime grounding and reconciliation. - Consumers: `praxis-ui-angular`, `praxis-config-starter`, `praxis-api-quickstart` Surfaces: - `/schemas/filtered` Evidence links: - None declared. Caveats: - The structural schema is canonical; aggregated capabilities do not replace it. --- ### metadata.semantic-discovery - Canonical owners: `praxis-metadata-starter` - Role: `semantic-grounding` - Evidence class: `publicly_proved` - Summary: Publishes documentary discovery, semantic surfaces, workflow actions and contextual availability snapshots. - Consumers: `praxis-ui-angular`, `praxis-config-starter`, `praxis-api-quickstart` Surfaces: - `/schemas/catalog` - `/schemas/surfaces` - `/schemas/actions` - `/{resource}/capabilities` - `/{resource}/{id}/capabilities` Evidence links: - None declared. Caveats: - Availability is contextual and must not be inferred from route or method names. --- ### metadata.resource-query-and-analytics - Canonical owners: `praxis-metadata-starter` - Role: `operational-capability` - Evidence class: `publicly_proved` - Summary: Provides the resource-oriented query, cursor, locate, statistics and export baseline consumed by operational materializers. - Consumers: `praxis-ui-angular`, `praxis-api-quickstart` Surfaces: - `/{resource}/filter` - `/{resource}/filter/cursor` - `/{resource}/locate` - `/{resource}/stats/*` - `/{resource}/export` Evidence links: - None declared. Caveats: - Concrete availability depends on the resource contract and published capabilities. --- ### metadata.governed-option-sources - Canonical owners: `praxis-metadata-starter` - Role: `semantic-grounding` - Evidence class: `publicly_proved` - Summary: Resolves named option sources with governed filtering and selected-value rehydration. - Consumers: `praxis-ui-angular`, `praxis-config-starter`, `praxis-api-quickstart` Surfaces: - `/api//option-sources/{sourceKey}/options/filter` - `/api//option-sources/{sourceKey}/options/by-ids` Evidence links: - Operational HTTP: `procurement-suppliers-governed-domain-rules-lookup` Caveats: - Do not infer RESOURCE_ENTITY semantics from a lightweight OptionDTO response. --- ### config.domain-catalog - Canonical owners: `praxis-config-starter` - Role: `semantic-grounding` - Evidence class: `confirmed_today` - Summary: Persists immutable producer releases and projects governed domain context, relationships, visibility and RAG status for AI grounding. - Consumers: `praxis-ui-angular`, `praxis-api-quickstart` Surfaces: - `/api/praxis/config/domain-catalog/**` Evidence links: - None declared. Caveats: - Domain Catalog provides meaning and grounding; it does not execute final business rules. --- ### config.domain-federation - Canonical owners: `praxis-config-starter` - Role: `semantic-grounding` - Evidence class: `confirmed_today` - Summary: Builds a validated LLM-safe read model over accepted domain releases with explicit candidate ingestion and activation. - Consumers: `praxis-config-starter` Surfaces: - `/api/praxis/config/domain-federation/context` - `/api/praxis/config/domain-federation/dry-run` - `/api/praxis/config/domain-federation/ingest` - `/api/praxis/config/domain-federation/releases/**` Evidence links: - None declared. Caveats: - No repeatable public operational proof is currently linked from this index. --- ### config.domain-knowledge - Canonical owners: `praxis-config-starter` - Role: `governed-knowledge` - Evidence class: `confirmed_today` - Summary: Governs versioned semantic knowledge change sets, validation, review, apply, evidence lifecycle and derived Project Knowledge indexing. - Consumers: `praxis-ui-angular`, `praxis-api-quickstart` Surfaces: - `/api/praxis/config/domain-knowledge/change-sets/**` Evidence links: - Protected contract HTTP: `domain-knowledge-change-set-timeline` Caveats: - The validator recognizes several operation types, but the current apply service executes only add_evidence and revert_evidence. --- ### config.domain-rule-lifecycle - Canonical owners: `praxis-config-starter` - Role: `governed-decision` - Evidence class: `publicly_proved` - Summary: Owns reusable rule intent, structural simulation, approval, publication, explainability, timelines and derived materializations independently from UI components. - Consumers: `praxis-ui-angular`, `praxis-api-quickstart` Surfaces: - `/api/praxis/config/domain-rules/intake` - `/api/praxis/config/domain-rules/definitions/**` - `/api/praxis/config/domain-rules/simulations` - `/api/praxis/config/domain-rules/publications` - `/api/praxis/config/domain-rules/materializations/**` Evidence links: - Operational HTTP: `procurement-suppliers-governed-domain-rules-lookup` - Protected contract HTTP: `domain-rules-supplier-eligibility-intake` - Protected contract HTTP: `domain-rules-supplier-eligibility-simulation` - Protected contract HTTP: `domain-rules-supplier-eligibility-definition` - Protected contract HTTP: `domain-rules-supplier-eligibility-approve` - Protected contract HTTP: `domain-rules-supplier-eligibility-publication` - Protected contract HTTP: `domain-rules-supplier-eligibility-materializations` Caveats: - Simulation reports coverage and publication readiness; it does not evaluate the condition against business records. - Write examples remain protectedContract and are not safe-first LLM operations. - The direct supplier materialization read remains reference-only until the published backend confirms its committed fixture; use the governed supplier lookup as operational runtime evidence. --- ### config.domain-rule-materializations - Canonical owners: `praxis-config-starter` - Role: `decision-materialization` - Evidence class: `local_authenticated_proof` - Summary: Projects approved domain decisions into runtime/backend artifacts without transferring rule ownership to those consumers. - Consumers: `praxis-metadata-starter`, `praxis-ui-angular`, `praxis-api-quickstart` Surfaces: - `option_source/resource-option-source` - `backend_validation/resource-validation` - `workflow_action/resource-workflow-action` - `approval_policy/resource-action-approval` Evidence links: - Evidence: `runtime-enforcement-consumer-local-proof-2026-05-02` Caveats: - option_source has published read-only proof; backend_validation, workflow_action and approval_policy currently have local authenticated proof. --- ### config.domain-rule-snapshots - Canonical owners: `praxis-config-starter` - Role: `decision-control-plane` - Evidence class: `confirmed_today` - Summary: Persists immutable RuleSet snapshots, composition approvals, active heads, strong concurrency validators, events and rollback without executing host Java rules. - Consumers: `praxis-api-quickstart` Surfaces: - `/api/praxis/config/domain-rules/snapshots/composition-manifest` - `/api/praxis/config/domain-rules/snapshots/composition-approvals` - `/api/praxis/config/domain-rules/snapshots` - `/api/praxis/config/domain-rules/snapshots/head` - `/api/praxis/config/domain-rules/snapshots/{snapshotKey}` - `/api/praxis/config/domain-rules/snapshots/{snapshotKey}/rollback` Evidence links: - None declared. Caveats: - Publication requires approved source provenance and two distinct composition approvers. - The host must compile and activate snapshots with its executable registry. - No public operational proof is currently linked from this index. --- ### ai.semantic-intent-and-tools - Canonical owners: `praxis-config-starter` - Role: `semantic-intent-resolution` - Evidence class: `confirmed_today` - Summary: Resolves authoring intent semantically from governed context, catalogs, capabilities and declared tools, failing closed on incomplete or weak evidence. - Consumers: `praxis-ui-angular`, `praxis-api-quickstart` Surfaces: - `agentic-authoring fast/full LLM intent resolution` - `pre-intent tool planning` - `governed candidate provenance` Evidence links: - Evidence: `governed-domain-context-llm-authoring-local-proof-2026-04-26` Caveats: - Keywords, aliases and fuzzy matching may rank already-scoped candidates but must not decide primary intent. --- ### ai.shared-rule-handoff - Canonical owners: `praxis-config-starter` - Role: `governed-authoring-routing` - Evidence class: `confirmed_today` - Summary: Routes reusable policy, eligibility, validation, approval and compliance intent to the governed Domain Rule lifecycle instead of fabricating a component preview. - Consumers: `praxis-ui-angular` Surfaces: - `route_shared_rule_authoring` - `shared-rule-authoring-required` Evidence links: - None declared. Caveats: - canApply remains false until a governed decision/materialization contract exists. --- ### angular.authoring-manifests - Canonical owners: `praxis-ui-angular` - Role: `runtime-authoring-contract` - Evidence class: `confirmed_today` - Summary: Declares component operations, targets, validation and authoring boundaries across the official Angular materializers. - Consumers: `praxis-config-starter`, `praxis-ui-angular` Surfaces: - `@praxisui/* authoring manifests` - `agentic component turn flows` Evidence links: - None declared. Caveats: - Manifest presence proves declaration, not complete execution, observation or platform certification. --- ### angular.runtime-observations - Canonical owners: `praxis-ui-angular` - Role: `runtime-evidence` - Evidence class: `confirmed_today` - Summary: Projects runtime state and outcome evidence so assistant success and explanation can be grounded in observed materialization. - Consumers: `praxis-config-starter`, `praxis-ui-angular` Surfaces: - `runtime observation contracts` - `component state and outcome evidence` Evidence links: - None declared. Caveats: - Observation coverage varies by operation and component; do not infer platform-wide certification. --- ### evidence.http-corpus - Canonical owners: `praxisui-http-examples` - Role: `published-operational-evidence` - Evidence class: `publicly_proved` - Summary: Classifies executable examples as llmOperational, protectedContract or referenceOnly and records published-backend confirmation. - Consumers: `praxis-ui-landing-page` Surfaces: - `examples.manifest.json` - `LLM_BOOTSTRAP.md` - `LLM_SURFACE.md` Evidence links: - None declared. Caveats: - The corpus is a derived evidence surface and never overrides canonical starter contracts. --- ### ai.generative-ui-machine-first - Canonical owners: `praxis-config-starter`, `praxis-ui-angular` - Role: `platform-certification-direction` - Evidence class: `architectural_direction` - Summary: Defines a machine-first certification direction connecting public capabilities, semantic selection, deterministic execution, runtime observation and explanation. - Consumers: `praxis-ui-landing-page` Surfaces: - `capability coverage model` - `component certification levels C0-C8` Evidence links: - None declared. Caveats: - Phase 0 is complete and Phase 1 is the active inventory milestone; broad Generative UI readiness is not currently a shipped claim. ## 7. Canonical Contract Index - `/schemas/filtered` — `canonical-structural-contract`; owner `praxis-metadata-starter` - `/schemas/catalog` — `canonical-documentary-discovery`; owner `praxis-metadata-starter` - `/schemas/surfaces` — `canonical-semantic-discovery`; owner `praxis-metadata-starter` - `/schemas/actions` — `canonical-semantic-discovery`; owner `praxis-metadata-starter` - `/{resource}/capabilities` — `aggregated-snapshot`; owner `praxis-metadata-starter` - `/api//option-sources/{sourceKey}/options/filter` — `governed-option-source-filter`; owner `praxis-metadata-starter` - Notes: Use for RESOURCE_ENTITY, LIGHT_LOOKUP and other named option sources. Do not model governed entity lookup against the generic /options/filter endpoint. - `/api//option-sources/{sourceKey}/options/by-ids` — `governed-option-source-rehydration`; owner `praxis-metadata-starter` - Notes: Required for reopening persisted IDs with labels, status, disabled reason and rich metadata where applicable. - `/api/praxis/config/ui` — `protected-contract`; owner `praxis-config-starter` - `/api/praxis/config/domain-catalog/**` — `canonical-semantic-grounding`; owner `praxis-config-starter` - `/api/praxis/config/domain-federation/**` — `canonical-federated-grounding`; owner `praxis-config-starter` - `/api/praxis/config/domain-knowledge/change-sets/**` — `canonical-governed-knowledge`; owner `praxis-config-starter` - `/api/praxis/config/domain-rules/**` — `canonical-governed-decision`; owner `praxis-config-starter` - `/api/praxis/config/domain-rules/snapshots/**` — `canonical-decision-control-plane`; owner `praxis-config-starter` ## 8. Current Evidence ### governed-domain-context-llm-authoring-local-proof-2026-04-26 - Class: `confirmed_today` - Scope: `local-managed-postgresql-llm-and-ci` - Canonical owners: `praxis-config-starter` - Evidence repositories: `praxis-config-starter`, `praxis-api-quickstart` - Summary: praxis-config-starter projects domain-catalog/context into contextBundle.governedDomainContext before LLM planning, and praxis-api-quickstart gates intent-resolution with REQUIRE_GOVERNED_CONTEXT=true. - Caveat: Not yet classified as publicly_proved because this cut was not published to Maven Central or redeployed to the remote quickstart. ### runtime-enforcement-consumer-local-proof-2026-05-02 - Class: `local_authenticated_proof` - Scope: `local-managed-postgresql-quickstart-and-browser` - Canonical owners: `praxis-config-starter` - Evidence repositories: `praxis-config-starter`, `praxis-api-quickstart`, `praxis-ui-angular` - Summary: Focused local lanes prove form_config browser consumption plus backend_validation, workflow_action, and approval_policy runtime blocking with 409 Conflict while domain-rules remains the canonical decision source. - Caveat: Classify as local_authenticated_proof, not publicly_proved, until a safe public read-only evidence surface or hosted smoke exists. - Public guide: `/guides/runtime-enforcement-consumer` ## 9. Canonical End-to-End Proof ### employee-operations-casework - Enterprise proof: `/enterprise-proof` - Public runtime: `/examples/dynamic-page/employee-operations-casework` - Machine catalog: `/examples/dynamic-page.json` - Recipe: https://github.com/codexrodrigues/praxis-ui-angular/blob/main/examples/ai-recipes/praxis-dynamic-page.employee-operations-casework.json Demonstrates: - semantic backend grounding - metadata-driven backend contract - praxis-dynamic-page runtime composition - published quickstart API - state-aware employee lifecycle actions - rich CRUD portfolio and governed drawer forms - tabbed employee dossier with payroll and equipment related resources - opaque concurrency tokens and governed refresh - canonical public end-to-end proof for current enterprise narrative - LLM-safe operational evidence Operational HTTP evidence: - `schemas-surfaces-human-resources-funcionarios` - `funcionarios-filter-basic` - `employee-state-snapshot-actions` - `employee-equipment-custody-surface` - `employee-payroll-history-related-resource` Use a prova comercial/runtime para explicar composição e resultado visual. Use IDs `llmOperational` com `publishedBackendConfirmed=true` para afirmar disponibilidade pública. Use IDs `protectedContract` somente para explicar contratos e lifecycles protegidos. ## 10. Governed Option Sources ### RESOURCE_ENTITY - Use when: The selected value is a real business entity with canonical identity, lifecycle, status, selection policy, dependency semantics, rich display, by-ids rehydration or detail navigation. - Quickstart sources: `employee`, `payroll`, `base`, `team`, `agreement`, `mission`, `incident`, `vehicle`, `equipment`, `threat`, `company`, `supplier`, `contract`, `product` ### LIGHT_LOOKUP - Use when: The value comes from a lightweight reusable catalog that needs named filtering and by-ids rehydration but only returns OptionDTO{id,label}. - Quickstart sources: `jobRole`, `department`, `skill` - Publication caveat: When HTTP examples remain referenceOnly with publishedBackendConfirmed=false and illustrative-only status, treat them as contract guidance rather than published runtime proof. ### DISTINCT_DIMENSION - Use when: The option list is an analytic dimension derived from a view, aggregation, or read model. - Quickstart sources: `payrollProfile` Anti-pattern: - Do not point entityLookup at /{resource}/options/filter when the field represents a governed business entity; use /option-sources/{sourceKey}/options/filter plus /by-ids. ## 11. Naming and Persistence - `/api/praxis/config/ui.componentType`: Angular selector. - `/api/praxis/config/ui.componentId`: stable persistence key. - AI context warning: Do not extrapolate uiConfig naming rules into ai-context without checking runtime behavior. - Explicit runtime state in an edit/patch request has precedence over persisted state for that operation. Persisted config remains initial hydration, not authority over explicit current state. - ETag/304 requires a matching local cached representation. A `304` without usable cache is not a complete load. ## 12. AI Routing and Safety - Consultative questions remain read-only; do not fabricate patches. - Local UI requests may use component authoring only after semantic scope and manifest operation are resolved. - Shared policy/rule intent must hand off with `shared-rule-authoring-required`; keep `canApply=false` until governed materialization exists. - Clarification labels and quick-reply display text are not executable semantics; preserve structured semantic payloads. - Provider failures, incomplete LLM JSON and low confidence fail closed with clarification/provider error and sanitized diagnostics. - Do not expose provider bodies, keys, secrets, stack traces, private evidence or raw prompts as governance evidence. - HTML, URLs and rich content remain subject to runtime sanitization and host policy. ## 13. Troubleshooting Matrix ### Structural schema missing or incomplete - Check the canonical operation and `/schemas/filtered` before adding frontend overrides. - Verify request/response schema selection, resource identity, ETag and `X-Schema-Hash`. - Treat a host override as temporary fallback, not canonical repair. ### Capability or action appears unavailable - Check contextual `/{resource}/capabilities`, surfaces/actions and instance scope. - Do not infer availability from route names, HTTP verbs or UI labels. ### 304 without usable data - Verify the client has a cached representation for the same validator and scope. - Retry without the validator only as a controlled cache recovery path. ### Config saved in the wrong scope - Check tenant, environment, user, `componentType`, `componentId`, headers and ETag. - Do not copy naming rules from `/ui` into AI context without checking that contract. ### Patch 409 or 422 - `409` normally indicates concurrency/schema/current-state conflict; re-read and reconcile. - `422` indicates semantic/validation rejection; inspect allowed paths, manifest operation and diagnostics. - Do not weaken the contract or bypass governance to force apply. ### Stream 404 or 410 - Verify turn/stream identity, lifecycle and retention. - Do not reconstruct a missing turn from UI text or stale client state. ### AI context empty or stale - Check Domain Catalog release, visibility, tenant/environment, resource grounding and provider status. - Missing projection is unresolved grounding, not proof that the capability does not exist. ### Shared rule was routed to component preview - Treat this as routing drift. The correct path is Domain Rule intake, simulation, review and publication. - Do not recover with keyword matching or a local form/table patch. ### Simulation reported pass - Interpret it as structural coverage/publication readiness, not evaluation over business records. ### Predicted materialization is missing - Inspect persisted materializations and publication outcome diagnostics. - Prediction alone does not prove persistence or runtime consumption. ### Snapshot publication or rollback conflicts - Use the current strong head ETag, verify composition approvals/provenance and preserve immutable versions. - Do not reuse a RuleSet version for changed content or use last-write-wins. ### Option source loses labels or policy - Use named `/option-sources/{sourceKey}/options/filter` plus `/by-ids`. - Verify descriptor/provider ownership, dependency mapping and selected-value rehydration. ### Manifest exists but behavior is absent - Manifest presence is declaration only. Check resolver, validator, handler, state transitions, runtime observer and tests. ## 14. Specialized Documentation Routes - Short orientation: `/llms.txt` - Machine capability index: `/llm-index.json` - Assistant answer benchmark: `/llm-benchmark.json` - Human source-of-truth: `/llm-source-of-truth` - Markdown source-of-truth: `/llm-source-of-truth.md` - Operational evidence: `/llm-operational-evidence` - Markdown operational evidence: `/llm-operational-evidence.md` - Host business grounding: `/guides/ai-host-business-grounding` - Runtime enforcement consumer: `/guides/runtime-enforcement-consumer` - Governed rule timeline: `/guides/domain-rules-governed-timeline` - Component docs: `/docs/components` - Backend docs: `/docs/backend` - AI docs: `/docs/ai` - Dynamic Page catalog: `/examples/dynamic-page.json` - HTTP safe-first lane: `https://github.com/codexrodrigues/praxisui-http-examples/blob/main/LLM_BOOTSTRAP.md` ## 15. Final Operational Rules - Start from semantic owner and evidence class, not from analogy or keywords. - Use the machine index for capability/surface/consumer lookup. - Use this expanded file for lifecycle, boundaries and troubleshooting. - Use owner docs for deep component or backend API detail. - Use the HTTP corpus for published availability. - Keep protected writes protected. - Keep partial support and architectural direction explicitly classified. - When sources disagree, fix the owner or report drift; do not institutionalize the Landing as a parallel truth.