When a customer's principal engineer, staff engineer, head of architecture, or engineering lead writes an architecture decision record on the customer's public engineering blog, in the customer's public design-docs repository, or as a numbered RFC inside the customer's open-source repository and names your product as the option selected over a head-to-head set of alternatives, references your product in a technology-choice rationale that includes explicit trade-off analysis, attributes the selection to your product's specific capability superiority across the evaluated criteria, or names your product in a deprecation-rationale ADR that explains why an earlier choice is being replaced by your product, they are delivering a category of endorsement that no marketing-elicited testimonial can replicate. The decision record has been written under the public commitment of an engineering-design-document discipline, attached to a documented evaluation against a named set of alternatives that any reader can scrutinize, peer-reviewed by the customer's senior engineering organization before publication, and archived in the customer's public design-doc repository where it survives indefinitely as the canonical justification for an irreversible technology choice. The ADR carries the customer's engineering testimony, the comparison matrix carries the head-to-head ratification, and the surrounding peer-review context establishes that the endorsement was issued under the most rigorous internal-engineering-scrutiny environment any customer-facing organization documents.
Almost no B2B developer-tooling, infrastructure-platform, observability-vendor, or engineering-productivity marketing team systematically extracts product mentions from public architecture decision records and engineering RFCs. The omission is the natural extension of the same blind spots we documented in our SEC filing extraction guide, our open-source repository extraction guide, our Stack Overflow extraction guide, our conference talk extraction guide, our SBOM extraction guide, our Terraform module extraction guide, our changelog extraction guide, our status page extraction guide, and our Kubernetes operator extraction guide. Open-source content covers cryptographically signed engineering mentions. Stack Overflow content covers reputation-attached Q&A mentions. Conference content covers peer-reviewed-selected presentation mentions. SBOM content covers regulatory-compliance attested mentions. Terraform module content covers infrastructure-as-code declarative mentions. Changelog content covers chronological release-discipline mentions. Status page content covers operations-pressured reliability mentions. Kubernetes operator content covers cluster-state declarative mentions. Architecture decision record content covers head-to-head-comparison-attached, peer-reviewed-by-senior-engineering, irreversibility-committed, design-archive-preserved engineering selection mentions made inside the most rigorous internal-evaluation environment any customer-facing organization documents — a pillar of the structurally durable public corpus that no other extraction surface can replicate, and the only one where the customer's testimony has been written specifically to justify an irreversible technology selection against a named comparison set.
This guide describes the extraction workflow for the architecture decision record and engineering RFC corpus.
Why an architecture decision record mention beats almost every marketing-elicited testimonial
An architecture decision record mention is a category of endorsement that has passed through filters no marketing-elicited testimonial encounters. Six properties stack to make it one of the most adversarially credible engineering endorsement formats in modern B2B developer-tooling marketing.
First, the ADR has been written under a documented evaluation against a named set of alternatives. ADRs that follow the Michael Nygard format, the Tyree-Akerman format, or the Y-Statement format require the author to list the alternatives considered and the criteria used to evaluate them. A product mention as the selected option is being made against an explicit alternative set that any reader can scrutinize. The named-comparison property is what makes ADR mentions more credible than any format that does not require explicit comparison-set declaration.
Second, the ADR has been peer-reviewed by the customer's senior engineering organization before publication. ADRs typically pass through a review chain that includes the principal engineer or staff engineer who authored the document, the engineering manager who owns the affected system, the head of architecture or head of platform who owns the decision boundary, and frequently the head of engineering or CTO who owns the cross-team consistency commitment. A product mention in an ADR that has passed through this review chain is being ratified by a senior engineering organization that has career exposure on the ADR's accuracy. The internal-review property is what makes ADR mentions more credible than mentions in any format that does not pass through comparable engineering scrutiny.
Third, the ADR records an irreversible commitment that the customer is publicly bound to. ADRs are written to document decisions that are expensive to reverse — database technology selection, message-bus selection, runtime selection, deployment-orchestration selection, monitoring-platform selection. A product mention in an ADR is being made under the public commitment that the customer has accepted the reversal cost of selecting that product. The irreversibility property is materially stronger than the equivalent on any format without comparable commitment-cost attachment.
Fourth, the ADR is archived indefinitely in the customer's public design-doc repository. ADRs are preserved indefinitely in the design-doc repository as the canonical justification for the selection, where any future engineer, regulator, journalist, or competitor can retrieve the record and compare it against the customer's current technology stack. The indefinite-archive property is what makes ADR mentions more durable than mentions in any format without comparable archival permanence.
Fifth, the ADR includes an explicit trade-off and consequences section. ADRs in any standard format require an explicit consequences section that documents the trade-offs accepted by the selection. A product mention in an ADR is therefore accompanied by the customer's own documentation of the trade-offs the customer accepted to select your product, which is a category of testimony no marketing-elicited testimonial includes. The trade-off-disclosure property is materially stronger than the equivalent on any format without comparable consequences-section attachment.
Sixth, the ADR is frequently referenced by subsequent ADRs as a precedent. ADRs in mature engineering organizations form a referenced chain where later ADRs cite earlier ADRs as precedent for related decisions. A product mention in an ADR that is subsequently referenced by other ADRs is being elevated from a single decision document to a precedent-setting reference in the customer's engineering canon. The precedent-chain property is what makes ADR mentions more compounding than mentions in any format without comparable cross-reference architecture.
The seven ADR and RFC content locations where customer mentions appear
The ADR and RFC ecosystem has seven primary content locations where a product mention can surface, and each carries a different credibility weight and a different downstream usability.
Location 1 — The ADR decision section where your customer names the selected option
An ADR decision section that names a vendor product as the selected option is the highest credibility-dense location because the decision section is the single irreversible commitment the document makes and the customer is publicly attributing the commitment to the vendor product. The selected-option-attribution format is the highest-weight format for ADR extraction.
Location 2 — The ADR alternatives-considered section where your customer rejects competitors
An ADR alternatives-considered section that names competitor products as rejected options is the second highest credibility-dense location because the rejection rationale is the customer's documented head-to-head comparison that establishes why your product was preferred. The rejection-rationale format is the second-weight format for ADR extraction and is the strongest competitive-positioning material that any extraction surface produces.
Location 3 — The ADR consequences section where your customer documents accepted trade-offs
An ADR consequences section that documents the trade-offs accepted to select your product is the third highest credibility-dense location because the trade-off documentation is the customer's own acknowledgment that the selection involved a deliberate cost-benefit choice. The accepted-trade-off format is the third-weight format for ADR extraction and is the most credibility-bearing content for risk-averse buyer personas.
Location 4 — The RFC implementation section where your customer specifies the integration approach
An RFC implementation section that specifies how your product will be integrated is the fourth highest credibility-dense location because the implementation detail is the customer's own engineering specification of the integration surface. The implementation-specification format is the fourth-weight format for RFC extraction.
Location 5 — The ADR superseded-by chain where your customer reaffirms or replaces the selection
An ADR superseded-by chain is the fifth highest credibility-dense location because the chain documents whether the original selection has been reaffirmed, modified, or replaced. A product mention in an original ADR that has not been superseded is being reaffirmed by the absence of a replacement ADR. The reaffirmation-by-non-supersession format is the fifth-weight format for ADR extraction.
Location 6 — The RFC review-comments section where senior engineers endorse the proposal
An RFC review-comments section that records senior-engineer endorsements is the sixth highest credibility-dense location because the comments are the named-attribution endorsements from the customer's senior engineering organization. The senior-endorsement format is the sixth-weight format for RFC extraction.
Location 7 — The cross-team ADR reference where your customer's other teams adopt the same selection
A cross-team ADR reference is the seventh highest credibility-dense location because the reference documents that the original selection has been adopted by other teams in the customer's organization as a precedent. The cross-team-adoption format is the seventh-weight format for ADR extraction.
The extraction workflow
The workflow has four stages and converts the raw ADR and RFC archive into a deployable testimonial inventory.
Stage 1 — Discovery of the public ADR archive
The discovery stage identifies which customers maintain public ADR archives. The discovery signals include the existence of a docs/adr/ or docs/architecture/decisions/ directory in the customer's primary open-source repository, the existence of an engineering blog with an /architecture/ or /decisions/ URL path, the existence of a public design-docs repository under the customer's GitHub or GitLab organization, the existence of an rfcs repository following the Rust, Python, Ember, or React RFC convention, and the presence of ADR or RFC mentions in the customer's engineering-blog index. The discovery stage produces a customer-segmented list of ADR-archive URLs.
Stage 2 — Full-text search across the ADR archive for product mentions
The search stage runs full-text queries across each customer's ADR archive for product-name mentions, product-component mentions, product-feature mentions, product-capability mentions, and product-integration mentions. The search uses both the canonical product name and the customer-side abbreviations that the customer's engineers use in internal documents. The search stage produces a per-ADR list of mention locations classified by the seven content locations.
Stage 3 — Credibility-weight classification of each mention
The classification stage assigns each mention to one of the seven content locations and applies the credibility weight associated with that location. Mentions in the decision section receive the highest weight. Mentions in the alternatives-considered section receive the rejection-rationale weight, which is the strongest competitive-positioning weight. Mentions in the consequences section receive the trade-off-disclosure weight. The classification stage produces a credibility-weighted mention inventory.
Stage 4 — Conversion of high-weight mentions into deployable testimonial assets
The conversion stage takes each high-weight mention and produces a deployable testimonial asset that includes the verbatim quote, the customer name and engineer role, the link to the public ADR or RFC, the alternatives compared, the criteria used, and the consequences accepted. The deployable asset is then routed into the customer's testimonial library, the competitive-positioning library, or the buyer-objection-handling library based on the content-location classification.
The compounding effect
A customer organization that publishes an ADR naming your product as the selected option will, over the following twelve months, publish three to seven subsequent ADRs that reference the original decision as precedent. A product mention in a single ADR therefore compounds into a precedent-setting reference in three to seven subsequent decisions. The ADR-extraction workflow that runs continuously across the public ADR archive will capture this compounding effect and produce a testimonial inventory that grows faster than the underlying customer base. This is the structural property that makes the ADR corpus one of the highest-yield extraction surfaces in the structurally durable public corpus.
For the broader extraction-workflow architecture that this ADR-extraction guide sits inside, see our bot-generated testimonial detection guide and our embed testimonials guide.