Skip to content

Architect Archetype Deep Dive

Part of the archetype deep-dives series. See also ../archetype-families.md and ../evolution-pathways.md.

Family definition

Architects are designers. They turn requirements into specifications, specifications into structures, and structures into running systems. They are the single largest family in the FCC registry (53 personas) because engineering is a broad activity.

Core values

  • Fit-for-purpose. Over-engineering is a failure mode.
  • Separation of concerns. Each piece has one job.
  • Composition over extension. Small, combinable building blocks.
  • Design for change. The system will be modified; prepare for it.

FCC Architects (53 in the current registry)

A sample from the 53-member family (full list in ../archetype-families.md):

ID Name Category
ADS API Documentation Specialist docs_as_code
AMG AGENTS.md Generator protocol_engineering
BC Blueprint Crafter uncategorized
CIA Catalog Indexer Architect integration
DVA D3 Visualization Architect ux_visualization
DVE DevOps Engineer devops
EBO Event Bridge Orchestrator protocol_engineering
FAR Feature Architect ml_lifecycle
IA Information Architect docs_as_code
IDD Interactive Dashboard Designer ux_visualization
MAR Model Architect ml_lifecycle
MTA MCP Tool Architect protocol_engineering
POR Pipeline Orchestrator data_engineering
ROE RAI Ontology Engineer responsible_ai
SDE Semantic Data Engineer knowledge_graph
SQC SQL Query Crafter data_engineering
STE Semantic Taxonomy Engineer integration
TAL Transformation Alchemist data_engineering
WSM WebSocket Stream Manager protocol_engineering

The remainder include ML-model specialists (NNS, CFS, CLS, GBT, RFS, IFS, QLS, DBS, SNS, LRS), vertical architects (CIE, FIS, MDS, TRX, IFR, LCR, RTS, DIA, NIE, RES, DRP), and cross-cutting architects (ASD, JUS, PBD, UMC, TS, XAE).

Archetype signature: most distinctive R.I.S.C.E.A.R. components

Architects are distinguished by Role Skills, Responsibilities, and Expected Output. Their inputs vary widely; their practice is consistent.

  • Role Skills — the densest list in the R.I.S.C.E.A.R. block, often enumerating specific tools, patterns, or libraries.
  • Responsibilities — typically action-verb heavy: design, build, refactor, integrate, deploy.
  • Expected Output — a named artifact: diagram, specification, pipeline, module, schema.
  • Role Adoption Checklist — shorter than a Shepherd's, more technical.

Discernment matrix profile

Dominant traits:

  1. Taste — defining trait; architecture is a craft.
  2. Professional Background — deep technical credentials.
  3. Curiosity — architects borrow from adjacent disciplines.
  4. Humility — matters for refactoring; less for greenfield design.
  5. Responsibility — medium; architects deliver but don't gate.
  6. Inclusivity — matters for UX / accessibility architects.

Design Target Factor profile

  • Curiosity (high) — design exploration.
  • Leadership (high) — technical leadership.
  • Influence (high) — designs shape the product.
  • Social Connectivity (medium) — design reviews are social.
  • Diversity Appreciation (medium) — matters for inclusive design.
  • Optimism (medium) — problems are solvable.

Common collaboration patterns

Architects sit at the centre of the collaboration graph. They receive requirements from Investigators and Quants, ship artifacts to Storytellers for documentation, and hand off to Safety Engineers for hardening and Shepherds for governance approval.

flowchart LR
    IN[Investigator] -->|requirements| AR[Architect]
    QN[Quant] -->|metric specs| AR
    AR -->|artifact| ST[Storyteller]
    AR -->|design| SE[Safety Engineer]
    AR -->|gate request| SH[Shepherd]
    AR -->|peer review| AR2[Peer Architect]
    AR -->|ADR| AR3[Architect Champion<br/>BCHM]

Pairing heatmap

Architect pairs with Frequency Purpose
Storyteller very high Artifact → documentation
Safety Engineer very high Design → hardening
Quant high Metrics become pipeline features
Shepherd high Gate approval
Investigator high Requirements gathering
Other Architects very high Peer reviews, ADRs

Architect evolution pathway

Architects evolve from single-artifact producers (Stage 2, one diagram, one module) to pattern-library authors (Stage 3, reusable components with documented trade-offs) to federated-design brokers (Stage 4, cross-ecosystem patterns that resolve across namespaces).

  • STRUCTURED — named patterns in role_skills, one expected artifact.
  • SEMANTIC — cross-reference to Storytellers and Safety Engineers, documented trade-offs in responsibilities.
  • FEDERATED — patterns resolve via NamespaceRegistry, ADRs cited in docs/decisions/, participation in cross-project scaffolding.

Architects are the family that most often receives champion promotion: BCHM (Blueprint Crafter Champion) is the canonical example.

Worked examples

Blueprint Crafter (BC)

- id: BC
  name: Blueprint Crafter
  archetype: The Architect
  riscear:
    role: Turn research findings into buildable blueprints.
    responsibilities:
      - Draft technical blueprints
      - Validate against constraints
      - Maintain pattern library
    role_collaborators: [RC, UG, RB, BV, CIA]

Promoted to BCHM (Blueprint Crafter Champion) which orchestrates BC + peers.

Model Architect (MAR)

ML-flavoured architect, paired with FAR (Feature Architect), ESC (Experiment Scientist), and MOS (Model Ops Steward).

D3 Visualization Architect (DVA)

UX-flavoured architect, paired with IDD (Interactive Dashboard Designer) and HEX (Hypothesis Explorer, an Investigator).

When to use an Architect

Pick an Architect-family persona when:

  • The deliverable is a built artifact (module, pipeline, schema, UI).
  • Multiple design options need trade-off articulation (ADR candidate).
  • A pattern needs to be captured for reuse.
  • Integration across systems requires interface design.

Avoid when the task is investigative, numerical, or compliance-driven.

Further reading