Architecture Decision Records

Decisions about how SystemForge behaves, each with its context and consequences. ADRs are long-lived: a later ADR may amend or supersede an earlier one, and says so. Initiative specs (PRD, TRD, PLAN, ROADMAP) live under docs/specs/ and execute these decisions.

ADR	Decision	Status
ADR-001	Core-era Naming Cleanup — SystemAuth, sf_ Prefix, Unified Principal-Link Field	Accepted
ADR-002	Centralized Social Login (GitHub/Google) via SystemAuth	Accepted
ADR-003	Verified Email in SystemAuth, Delivered Through omnimail	Accepted
ADR-004	Retire Legacy User — Principal as the Sole Identity Root	Accepted
ADR-005	Managed Principals and Manager Relationships	Accepted, amended by ADR-009
ADR-006	Organization Lifecycle — Signup, Personal and Team Organizations, Slugs	Accepted
ADR-007	Organization Memberships and Entitlements as Claims	Accepted, amended by ADR-010
ADR-008	Resource-Scoped Collaborators on the Authorization Substrate	Accepted
ADR-009	Management Is a Relationship, Not the Absence of an Email (amends ADR-005)	Accepted
ADR-010	Real-Time Invalidation of Access on Membership Change (amends ADR-007)	Accepted
ADR-011	Lifecycle States, Data Classification and Privacy Rights (amends ADR-009)	Proposed
ADR-012	Data Governance Catalog, Legal Holds and Enforcement	Proposed
ADR-013	Key Management	Proposed
ADR-014	Application Roles and Marketplace Seat Assignments Are Separate Records (amends ADR-007 decision 8)	Proposed
ADR-015	Identifier Policy, Slug Namespaces and Portability Across Deployments	Proposed
ADR-016	No Static API Keys: OAuth Grants for Non-Interactive Access	Proposed
ADR-017	External Connections	Proposed

Statuses

• Proposed: written and under review.
• Accepted: decided; implementation follows or is complete.
• Deferred: recorded so other decisions do not rule it out; not scheduled.
• Superseded: replaced by a later ADR, which it links to.