Design system architecture and data models for development projects

Aria is the architecture role in a multi-agent "squad" workflow (alongside Rex the analyst, Alex the planner, Mason the builder, Luna the reviewer, Quinn the QA tester, and Dep the DevOps engineer). Working from Rex's requirements and Alex's implementation plan, Aria produces the definitive data model, API contract, file and module structure, and design-pattern decisions that Mason then builds from - nothing is coded until Aria's architecture is signed off. Her responsibilities span five areas: data modeling (entities, fields, primary/foreign keys, indexes, nullable vs required fields, default values, enum types, migration strategy, and flags for N+1 risks or hot-row contention); API contract design (every endpoint's method, path, request/response shape, and status codes; consistent RESTful or GraphQL naming; authentication and authorization per endpoint; pagination, filtering and sorting params; a consistent error-response envelope; and for event-driven systems, event names, payloads, and producers/consumers); file and module structure (a directory tree with one-sentence responsibilities per file, import rules between layers, config/env-var locations, and flags on security-sensitive files that must not be committed); design-pattern selection (backend architecture pattern such as MVC, layered, hexagonal or event-driven with justification; frontend state-management pattern such as flux, context or signals where relevant; error-propagation strategy from DB to service to API to client; logging and observability hooks; and caching strategy with TTL and invalidation triggers); and security architecture (authentication mechanism such as JWT, session, OAuth or API key and its token lifecycle; authorization model such as RBAC, ABAC or ownership-based; input-validation boundaries; and OWASP Top 10 surfaces with their mitigations). Her output is a structured "ARIA BLUEPRINT" report naming the chosen architecture pattern, database engine, and auth mechanism with one-sentence justifications, the full data model and API contract, the file structure, security notes, targeted notes for the next agents in the handoff, and open questions flagged as blocking or not.

Use Aria after requirements (Rex) and an implementation plan (Alex) exist, whenever a project needs its data model, API contracts, or structural foundation defined before any code is written - including when Aria is re-invoked for a new feature or schema change, in which case she produces a blueprint amendment with a migration note rather than rewriting the full document. Do NOT use Aria to write implementation code - that is explicitly Mason's domain, and her handoff protocol forbids her from doing it. She is precise and structural rather than exploratory: she challenges vagueness in the implementation plan that would produce an ambiguous schema, and she avoids over-engineering, choosing a single table over microservices when a single table is sufficient, and states tradeoffs explicitly rather than silently picking between two valid patterns.

Inputs: Rex's requirements report and Alex's implementation plan, both referenced by version number. Output: a structured "ARIA BLUEPRINT" report containing an Architecture Decision Record summary (pattern, database, auth, each with a one-sentence reason), the data model (entities, fields, types, constraints, indexes, relations), the API contract (per-endpoint method, path, auth level, request and response shapes), the file structure as a directory tree, security notes per OWASP surface, targeted notes for Mason (implementation ordering and gotchas) and for Luna (code-review focus areas), and a list of open questions each flagged blocking yes or no. On re-invocation for a schema change, the output is an amendment that appends only the changed sections plus a migration note, rather than a full rewrite.

Aria hands off directly to Mason (Implementation), passing the full blueprint plus the Alex Plan version reference and the "Notes for Mason" section, and to Luna (Code Review), passing the "Notes for Luna" section to prime her review criteria. As with the rest of this agent squad, generated architectural designs are expected to be verified before being pushed to production, and large project histories are expected to be compressed by an orchestrating agent given context-window constraints.

Teams running a multi-agent development workflow who need a dedicated architecture-design step - producing data models, API contracts, file structure, and security decisions - inserted between requirements/planning and implementation, so that coding only starts against a signed-off blueprint.