Architecture Board Charter Template — Scope, Cadence, Decision Rights, and the Governance Log Boundary

When you actually need an Architecture Board

Architecture Boards are an enterprise-shaped pattern. Adopting one prematurely (below ~50 engineers, or fewer than three independently-staffed product teams) is one of the most common architecture-process mistakes: the meeting becomes a tax on the same three senior engineers who would have made the decisions anyway, and the resulting Governance Log entries describe pre-determined outcomes rather than real precedent.

The signals that you actually need one:

• The same architecture question keeps getting answered differently in different rooms. Team A picks Postgres for a new service while Team B is six months into a CockroachDB rollout for the same problem class. No shared forum exists to surface the precedent. This is the load-bearing signal — the Board's primary job is making cross-team precedent visible.
• Cross-team contracts are starting to break. Two teams' API contracts assume incompatible auth models, or two systems' data ownership boundaries overlap. Per-team ADRs can't catch this because each team's directory is local; the Board catches it because every Board-eligible decision surfaces the cross-team interfaces it touches.
• Audit / compliance asks "who approved this." SOC 2 / ISO 27001 / HIPAA / regulated-industry audits routinely sample architecture decisions and ask for evidence of authorized review. Per-team ADRs alone don't satisfy that ask — the auditor wants to see a Board minute. This is the strongest forcing function for the upgrade and the reason most regulated SaaS adopt Boards earlier than their headcount alone would suggest.
• New patterns need promotion to "reusable across teams." When an internal pattern (e.g. a shared event-bus library, a standard idempotency-key convention) graduates from one team's local implementation to org-wide adoption, someone needs to authorize the promotion. The Board is the right venue.

The signals that you do NOT need one:

• Headcount under ~50 engineers. Below this scale, the same people are usually in the room for the decisions anyway. Adding a Board adds latency without precedent value.
• Single product, single team, single stack. If there's nothing crossing team boundaries, there's nothing the Board does that team standups don't.
• "We need more documentation." The Board doesn't write better documentation than the team that owns the decision. If documentation is the gap, fix the ADR practice (see how to document architecture decisions) before adding a forum.

The seven sections of a working charter

Every section below has a "what to write" and a "what to avoid" pairing — the avoid column is where most charters go wrong.

The eight standing roles

Five voting + three non-voting is the working composition for a fifty-to-two-hundred-engineer organization. Larger organizations sometimes split into multiple domain-specific boards (a Data Board, a Platform Board) federated under an Enterprise Architecture Board; the role taxonomy below scales as the per-board membership rather than expanding the Board itself.

• Chair (voting). Single named person, typically the principal engineer or staff engineer with the most cross-team architectural context. Sets the agenda, runs the meeting, has tie-breaker vote. Rotates annually to prevent personality-of-the-Chair becoming the Board's de facto policy. The Chair is NOT the CTO — the CTO has decision authority above the Board (escalation target), not within it.
• Senior Architects (two voting). Two principal-or-staff engineers from different domains (e.g. one from the platform side, one from the product side). Their job is technical depth on incoming proposals; together with the Chair they form the technical review core.
• Security representative (voting). Senior security engineer or CISO delegate. Voting because security veto on architecture decisions is structurally important — the failure mode of a Board where security is non-voting is a decision that ships and immediately accrues a security finding the Board approved.
• Data representative (voting). Senior data engineer or data architect. Voting for the same reason as Security — data ownership boundaries, retention policy, and PII handling are architecture concerns that need first-class authority on the Board, not advisory comment.
• Engineering Manager rotation (non-voting). One EM at a time, rotating quarterly. Non-voting because EMs represent their team's interests and voting would create misaligned incentives (an EM's vote would always lean toward what their team wants). Their job is to surface team-level operational concerns the architects might miss.
• Product representative (non-voting). Senior PM with cross-team scope. Non-voting because product authority is on roadmap, not architecture. Their presence ensures architecture decisions account for product timing and customer commitments.
• Compliance representative (non-voting). Compliance lead, regulatory counsel delegate, or audit lead. Non-voting in normal proceedings; gains effective veto in regulated-industry environments where the compliance team can flag a decision for legal review (which escalates above the Board).
• Secretary (non-voting, optional). Owns minute-writing and Governance Log entry creation. Often the Chair's responsibility in smaller Boards; emerges as a separate role around 200 engineers when minute volume justifies it.

Quorum is 3 of 5 voting members for routine decisions; 4 of 5 for charter amendments and approval-class votes that cross domain boundaries (e.g. a decision touching both security and data needs Security + Data + at least two of Chair/Architects). Sub-quorum meetings can produce advisory output but cannot ratify approval-class decisions.

The decision-rights matrix

The single most important section of the charter. A working matrix names 8-12 categories with explicit class assignments. Below is a template that's worked across multiple SaaS organizations — start from this and adjust per your domain.

Two patterns to recognize. Most categories are Advisory. A working Board has roughly 3-5 categories at Approval, 6-8 at Advisory, 1-2 at Escalated, and an explicit "out of scope" list. If your matrix has more than 6 Approval categories, the Board will become a bottleneck within six months. The split between Advisory and Approval is "does this affect another team or set new precedent." Per-team architectural choices get Advisory; cross-team contracts and pattern promotion get Approval. This is the boundary the charter exists to enforce.

Worked charter — one-page version

A real, copy-paste-and-adjust charter for a 75-engineer SaaS. Three to five paragraphs total — long charters die in PR review. Names are placeholders.

# Architecture Board Charter — Acme Inc.
# v1, ratified 2026-01-15

## Purpose & Scope
The Architecture Board exists to review architecture decisions that affect multiple
teams, set new precedent, or carry audit-defensibility implications. The Board does
NOT review per-team architectural choices that fit existing patterns, code-level
convention questions, or tactical in-flight changes.

## Standing Roles (5 voting / 3 non-voting)
Chair: Sara L. (rotates 2027-01-15). Senior Architects: Jin H. (Platform), Marco V.
(Product). Security: Priya R. Data: Tomás G. Non-voting rotation: EM (quarterly),
Product (Lila K.), Compliance (Kim S.). Quorum: 3 of 5 voting (4 of 5 for charter
amendments and cross-domain Approval decisions).

## Cadence
Monthly synchronous meeting, second Tuesday 14:00-15:30 UTC. Async review queue with
5-business-day SLA via #arch-board Slack and PRs labeled `arch-board`.

## Decision Rights
- Approval (binding): cross-team API contracts, shared library promotion, new datastore
  or cache adoption, PII handling boundary changes, auth model changes, DR posture.
- Advisory (review only): per-team service architecture, library upgrades, operational
  tooling.
- Escalated to CTO: acquisition integration shape, vendor contracts >$500k.
- Out of scope: code-level convention, in-flight tactical changes.

## Input Gates
ADR drafted in /doc/decisions/, two consulted parties named from affected teams,
Context section identifies cross-team boundaries. PR labeled `arch-board` opens the
review window.

## Output Artifacts
(1) Board minute at /governance/board-minutes/YYYY-MM-DD.md (attendance + decision
class + vote + rationale). (2) Governance Log entry at /governance/log/<adr-id>.md
linking the ADR and the minute. (3) ADR Status updated to Accepted (or Trial-Period)
with governance_review_id frontmatter field set.

## Review & Retrospective
Quarterly self-assessment: count decisions ratified without substantive discussion
(rubber-stamp signal). Goal <20%. Charter amended via PR with 4-of-5 voting
majority.

Notice three things. It fits on one page. Charters that run to multiple pages either repeat themselves or hide ambiguity in volume. It names actual people. Charters with only role names (no names) signal that the Board hasn't started yet; ratification day is when names go in. The decision-rights section names categories, not principles. "Significant decisions require approval" is a non-charter; "cross-team API contracts require Approval" is the actual rule.

Input gates — what an ADR needs to reach the Board

The most common pre-meeting failure is an ADR that arrives at the Board agenda without enough preparation. Three gates eliminate ~80% of these.

1. The ADR file exists. Drafted in /doc/decisions/<NNNN>-<slug>.md using the team's standard template (see ADR template for the body shape) before the Board meeting. Verbal-only proposals don't enter the queue. The ADR can be in Status: Proposed — the Board's job is to ratify (or reject, or trial-period) it.
2. Two consulted parties are named. The proposing team has named two engineers from affected teams (or domains) who reviewed the proposal pre-Board and either supported it or filed objections in the PR. This catches the failure mode where the Board hears about cross-team conflicts in the room rather than ahead of time.
3. Cross-team boundaries are explicit in the Context section. The ADR's Context section names which other teams' systems, contracts, or operational surfaces are touched. If the Context is purely local, the ADR shouldn't be at the Board (it's per-team and stays Advisory at most).

Boards that skip the input gates always end up with the Chair re-explaining the decision in the room while the actual technical review happens after the meeting in PR comments — wasting the synchronous slot. Inverting the order (PR review first, Board ratification second) is the working pattern.

The Governance Log boundary — ADR vs Board decision

The relationship to the per-team ADR practice is what most charters under-specify, and the source of most "is this an ADR or a Board decision" confusion.

The boundary is operational, not philosophical:

• Every Board-reviewed decision IS an ADR — written using the team's standard template, in /doc/decisions/. The Board doesn't introduce a separate format.
• Every Board-reviewed ADR additionally has a Governance Log entry. Located at /governance/log/<adr-id>.md (or the equivalent path in your TOGAF Architecture Repository placement), linking the ADR file, the Board minute that ratified it, and the decision class (Approval / Advisory / Escalated).
• The ADR's frontmatter includes governance_review_id — the link back from the ADR to the Board minute. This is what makes the cross-link bidirectional and what auditors test by sampling.
• Most ADRs do NOT have Governance Log entries. Because most ADRs are per-team and never reach the Board. A working ratio is roughly three to five Board-reviewed ADRs per quarter against fifteen to forty total ADRs per quarter for a fifty-engineer organization. Anything above that ratio means the Board is reviewing things it shouldn't.

For organizations on TOGAF specifically, the Governance Log corresponds to the explicit Architecture Repository placement of the same name — see the TOGAF ADR template page for the three placements (Architecture Landscape, Reference Library, Governance Log) and the bar for promotion. Non-TOGAF organizations can use the Governance Log path simply as a flat directory under /governance/log/; the operational shape is identical.

Output artifacts — what the Board produces

Three deliverables per Board-reviewed decision. Without all three, the audit trail breaks.

1. Board minute at /governance/board-minutes/YYYY-MM-DD.md. One file per Board meeting, aggregating all decisions reviewed in that meeting. Each decision section: title, ADR ID, decision class, vote tally (e.g. "Approval — 5/5 voting"), one-paragraph rationale capturing the substantive discussion. The rationale is the load-bearing artifact — votes alone don't survive memory.
2. Governance Log entry at /governance/log/<adr-id>.md. One file per Board-reviewed decision, linking the ADR file and the minute that ratified it. Includes review_date, vote_class, vote_tally, and the link to the originating ADR's frontmatter governance_review_id.
3. ADR Status update in the originating ADR file. Status moves from Proposed to Accepted (or Trial-Period, or back to Proposed with feedback, or Rejected) per the ADR status template. The governance_review_id frontmatter field is set to the Governance Log entry's filename, completing the bidirectional cross-link.

The reason for three artifacts (rather than one consolidated record) is failure-mode resilience. If the Board minute is lost (e.g. file system mishap, repository mistake), the Governance Log entry preserves the decision's existence. If the Governance Log directory is reorganized, the ADR's frontmatter still points back to the Board minute. The redundancy is intentional; an audit trail is only as good as its survival of operational accidents.

Four common failure modes

1. Scope creep. The Board starts reviewing 3-5 decision categories and over six months drifts to reviewing every architectural decision because reviewing more feels like more work. Engineers route around the bottleneck either by skipping the practice entirely or by pre-deciding everything before the meeting (the meeting becomes ratification theater). Mitigation: the quarterly retrospective explicitly asks "are we approving things that didn't need approval" — not "are we missing things." The asymmetry is the point. The cost of approving an unnecessary decision is one rubber-stamp meeting; the cost of bottlenecking is months of decision latency. Charters that don't name this trade-off explicitly always drift toward over-review.
2. Missing decision rights. The charter says "the Board reviews and provides feedback" without specifying whether that feedback is binding. The result is a Board where every decision's class is ambiguous in the room. Teams interpret feedback as advisory; the Board interprets it as approval. Six months later the first cross-team conflict surfaces and nobody can tell whether the Board's earlier review counted as authorization. Mitigation: the decision-rights matrix names categories explicitly and assigns one of three classes to each. No category is unspecified; "this case isn't in the matrix" is itself a Board agenda item to decide which class it belongs in.
3. No quorum hygiene. The Board meets with two voting members present and ratifies decisions anyway because "we couldn't reach the others." Six months later an audit asks how a particular decision was approved and the minute shows two attendees voting where the charter requires three. Mitigation: sub-quorum meetings produce advisory output only; approval-class decisions defer to the next quorum-having meeting or use the async review queue with explicit voting.
4. Personality of the Chair. A long-tenured Chair becomes the de facto Board policy — their preferences shape what gets approved and what doesn't, and the charter becomes irrelevant in practice because everyone reads the Chair instead of the matrix. Mitigation: annual Chair rotation, ratified in the charter. Short Chair tenures keep the matrix as the authoritative document. The same role-rotation pattern applies to the Senior Architect seats; rotating one of two annually keeps domain expertise stable while preventing single-person policy capture.

Three honest signals you've outgrown the Board

Architecture Boards should evolve as the organization scales. Three signals that the original charter no longer fits:

1. Meeting volume is no longer feasible. The monthly meeting has 12+ ADRs queued and the Board can't substantively review more than 4-5 per session. The fix is either to split into domain-specific Boards (Data Board, Platform Board, Product Architecture Board) federated under an Enterprise Architecture Board, or to raise the input-gate bar so fewer ADRs reach the agenda.
2. Cross-Board decisions are accumulating. A decision touches both Data and Platform domains and neither Board feels confident ratifying alone. This is the signal for an Enterprise Architecture Board layered above the domain-specific Boards. Don't bypass — federate.
3. Compliance is asking for finer-grained evidence than minutes provide. SOC 2 Type 2 audits sometimes ask for per-decision evidence chains, including the Slack threads and PR comments leading to the Board ratification. The fix is a stricter Governance Log shape that captures the link graph (ADR + Slack archive link + PR link + Board minute) — not a different forum.

How WhyChose fits in

Most architecture decisions in fifty-to-two-hundred-engineer SaaS organizations are made in chat conversations between architects, engineering managers, and senior product engineers — days or weeks before the formal Board meeting that ratifies them. The Board minute documents the ratification. The actual reasoning happens earlier, in ChatGPT or Claude conversations where the trade-offs were explored and the decision converged. The WhyChose extractor reads chat exports and surfaces decision-shaped exchanges with the trade-offs considered at the time — including the alternatives sections that auditors test by asking "what else did you consider?" Drop the extracted record into /doc/decisions/, the team adds the cross-team Context, the input gates determine whether it reaches the Board agenda, and the Board's review process produces the formal ratification artifacts. The decision-archaeology question — "what conversation produced this ADR" — is answerable because the extracted record carries the original chat snippet as a backlink, even years later when the chat platform has rotated history. Pro tier exports to Notion / Linear / Obsidian; Team tier scopes the shared decision log by Project membership — useful for Boards whose members need access to the originating reasoning without each one running their own export.

Get early access

Related questions

Further reading

• TOGAF ADR template — the enterprise-architecture extension; the Governance Log is one of three Architecture Repository placements with explicit Board-promotion bar.
• Architecture decision record template — the broader head-term reference; Board-reviewed decisions use the same body shape, just with additional frontmatter.
• How to document architecture decisions — the cultural pairing; Boards work only when the underlying ADR practice is healthy.
• When to write an ADR — the threshold question; an ADR reaching the Board is one of the four signals (cross-team) made operational.
• How to update an ADR — the supersession protocol; Board-reviewed ADRs follow the same protocol with the Governance Log entry updated atomically.
• ADR status template — the format pairing; the governance_review_id field is the recommended frontmatter addition for Board-reviewed ADRs.
• The ADR GitHub Action — the CI pairing; add a small additional job to verify Board-specific frontmatter.
• ADR numbering scheme — Board-reviewed ADRs share the per-directory numbering scheme; no separate enterprise-wide sequence.
• ADR storage format comparison — storage placement decisions affect both per-team ADRs and Governance Log entries; the cross-layer dual-surface pattern works for both.
• ADR vs Design Decision Record — Boards review ADRs (architecture-level), not DDRs (design-level).