Platform Design Principles
During the beta phase, the public documentation intentionally focuses on integration behavior, trust guarantees, and evaluator outcomes rather than publishing detailed internal infrastructure diagrams. That keeps the docs useful for implementers without overexposing operational internals that are still evolving.
Mandaitor is designed around a small number of principles that matter directly to integrators.
| Principle | Why it matters to integrators |
|---|---|
| Explicit delegation | An agent acts only within a mandate a person stands behind |
| Mandaitor performs the write | The agent asks; it never holds the target system's credential, so it cannot act on its own |
| Decisions on the record | Amounts and sites are read from the target system, never taken from the agent |
| Approval bound to the request | A person approves exactly the request they are shown; a change to the record voids the approval |
| Auditable evidence | Each write is made on a signed Proof-of-Mandate, and the outcome a read-back establishes gets a signed receipt, both on a hash-chained audit trail |
| Identity-aware authorization | Agents authenticate with their own keys; approvers with their own sessions |
| Composable integration surface | Agents connect through the execution API or any MCP client; people work in the dashboard |
| Taxonomy-driven permissions | Mandates name business actions, never vendor APIs, so one mandate covers every system Mandaitor has a tool for |
What the public docs cover
For beta evaluators, the most relevant technical surfaces are the API contract, the mandate model, the execution path with its evidence, and the supported integration patterns.
| Surface | Public documentation focus |
|---|---|
| API Reference | Endpoints, schemas, request and response behavior |
| Getting Started | The fastest path from a mandate to a first execution and its receipt |
| Executions and MCP Server | How an agent asks, how Mandaitor decides and writes, and what each state means |
| Proof-of-Mandate | The authorization proof and the receipt, and how to check them |
| React Integration | Embeddable UI components for selected delegation flows |
| Identity Integration | Supported identity providers and current beta boundaries |
Why there is no detailed public system diagram here
A detailed infrastructure graph is not required for most evaluators to assess Mandaitor. For beta, the more important questions are whether it acts only within the mandate, produces verifiable evidence of each write, and integrates cleanly into existing agents and systems. Those aspects are documented elsewhere in a more useful form.
If a design partner or evaluator needs a deeper technical review, that discussion is better handled directly and in context rather than through a static public architecture page.
Recommended next reads
| Document | Why to read it next |
|---|---|
| Core Concepts | Understand the delegation model and object vocabulary |
| Proof-of-Mandate | Inspect the authorization proof, the receipt and the evidence chain |
| Getting Started | Run the fastest end-to-end evaluator path |
| Executions | The full execution contract: setup, states, approvals and receipts |
| /api-reference | Review the exact public integration contract |