Platform architecture

How identity, routing, App authority, approved contracts, and documentation fit together.

System boundary

Vision Core is the machine-identity and common-policy plane. CRM, Calendar, Accounting, and future Apps are independent resource authorities. The developer portal publishes approved interfaces; it is not an API gateway and does not grant access.

machine client
    │
    ├─ client credential ──> Vision Core token endpoint
    │                            │
    │                            └─ short-lived, audience-specific JWT
    │
    └─ bearer token ───────> routed App resource server
                                 │
                                 ├─ verify issuer, signature, audience, expiry
                                 ├─ enforce App entitlement and workspace
                                 ├─ enforce operation scope
                                 └─ enforce App-owned record and business rules

App-owned OpenAPI/MCP source
    └─ candidate → human approval → checksum-pinned portal snapshot

Request path

An operator provisions a server-side client for one installation and an allowed set of Apps/scopes.
The client exchanges its credential for a token. The requested scope set cannot exceed the current grant.
Vision issues a short-lived token for one precise audience and App workspace.
The client sends the token to the routed resource server.
The resource server validates cryptographic and contextual claims, then performs its own authorization.
The App returns only records and fields visible within that workspace and permission context.

A token that is valid for one App must not be replayed to another audience. A scope does not override workspace, record, state, retention, or business-rule checks.

Authority boundaries

Concern	Authority
Machine client, credential verifier, rotation, revocation	Vision Core
Token issuer, signing keys, common claim vocabulary	Vision Core
App installation profile, target audience, workspace binding	Vision Core plus App profile
Resource schema and record state	Owning App
Operation scope and record-level decision	Owning App
Cross-App/public field projection	Source App approval plus Vision publication boundary
Public HTTP/MCP promise	Human-approved registry snapshot
Rendered documentation	Generated from the approved snapshot

Environments and availability

The public documentation origin is live. The API contracts are preview contracts with different runtime labels:

Vision Core: acceptance-gated
CRM: restricted
Calendar: restricted
Accounting: not-public

The approved CRM, Calendar, and Accounting contracts declare no direct servers origin. Do not construct an origin from product names. Exact development, staging, sandbox, and production gateway origins remain release inputs.

See runtime status before planning an integration.

Contract publication

The App owns its source manifest and machine-readable interface.
Registry preparation discovers the candidate and calculates its checksum.
Validation rejects broken references, unsupported security, missing required scope declarations, version drift, duplicate interface identity, and stale generated output.
A named human approves the exact candidate and records a reference.
The portal copies and renders the approved artifact.
Source drift after approval is reported; it does not silently change the public promise.
Preview build, production deployment, external verification, and rollback remain separate gates.

Download contracts from the API catalog and inspect reusable models in the schema index.