This directory contains Architecture Decision Records (ADRs) for TrustLink. An ADR captures a significant design choice, the context that drove it, and the trade-offs accepted as a result.
| ADR | Title | Status |
|---|---|---|
| ADR-001 | Deterministic IDs instead of sequential counters | Accepted |
| ADR-002 | Persistent storage instead of temporary storage | Accepted |
| ADR-003 | Immutable attestation history (no delete) | Accepted |
| ADR-004 | Separate issuer and subject indexes | Accepted |
| ADR-005 | Replace imported/bridged Booleans with AttestationOrigin Enum |
Accepted |
| ADR-006 | OR-logic across issuers in has_valid_claim |
Accepted |
| ADR-006 | Multi-Sig Attestation Design | Accepted |
| ADR-007 | Pull-based attestation request workflow (subject-initiated, 7-day TTL, optional rejection reason) | Accepted |
| ADR-008 | Rate limiting design — per-issuer last-issuance timestamp, known limitations | Accepted |
| ADR-009 | Delegation model and trust chain implications | Accepted |
| ADR-010 | Issuer-defined custom validation hooks for attestation creation (cross-contract) | Accepted |
| ADR-011 | GraphQL Schema Versioning and Federation Strategy | Accepted |
| ADR-011 | GraphQL Schema Federation and Versioning Strategy | Accepted |
| ADR-012 | Prevent Admin from Setting Themselves as Fee Collector | Accepted |
Use ADR-000-template.md when recording a new decision.
Each ADR follows this structure:
- Status — Proposed / Accepted / Deprecated / Superseded
- Context — The situation and forces that made a decision necessary
- Decision — What was decided and how it works
- Consequences — Trade-offs, benefits, and known limitations