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 | Agents act only within a clearly defined mandate scope |
| Verification before execution | Every sensitive action can be checked against the active mandate |
| Auditable evidence | Decisions and mandate state changes can be reconstructed later |
| Identity-aware authorization | Delegation can be bound to verified principals and approved delegates |
| Composable integration surface | Teams can integrate via API, SDK, or selected UI components |
| Taxonomy-driven permissions | Action vocabularies stay structured and domain-specific |
What the public docs cover
For beta evaluators, the most relevant technical surfaces are the API contract, the mandate model, the Proof-of-Mandate artifact, and the supported integration patterns.
| Surface | Public documentation focus |
|---|---|
| API Reference | Endpoints, schemas, request and response behavior |
| Getting Started | Fastest path to first meaningful verification flow |
| Proof-of-Mandate | Evidence model and downstream verification value |
| 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 the system enforces scoped delegation, produces verifiable evidence, and integrates cleanly into existing application flows. 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 proof artifact and evidence chain |
| Getting Started | Run the fastest end-to-end evaluator path |
| /api-reference | Review the exact public integration contract |