The engineering architecture review process decision record: why the review model you chose determines your architectural consistency ceiling and your design decision quality surface

A 21-person developer tools startup had been operating for two and a half years without a formal architecture review process. The team was small enough that significant technical decisions were made in Slack, in short video calls between the two or three engineers most affected, or by the technical co-founder who held the architectural context for the system as a whole. New services were built by individual engineers or pairs working on specific product features, with designs shaped by the engineer's preferences and the immediate requirements of the feature. There was an ADR repository with nine documents covering the earliest foundational decisions — database selection, authentication model, deployment infrastructure — but no requirement to add new entries and no process for reviewing designs before implementation.

Over eighteen months, five services were added to the system by four different engineers working on different product areas. An engineering consultant who joined for a three-month engagement to help with a performance optimization reviewed the codebase and identified four distinct caching models across the system: one service used Redis with TTL-based expiration, two used in-process LRU caches with different eviction policies, one used Redis with explicit invalidation on write events, and one used no caching at all but had a documented plan to add Redis with a read-aside pattern. None of the choices were wrong in isolation — each engineer had made a reasonable choice for the specific service they were building. The choices were collectively inconsistent in a way that created operational complexity: the infrastructure team managed two Redis clusters with different configuration models, the monitoring setup was different for each caching approach and none of the monitoring configurations were comprehensive, and the engineers who had implemented each service held different mental models about when caching was appropriate and what failure modes to design for. The consultant's finding was not that any of the choices should have been different but that the organization had no mechanism to notice that the choices were accumulating into a pattern — a pattern that would become more expensive to rationalize as the system grew.

The technical co-founder's response was to schedule an architecture retrospective: a two-hour meeting where the engineers who had built the five services walked through their caching design choices and the team arrived at a shared model they would apply going forward. The retrospective produced a decision: new services would use Redis with TTL-based expiration for read caches and explicit invalidation for write-through caches, with the model documented in a new ADR. The retrospective took three hours of engineering time across seven engineers. The decision to add a sixth service — which had been underway for two months, with the in-progress implementation using the in-process LRU model — required an additional two weeks of rework to migrate to the Redis model before the service could be considered complete. The retrospective produced a documented decision; it did not produce a process that would prevent the same pattern from recurring. Eighteen months later, a new set of services built by engineers who had joined after the retrospective had accumulated a new set of inconsistencies in a different part of the system: four different approaches to inter-service communication, none of them the approach the technical co-founder would have chosen and none of them documented in any ADR.

A 48-person B2B SaaS had introduced a formal RFC process after a cross-team integration failure that caused a two-week production incident. The incident's root cause was a decision made by the data pipeline team to change the serialization format for event payloads from JSON to a compact binary format, without notifying the three downstream services that consumed the events, because the data pipeline team had not known which services consumed their event stream. The RFC process was designed to prevent this: any change with cross-cutting impact required an RFC document that specified the proposed change, the affected components, the migration plan, and the timeline, followed by a two-week comment period during which affected teams could raise concerns. The process was thorough; the template was detailed; the review criteria were explicit. Engineering leadership considered it a significant improvement over the informal process that had preceded it.

Eighteen months into the RFC process, the engineering director commissioned a review of what decisions had actually gone through the process. The review found: 23 RFCs had been submitted in 18 months. The median time from RFC submission to decision was 44 days. Of the RFCs submitted, 19 were infrastructure decisions — new service deployments, dependency updates, configuration changes — and 4 were architectural design decisions. A parallel review of pull request history and Slack archives for the same 18-month period identified 31 additional architectural design decisions that had been made and implemented without going through the RFC process. Engineers, when asked about these decisions in structured 1:1 interviews, gave consistent explanations: the decision needed to be made within a sprint cycle and a 44-day review process was incompatible with that constraint; the decision was made by a team that did not believe it had cross-cutting impact, which the RFC template required them to enumerate before submitting; the engineer making the decision believed the RFC process was for infrastructure changes, not for design decisions within a service. The RFC process was being used for exactly the class of decision it was least needed for — infrastructure changes with clear affected parties and straightforward review — and was being bypassed for the class of decision it was most needed for — architectural design choices whose cross-cutting impacts were not apparent to the team making the choice.

The engineering director's analysis identified three structural causes. First, the review latency was set by the comment period — two weeks minimum — plus the actual time to produce a decision, which added another two to four weeks when the RFC required synchronous discussion or had concerns that required the author to revise the proposal. The latency was not calibrated to review complexity: a trivial infrastructure change and a significant architectural decision both went through the same 44-day median process, which meant trivial changes generated paperwork overhead and significant decisions faced a time constraint that made the official process impractical. Second, the RFC template required the author to enumerate all affected components before submitting, which meant that an engineer who had not yet identified the cross-cutting impacts of their design could not initiate a review without first doing the research that the review process should help them do — the template imposed a prerequisite that only engineers with broad system knowledge could satisfy, which excluded the junior and mid-level engineers whose decisions most needed cross-cutting review. Third, the process produced no collaborative review — the comment period was asynchronous, the feedback was provided as document comments, and the author responded to comments in writing; there was no mechanism for the kind of exploratory conversation where a reviewer raises a concern, the author explains their reasoning, and the reviewer identifies a modification that addresses the concern without requiring a complete proposal revision. The RFC format produced advocacy documents and responded to them with written objections rather than producing the collaborative exploration that improved decision quality.

A 74-person enterprise SaaS had an Architecture Review Board that met monthly. The ARB consisted of the CTO, three principal engineers, and the two engineering directors. Any change with architectural impact — new services, significant new dependencies, cross-team integration designs, changes to core data models — required ARB approval before implementation could begin. The ARB maintained a decision log, reviewed proposals in monthly meetings, and issued written decisions. Engineering leadership considered the ARB a sign of engineering maturity: architectural decisions were reviewed by the most experienced engineers in the organization before implementation, and the decision log provided a record of architectural commitments that new engineers could reference.

A new VP of Engineering joined and spent her first two months reviewing the ARB's operation before proposing changes. She attended three monthly meetings, reviewed the decision log for the past two years, and conducted structured interviews with twelve engineers across six teams about their experience with the architectural review process. The meeting observations: each meeting reviewed four to six proposals in a three-hour session; proposals were presented by the proposing team with a ten-minute summary and ten minutes of Q&A; the ARB members asked questions during the Q&A that often surfaced concerns the proposing team had not addressed; proposals were approved, rejected, or deferred to the following meeting for clarification. Proposals deferred for clarification — about 30% of submissions — waited a full month for the next meeting. The decision log: 47 decisions over two years, covering 38% of the architectural changes that teams had identified as requiring ARB review based on the scope criteria. The remaining 62% had been initiated without ARB review, with teams citing scope uncertainty, timeline constraints, or a belief that the change was below the scope threshold. The team interviews: eleven of twelve engineers described a pattern of two categories of architectural change — those small enough to implement without triggering ARB review, and those large enough that a month-plus wait was unavoidable; the middle category, changes that were significant but not large, was the category that most frequently got implemented without review when timeline pressure made a monthly cadence impractical. Two teams described situations where they had initiated implementation of a change they believed was below the ARB scope threshold, completed 70% of the implementation, and then been informed by a principal engineer that the change was within scope and required ARB review — requiring the team to either stop implementation and wait for the next monthly meeting, or to retrospectively present a completed design to an ARB that could technically reject the implementation of work that was nearly done. The retroactive review had a predictable outcome: no proposal that was 70% implemented was rejected, which meant the retroactive ARB review for those proposals was producing approvals without the scrutiny that earlier review would have provided.

The VP of Engineering's analysis: the ARB model had designed a high-quality review gate for the decisions that successfully passed through it, and had designed a strong incentive for teams to route decisions below the threshold — or to present decisions as below the threshold — because the cost of monthly cadence scheduling and a full-ARB review was too high for decisions that needed to be made in a sprint cycle. The ARB was reviewing 38% of the architectural changes that qualified for review, applying significant scrutiny to each one, and producing no review at all for 62% of the changes that its own scope criteria considered architectural. The review quality for reviewed decisions was high; the review coverage was not. The VP's redesign: replace the monthly ARB with a tiered review model — a 48-hour async review for decisions below a scope threshold defined by cross-team impact, with review participation by the affected teams; a weekly ARB sync for decisions above the threshold, with 30-minute focused reviews rather than 10-minute presentations followed by open Q&A. The tiered model distributed the review latency to match the decision complexity, which allowed teams to route decisions to the review process rather than around it because the latency for most decisions became compatible with sprint planning.

Structural properties set by the architecture review process decision

Two structural properties are determined by the founding decisions about review scope, participation model, format, and latency. Both are invisible when the team is small enough that informal conversation handles architectural alignment without a formal process; both become visible when the organization has grown large enough that design decisions made by one team create constraints on other teams who were not part of the decision, and when the accumulated pattern of design decisions across teams either compounds toward a coherent system architecture or diverges toward a set of locally-reasonable but globally-inconsistent subsystems.

Property 1: Architectural consistency ceiling. The architectural consistency ceiling is the maximum degree of coherence the system can achieve across independently-built components — bounded by three factors. First, review scope and trigger model: the set of decisions that go through any review process before implementation determines the maximum scope within which consistency can be enforced. Decisions below the trigger threshold are made independently by each team and accumulate divergence that is visible only when a cross-team integration, a new hire's onboarding, or a system-wide change reveals that each team built something locally reasonable and globally inconsistent — the four incompatible caching models, the five incompatible inter-service communication approaches, the three incompatible authentication token formats. The trigger threshold must be calibrated to two constraints that pull in opposite directions: set too low, it routes decisions to review that are made faster by individual engineers without coordination overhead; set too high, it routes the decisions that most create cross-team constraints below the review threshold and allows the inconsistency to accumulate. The calibration mechanism that produces a stable threshold is feedback from the consistency problems that emerge despite the review: when a cross-team integration reveals that two teams built incompatible approaches neither of which went through review, the trigger threshold should be recalibrated to capture that class of decision. Connect this to the software architecture documentation decision record: the documentation model specifies what architectural decisions are required to be documented and at what level of completeness; the review process trigger model and the documentation trigger model should be aligned — decisions that go through review should produce documentation records, and the documentation record format should capture the review's findings rather than only the author's original proposal, because the finding of the review is the part of the decision record most likely to be useful to a future engineer who encounters the same design space. Second, review participation model: whether the engineers who participate in a review include everyone who will be affected by the decision determines whether the review can identify cross-cutting impacts. A review participated in by the proposing team and a senior technical reviewer will identify quality and feasibility concerns but may miss the specific cross-team impact that only the affected team would know — the downstream service that parses a specific field in the format being changed, the infrastructure team that will need to manage a new caching backend, the security team whose review requirements are triggered by a specific data category. The participation model should specify for each decision class the minimum set of reviewers required, determined by the cross-cutting impact categories that class of decision typically creates, rather than routing all reviews to the same small group of senior engineers who may not have the specific knowledge to identify every impact. Third, architectural record model: whether review decisions are recorded in a form that is accessible to future engineers who will implement components that interact with the decided design determines whether the review process compounds over time. A review that produces a verbal agreement in a meeting, with the agreement preserved only in the memories of attendees, becomes inconsistently applied within six months as team composition changes and memories decay. A review that produces a documented decision record — available to engineers who were not present, discoverable by engineers building components that interact with the decided design — allows each decision to constrain future decisions in the same design space, which is the compounding mechanism that produces architectural consistency over time.

Property 2: Design decision quality surface. The design decision quality surface is the rate at which reviewed decisions achieve a quality level that reduces the need for expensive post-implementation revision — bounded by three factors. First, review latency model: the time from a decision needing review to a decision being unblocked for implementation determines whether the review process is used for significant decisions or routed around. A review process whose latency is calibrated to the organization's planning cycle — where the time required to go through review is compatible with the time available before implementation pressure creates a forcing function — is used for the decisions it is designed to improve. A review process whose latency exceeds the planning cycle creates an incentive to route decisions below the scope threshold, to begin implementation before review, or to present a completed implementation retroactively — all of which produce a review with less ability to change the outcome than a review that happens while the design is still open. The latency model should distinguish between decision classes with different urgency: decisions that must be made within a sprint cycle require a review process with a latency of days, not weeks; decisions whose implementation timeline is measured in quarters can tolerate a higher latency review that provides more comprehensive scrutiny. A single-cadence review process — whether a monthly ARB or a two-week comment period — applies the same latency to every decision regardless of urgency, which produces either a bottleneck for urgent decisions or insufficient scrutiny for complex ones, depending on whether the latency is calibrated to the urgent decisions or the complex ones. Connect this to the engineering technical strategy decision record: the technical strategy specifies the architectural principles and investment priorities that should constrain design decisions across the organization; the architecture review process is the mechanism that ensures design decisions are consistent with the technical strategy, which means the review trigger threshold should be defined in terms of the technical strategy's commitments — any decision that would trade off against a committed architectural principle requires review, regardless of its local scope within one team's component. Second, review format and exploration model: whether the review format is designed to help the proposing team explore the design space and identify failure modes they had not considered, or to evaluate a fully-formed proposal for approval or rejection, determines whether engineers bring decisions to review while options are still open. An approval-gate format — where the review's output is a binary approve or reject decision — creates an incentive to produce advocacy documents rather than explorations, because the author is trying to get approved rather than trying to identify what they might be missing; the advocacy framing means the author presents the strongest case for their proposal and does not surface the uncertainties and alternative approaches that a collaborative review could help resolve. An exploration format — where the review's output is a set of concerns that the author should address, a set of alternative approaches the review identified that the author had not considered, and a set of conditions that would make the proposal acceptable — produces a different kind of document and a different kind of review; engineers bring drafts rather than finished proposals, because the review is useful at draft stage when the design is still open. The format distinction maps directly to when in the design process review is initiated: approval gates are initiated after the design is finished; explorations are initiated while the design is in progress. Third, feedback quality model: whether the review process produces substantive feedback that identifies specific failure modes, cross-cutting impacts, and alternative approaches the proposer had not considered, or produces approvals with minor comments, determines whether the review process adds value proportionate to its latency cost. Connect this to the engineering code review culture decision record: code review culture decisions determine whether code reviewers provide substantive analysis or approve with stylistic comments; architecture review culture decisions determine the same thing at the design level; in both cases the culture is shaped by explicit modeling from senior engineers — senior engineers who provide substantive architecture reviews model the standard that other reviewers calibrate to, and senior engineers who approve without raising concerns model a review culture where approval is the default and concerns are the exception.

The engineering architecture review process ADR: five sections

Section 1: Review scope model and trigger criteria. The scope model specifies what classes of decision require external review before implementation begins. The trigger criteria should be defined in terms of the impact categories that require cross-team alignment rather than in terms of decision magnitude alone, because magnitude is subjective and produces inconsistent application across teams. Three impact categories consistently require review. Cross-cutting impact: decisions that change a shared interface, a shared data format, a shared infrastructure component, or a shared operational constraint in a way that requires other teams to change their implementations. The first story's caching inconsistency accumulated because no individual decision had obvious cross-team impact — each engineer was building a new service, not changing an existing one — but the accumulation of independent decisions produced a cross-cutting impact at the system level that was not visible in any individual decision. The scope model for cross-cutting decisions should include a mechanism for identifying that a pattern is accumulating — an architectural consistency review triggered periodically rather than only on individual decisions — alongside the per-decision trigger for changes to explicitly shared components. Architectural commitment impact: decisions that would trade off against an explicitly documented architectural commitment — a principle in the technical strategy, a constraint in an existing ADR, a promise in a customer contract. These decisions require review regardless of their local scope because they affect a commitment that was made with cross-organizational visibility and that cannot be revised by the team making the local decision. Irreversibility threshold: decisions whose implementation produces a state that is expensive to change after the fact — technology selections that create long-term dependency lock-in, data model choices that become hard to migrate, API designs that create backward compatibility obligations. The irreversibility threshold requires an explicit definition calibrated to the organization's current size and velocity: at a 20-person startup, most decisions are reversible within a sprint cycle; at a 70-person enterprise, a data model decision affects every team that reads or writes that data and requires months to migrate. Connect this to the software architecture documentation decision record: the documentation scope model should match the review scope model — decisions that go through review should produce documentation records, and the documentation record should capture the review's findings so that future engineers can find not just the decision but the concerns the review raised and how they were addressed.

Section 2: Review participation model. The participation model specifies who reviews each class of decision. The participation model should be defined by the impact categories a decision class creates, not by the seniority of the decision-maker or the proposing team: the review participants should be the engineers with the specific knowledge required to identify the cross-cutting impacts of that class of decision, which may be the team that owns an affected component rather than the most senior engineers in the organization. The cross-cutting impact participation model: for decisions that change a shared interface or data format, the required reviewers should include at minimum one engineer from each team that produces or consumes the affected interface; for decisions that change a shared infrastructure component, the required reviewers should include the infrastructure team and one engineer from each team that depends on the component. The architectural commitment participation model: for decisions that trade off against an explicitly documented architectural commitment, the required reviewers should include the engineers who authored the commitment and the engineers whose work was most constrained by it. The model should specify a reviewer assignment process that does not route all reviews to the same small group — the CTO and principal engineers, or the Architecture Review Board — unless those individuals are the only engineers with the required knowledge. Routing all reviews to the same group creates a bottleneck that scales with review volume rather than with reviewer availability, and concentrates the architectural knowledge that determines review quality in a small group whose throughput limits the review process's latency. The participation model should also specify what each reviewer is expected to contribute: whether reviewers are evaluators who assess the proposal against a standard, or collaborators who bring specific knowledge about the cross-cutting impacts in their domain. The collaborator model produces better decisions because it brings domain-specific knowledge to the review rather than only general architectural judgment; the evaluator model produces faster reviews because reviewers can assess without deep domain knowledge, at the cost of missing the domain-specific impacts that would only be identified by someone with that knowledge.

Section 3: Review format and latency model. The format model specifies what a review consists of — what the proposer prepares, what the review participants do, what the review produces — and the latency model specifies the timeline from review initiation to decision. The format choices that most affect decision quality: whether the review requires a fully-formed proposal or accepts a draft-stage exploration; whether the review is synchronous (a meeting where participants discuss the proposal together) or asynchronous (a comment period where reviewers provide written feedback independently); whether the review's output is a binary approve/reject or a structured set of concerns and conditions. A synchronous exploratory format — where the proposer presents a draft design and the reviewers ask questions, raise concerns, and suggest alternatives in a conversation — produces the highest decision quality improvement, because the back-and-forth allows reviewers to understand the proposer's constraints and the proposer to understand reviewers' concerns before a final proposal is written. An asynchronous approval-gate format — where reviewers provide written comments on a finished proposal and the author either accepts or rebuts each comment — produces the least quality improvement, because the proposer produces an advocacy document rather than an exploration and reviewers respond to advocacy rather than exploring the design space together. The latency model should distinguish between decision classes with different urgency, and should specify different formats for different urgency tiers. A tiered model: decisions requiring cross-team alignment but not blocking current sprint work use a two-day async review with a structured concerns template; decisions blocking current implementation use a 48-hour synchronous review with a one-hour meeting of affected parties; decisions affecting architectural commitments use a weekly or bi-weekly scheduled review with a proposal submitted at least five days before the meeting. The latency model is the most important determinant of whether the review process is used for the decisions it is designed for: a process whose latency is consistently compatible with team planning cycles will be used; a process whose latency consistently forces teams to choose between waiting for review and maintaining sprint commitments will be bypassed.

Section 4: Review record model and architectural decision integration. The review record model specifies what the review produces as a documented output, how that output is stored, and how it is connected to the implementation that results from the reviewed decision. The review record should capture more than the approved proposal: the concerns raised in the review and how they were addressed or accepted; the alternatives that were considered during the review that were not in the original proposal; the conditions under which the approved approach was accepted and the conditions under which it would need to be revisited; the reviewers who participated and what domain knowledge each brought to the review. This record structure is more useful to future engineers than the original proposal alone, because it captures the design space that was explored rather than only the design that was selected — the concerns raised in the review are the specific failure modes and cross-cutting impacts the review identified, which is the information a future engineer needs to know whether a change they are proposing conflicts with the reasoning the original review produced. The connection between the review record and the implementation should be explicit: the code or configuration that implements the reviewed decision should reference the review record by identifier, so that an engineer reading the code can find the review that produced the design choice, and an engineer reviewing a proposed change to the code can find the concerns the original review raised before approving the change. Connect this to the engineering incident retrospective decision record: incidents frequently reveal that a design decision made in an architecture review contained an unresolved concern that materialized as a contributing factor; the incident retrospective's contributing factor analysis should check the review records for the affected components to identify whether the failure mode was raised as a concern in the original review and accepted rather than resolved — because an accepted concern is a known risk that was taken on explicitly, while an unidentified concern is a design gap that the review process failed to find; the review record's concerns section is the input that connects incident analysis back to architectural review quality improvement.

Section 5: Review calibration and process health model. The calibration model specifies how the review process is measured and improved over time. A review process that is not measured will drift: latency will grow as review backlog accumulates, scope criteria will become inconsistently applied as team composition changes, and the feedback mechanism that produces process improvements — when teams encounter the consequences of unreviewed decisions, those consequences should trigger scope recalibration — will not operate. Three measurement dimensions for a healthy review process. Coverage rate: the proportion of decisions that met the scope criteria and went through review, measured by comparing the decisions that were submitted for review against the changes implemented in the same period that should have triggered review based on the scope criteria. A coverage rate below 70% signals that the scope criteria are not being applied consistently, that the review latency is causing teams to bypass the process, or that the scope criteria are set too high. The first story's startup had an effective coverage rate near 0% because the scope criteria had never been articulated; the second story's SaaS had an effective coverage rate of about 11% (4 of 35 architectural decisions) because the review latency was incompatible with sprint planning for the remaining 31; the third story's enterprise had an effective coverage rate of 38% because the monthly cadence was incompatible with mid-sprint decisions. Quality improvement rate: the proportion of reviewed decisions that were materially changed by the review — where the review identified a concern that caused the proposer to revise the design, adopt an alternative approach, or add conditions that constrained the implementation. A review process where all or nearly all proposals are approved without material change is either reviewing decisions after they are too committed to change (retroactive review) or is not surfacing the concerns that would improve decision quality (low feedback quality). Architectural drift detection latency: the time from an inconsistency accumulating in the system to the review process identifying it, measured by tracking when cross-team integration problems or new hire onboarding friction attributable to inconsistent architectural choices are first identified. This is the lag indicator that tells you how long architectural inconsistency persists before the review process detects it; a review process with a high drift detection latency is not catching inconsistencies early enough to prevent the compounding cost of rebuilding components to a shared model after the divergence has already been implemented. The calibration model should specify what events trigger a review process calibration review: coverage rate falling below 70%, a cross-team integration failure where both involved changes were below the scope threshold, a new hire's onboarding taking substantially longer than the target due to architectural inconsistencies the review process should have caught. The calibration review produces scope threshold adjustments, format changes, or latency adjustments that the review process applies going forward, keeping the process calibrated to the organization's current size and complexity rather than to the organization it was when the process was designed.

FAQ

Further reading

• Software architecture documentation decision record — the documentation model specifies when architectural decisions are required to be documented, in what format, and with what minimum content; the review process and the documentation model should be aligned so that decisions that go through review produce documentation records that capture the review's findings rather than only the author's original proposal — the finding of the review is the part of the decision record most useful to a future engineer who encounters the same design space, because it specifies the concerns and failure modes the review identified and how they were resolved.
• Engineering technical strategy decision record — the technical strategy specifies the architectural principles and investment priorities that should constrain design decisions across the organization; the architecture review process is the operational mechanism that ensures design decisions are consistent with the technical strategy, which means the review trigger threshold should be defined in part by the technical strategy's commitments — any decision that would trade off against a committed architectural principle requires review regardless of its local scope — and the review participation model should include the engineers responsible for the technical strategy as required reviewers for decisions in their area.
• Engineering code review culture decision record — code review culture decisions determine whether code reviewers provide substantive analysis or approve with stylistic comments; architecture review culture decisions determine the same thing at the design level; in both cases the culture is shaped by explicit modeling from senior engineers; a review culture where architectural concerns raised in code review produce substantive discussion and design changes is a prerequisite for a review culture where architectural concerns raised in an architecture review receive the same; the two review cultures reinforce each other, and an organization that has high code review quality is better positioned to develop high architecture review quality than one where code review has become a formality.
• Engineering incident retrospective decision record — incidents frequently reveal that a design decision made in an architecture review contained an unresolved concern that materialized as a contributing factor; the incident retrospective's contributing factor analysis should check the review records for affected components to identify whether the failure mode was raised as a concern in the original review and accepted rather than resolved; an accepted concern is a known risk taken on explicitly while an unidentified concern is a design gap the review failed to find; the review record's concerns section is the input that connects incident analysis back to architecture review quality improvement, and the retrospective is the event that produces the scope calibration signals the review process needs to identify decisions it should have reviewed and didn't.
• Open-source extractor — the reasoning behind architecture review process design decisions — why the trigger threshold was calibrated to the specific impact categories it specifies, what failure modes the tiered latency model was designed to prevent, how the participation model was designed to distribute review without losing the cross-cutting knowledge concentrated in senior engineers, what the scope calibration adjustments were made in response to which consistency problems — is reasoning conducted in AI chat sessions when engineering leads work through the gap between what their review process was supposed to produce and what it was producing; running those sessions through the extractor produces the architecture review process decision record that allows the next engineering lead to inherit the analysis that shaped the current process, not just the process documentation that resulted from it.