Owner: Cto Clara · Department: executive

Process: Technical Decision-Making

Process Flow

graph TD
  S0["Purpose"]
  S1["Steps"]
  S0 --> S1
  S2["1. Identify the decision need"]
  S1 --> S2
  S3["2. Gather context"]
  S2 --> S3
  S4["3. Evaluate options"]
  S3 --> S4
  S5["4. Decide"]
  S4 --> S5
  S6["5. Document"]
  S5 --> S6
  S7["6. Communicate"]
  S6 --> S7
  S8["Quality gate"]
  S7 --> S8

Process: Technical Decision-Making

Owner: CTO (Clara) Type: Manual + Agent-assisted Frequency: As needed (triggered by technical questions or proposals)

Purpose

Ensures that all technical decisions are made deliberately, documented consistently, and communicated to affected roles. Prevents ad-hoc or contradictory technical choices.

Steps

1. Identify the decision need

A technical decision is needed when:

  • A new technology, tool, or pattern is proposed
  • Two or more approaches conflict and need arbitration
  • A role asks "what technology should we use for X?"
  • A build priority question arises
  • An existing decision needs to be revisited

Input: Question, proposal, or conflict from any role.

2. Gather context

  • Read company/vision.md for strategic alignment
  • Scan company/decisions/ for related prior decisions
  • Read company/org-chart.md for phase and build order context
  • Consult affected roles for their constraints and preferences
  • Review the design spec if the topic relates to factory design

Output: Contextual understanding of the decision landscape.

3. Evaluate options

For each option, assess:

  • Vision alignment: Does it support the mission?
  • Phase appropriateness: Is it right for now, or premature?
  • Tradeoffs: What does it enable vs. constrain?
  • Consistency: Does it conflict with existing decisions?
  • Simplicity: Is there a simpler approach that achieves the same goal?

Use /tech-direction to structure this analysis when complex.

Output: Tradeoff analysis with clear recommendation.

4. Decide

  • Choose the option that best balances the evaluation criteria
  • If the decision is borderline, default to simplicity and phase-appropriateness
  • If the decision is reversible, bias toward action; if irreversible, bias toward caution

Output: Clear decision statement.

5. Document

  • For formal decisions: Create a TFD record via /infra-decision (scope: technology, architecture, or conventions)
  • For directional guidance: Save to departments/executive/cto-claradecisions/ as a direction document
  • For minor choices: Document in the relevant conversation or commit message

Output: Decision record in the appropriate location.

6. Communicate

  • Notify affected roles of the decision
  • Update any documentation that references the topic
  • If the decision changes a prior direction, mark the old TFD as Superseded

Output: All stakeholders informed, documentation updated.

Quality gate

A technical decision is complete when:

  • It is documented (TFD or direction document)
  • It references the vision alignment
  • Affected roles have been identified
  • No contradictions with existing decisions exist