Overview
Platform concepts
Understand workspaces, grants, scopes, canonical tools, action state and evidence before integrating.
Authorization boundary
An external access token resolves to a grant bound to one registered client, one Fullness user, one workspace, a declared purpose and an exact scope set. It cannot be reused to cross workspace boundaries.
Canonical tools
Fullness maintains one versioned tool catalogue. OpenAPI, MCP and A2A are generated projections of that catalogue and the environment release allow-list. A tool absent from live discovery is unavailable even if it appears in source history or another environment.
Reads, drafts and writes
| Kind | Authority | Idempotency | Approval |
|---|---|---|---|
| Read | actions:read plus data/privacy scopes | Not required | None |
| Draft/write | actions:draft plus data/privacy scopes | Required | Fullness-hosted handoff |
| L5/prohibited | Never externally released | — | Cannot be requested |
Evidence and activity
Every action returns identifiers and an activity URL. Results preserve the canonical tool name, contract version and evidence object so an integration can show where an answer or proposed action came from.
Fail-closed release policy
The deployed service starts from an explicit operation allow-list. An empty allow-list exposes no tools; an unknown or prohibited name prevents startup. A grant then narrows the released set further through scopes and privacy authority.