The platform engineering team mandate decision record: why the toil reduction mandate you set determines your platform adoption incentive surface and your golden path completeness gap

A 38-person B2B SaaS company built an operations intelligence platform for logistics and supply chain teams — route optimization, carrier performance dashboards, and a real-time exception management interface for freight operations managers. The company had grown from eleven to thirty-eight people over four years, with an engineering team of sixteen across two product squads and a shared infrastructure function. At the beginning of year four, the head of engineering proposed creating a dedicated platform engineering function — a team of two senior engineers who would build the internal developer platform that the product squads were increasingly spending time reinventing. The proposal identified four areas of toil: service scaffolding (each new service required two to three days of manual setup), CI pipeline configuration (each squad maintained its own pipeline templates with significant variance), secret provisioning (engineers submitted Jira tickets to the infrastructure team to provision database credentials and API keys), and deployment promotion (promoting a release from staging to production required manual steps that were documented in a runbook and took thirty to forty-five minutes to execute). The mandate was stated in the platform team's launch announcement: "The platform team's job is to eliminate developer toil. We will build the internal tools that let product engineers focus on product problems instead of infrastructure problems."

In the twelve months that followed the platform team's formation, the team shipped fourteen self-service tools: a service scaffolding CLI, a CI pipeline configurator, a secret provisioning API with a web interface, a deployment promotion pipeline, a local development environment setup script, a database migration helper, a cross-service integration test fixture generator, a Kubernetes namespace provisioning tool, a TLS certificate renewal automator, a dependency update bot, a cost anomaly alert configurator, a load testing scaffold, a runbook template generator, and a service health dashboard bootstrapper. Each tool was announced in the #platform-engineering Slack channel with a demo and a usage guide. The head of engineering presented the fourteen tools to the executive team at the annual engineering review as evidence of the platform team's productivity. The platform team's velocity was high: fourteen shipped capabilities in twelve months was more than one tool per month.

The engineering survey conducted six weeks after the annual review asked product engineers to rate the tools they used weekly, the tools they had tried once, the tools they had heard of but never tried, and the tools they had not heard of. The results were stark. Three tools had more than 20% weekly active users among the sixteen product engineers: the secret provisioning API (11 weekly active users), the deployment promotion pipeline (9 weekly active users), and the CI pipeline configurator (8 weekly active users). The remaining eleven tools had between zero and three weekly active users each. The service scaffolding CLI — the tool the mandate had listed first as the highest-toil workflow — had been used by four engineers in the past twelve months, all of whom had scaffolded exactly one service and then returned to their prior scaffolding approach for subsequent work. The cross-service integration test fixture generator had been used by one engineer on one occasion. The database migration helper, the Kubernetes namespace provisioning tool, and the runbook template generator had zero weekly active users.

The post-survey platform team retrospective identified the root cause: the mandate had specified toil reduction as a capability-delivery goal — build tools — rather than as an adoption outcome — reduce the time engineers spend on specific workflows. The fourteen shipped tools were available. The eleven that engineers did not use were available because the platform team had shipped them, not because the platform team had confirmed that engineers would adopt them. The secret provisioning API, the deployment promotion pipeline, and the CI configurator had high adoption for a structural reason: the platform team had explicitly replaced the prior workflow for each of these three tools, either by deprecating the old Jira-based secret request process (forcing engineers to use the API or have no path to secrets), or by making the CI configurator the only supported path for new CI pipelines going forward. The eleven low-adoption tools had been added to the existing set of options without removing the workflows they were intended to replace. Engineers had no incentive to switch from a familiar manual workflow to an unfamiliar self-service tool when both paths reached the same outcome, and no one on the platform team had measured whether the switch actually happened. The platform team's mandate had no adoption success criterion because adoption had not been defined as part of the mandate — only capability delivery had been defined, and capability delivery had been achieved.

A 53-person enterprise SaaS company built a compliance workflow platform for mid-market financial services teams — regulatory filing management, evidence collection, audit preparation, and a client-facing portal for external auditors. The company had grown to fifty-three people over five years, with an engineering team of twenty-four across three product squads and a platform team of three. The platform team had been running for two years and had built a golden path covering four capabilities: service scaffolding (a CLI that provisioned a new service with standardized project structure, Dockerfile, CI pipeline, and Kubernetes manifests), CI pipeline configuration (a shared pipeline library that all services were required to use), secret provisioning (an API that replaced manual Vault access), and deployment promotion (a pipeline that enforced the staging-to-production promotion sequence). The platform team measured golden path adoption quarterly. At the end of the second year, adoption metrics were: service scaffolding 84%, CI pipeline library 91%, secret provisioning 79%, deployment promotion 88%. The platform team lead presented these numbers to the head of engineering as evidence that the golden path was working.

Twelve weeks later, the company ran its first formal developer experience survey — a structured questionnaire covering twelve workflow categories, each rated on a five-point friction scale. The survey was designed by a developer experience consultant the company had engaged to evaluate whether the engineering team was ready to support the growth from twenty-four to thirty-five engineers planned for the following year. The survey results produced a friction ranking across the twelve categories. Service scaffolding, CI configuration, secret provisioning, and deployment promotion — the four golden path categories — all scored between 1.4 and 2.1 on the five-point friction scale (1 = no friction, 5 = significant friction). They ranked as the lowest-friction workflows in the survey, consistent with the platform team's adoption metrics. The eight categories not covered by the golden path told a different story.

Local development environment setup averaged 3.8 friction and was cited as the highest-friction activity by 14 of 24 engineers. The typical pattern was that a new engineer joining a squad spent two to three days getting their local environment running against the company's services, navigating service version incompatibilities, secret injection into local processes, and network configuration for cross-service calls in the local context. Cross-service integration testing averaged 3.6 friction: engineers building features that crossed service boundaries spent an average of four to six hours per sprint creating test fixtures that simulated the behavior of services they did not own. Database schema migration coordination averaged 3.4 friction: major schema changes required coordination meetings, manual DBA review, and a migration timing window negotiation that added two to four hours of overhead per significant schema change. Dependency update management averaged 3.2 friction. Cross-team API contract validation averaged 3.1 friction. The eight uncovered workflows averaged 3.1 friction; the four covered workflows averaged 1.7 friction.

The DX consultant's analysis calculated total engineering-hours consumed by friction across all twelve categories. The four golden path workflows accounted for 33% of total friction hours — the other 67% was in uncovered workflows. The consultant noted that the platform team's adoption metrics were accurate and that the golden path was genuinely effective at reducing friction within its coverage scope. The problem was that the coverage scope had been defined by the platform team's interpretation of where toil was highest in year one, before any systematic measurement had been conducted. The original four covered workflows had been the most visible toil to the platform team because they were the workflows where engineers most often interrupted the platform team's predecessor — the infrastructure function — for manual assistance. Local development environment setup, cross-service integration testing, and database schema migration coordination had not generated infrastructure team tickets because engineers routed those problems through their squad's internal practices rather than through infrastructure requests. They were invisible to the team that defined the golden path's coverage scope, and two years of 80%+ adoption in covered areas had provided no signal that the 67% of total toil was going unaddressed.

A 44-person B2B SaaS company built a developer productivity analytics platform — CI performance profiling, build time regression detection, and a test failure correlation tool. The company had grown to forty-four people over three years, with an engineering team of twenty across four product squads and a platform team of three. When the platform team was established in year two, the head of engineering had written a mandate that included an explicit inner source principle: "The developer platform is a product owned by the platform team and contributed to by everyone. Every engineering squad is a stakeholder and every engineer is a potential contributor. We want the platform to reflect the workflows that squads actually use, and contributions are the mechanism by which squad-specific knowledge enters the platform." The announcement was well-received. Three squad leads committed to contributing a workflow automation they had been building independently.

In the first year of the inner source model, thirty-four pull requests were opened against the platform team's repositories by non-platform engineers. Eleven were merged. The twenty-three rejected PRs included: a new integration for a third-party end-to-end testing tool that one squad had adopted (rejected with the comment "we're not ready to take a dependency on this tool at the platform level — not in our current roadmap"); a CI pipeline optimization for Go services that reduced the average build time by 23% on the submitting squad's services (rejected with the comment "this doesn't fit our current pipeline abstraction model, would need a refactor of the core pipeline library"); a secret rotation helper that stored rotated credentials in a format that the platform team's Vault-based secret manager did not support (rejected with the comment "incompatible credential format — you'd need to use the Vault KV v2 schema instead of this flat structure"); a service-to-service authentication helper that provided a simplified interface over the platform team's mTLS configuration (rejected with the comment "we're planning to address this in Q3 with a different approach"); and a monitoring dashboard bootstrapper for Go services that used Prometheus client libraries the platform team had not standardized on. Most rejected PRs received a comment explaining the rejection reason, but none of the rejection comments had been predictable from the contributing guide, which described the inner source model as "open contribution with platform team review" without specifying what the review would evaluate.

By the second year, contributions from non-platform engineers dropped to four pull requests over the full year, of which three were merged. An engineering retrospective in year two's Q3 identified a pattern: fourteen engineers across the four product squads had built workflow tools in their own squad repositories over the course of the year. The tools included a local development bootstrapper for the frontend squad, a service-specific Makefile target library for the data engineering squad, a deployment helper that wrapped the platform's deployment pipeline with squad-specific environment configuration, and a cross-service test fixture library for two of the product squads. None of these had been proposed as platform contributions. When the retrospective facilitator asked why engineers had built in their squad repositories instead of contributing to the platform, three themes emerged: engineers did not know whether their proposed tool was within the platform's scope, engineers who had contributed in year one and been rejected had concluded that the platform acceptance bar was unpredictable, and engineers who had heard about rejections from colleagues had decided the contribution overhead was not worth the risk of a rejection that arrived after weeks of work. The fourteen squad-level tools collectively duplicated significant platform team effort — the local development bootstrappers in three squads each solved the same problem with slightly different approaches, and none of the three had benefited from the other two's solutions because all three were in squad-private repositories.

The platform team's year-two retrospective identified the structural gap: the inner source principle had stated that contributions were welcome without specifying the criteria a contribution had to meet. The acceptance criteria for platform contributions were implicit in the platform team's architectural model, which was documented in internal ADRs that were accessible but not referenced in the contributing guide. Engineers who submitted contributions had no way to evaluate, before investing the work, whether their proposed contribution was in scope, whether their implementation approach was consistent with the platform's existing abstractions, or whether the maintenance burden their contribution created was within the platform team's staffing model. The rejection comments had explained why specific PRs were rejected but had not provided the generalizable criteria that would have allowed the next contributor to predict whether their contribution would be accepted. The inner source model had been genuine — the platform team had wanted contributions — but the contribution governance surface had been opaque, and engineers had rationally concluded that the contribution path was not worth the investment.

Structural properties set by the platform engineering team mandate decision

Three structural properties are determined when a team establishes — or fails to explicitly specify — a platform engineering team mandate: what the toil reduction mandate determines about the adoption incentive surface as the platform team ships capabilities that engineers may or may not use, what the self-service coverage definition determines about the golden path completeness gap as the platform team selects which workflows to automate without measuring which workflows engineers actually find most painful, and what the inner source model determines about the contribution governance surface as non-platform engineers decide whether to route their platform-adjacent work through the platform or into squad repositories. None of these are labeled as decisions when a head of engineering announces that a platform team is being created, writes a mandate that says "eliminate developer toil," and states that the platform is open to contributions. They emerge as operational failures when a team ships fourteen tools and finds eleven with negligible adoption because adoption was never defined as a success criterion, when a platform team achieves 85% adoption in covered workflows while DX data reveals those workflows contain a third of actual engineering friction, and when an inner source model collapses as engineers learn through rejected PRs that the acceptance criteria they needed to predict success were never documented.

Property 1: The toil reduction mandate and the platform adoption incentive surface. The toil reduction mandate is the statement of what the platform team is responsible for producing — the outcome the team's effectiveness is evaluated against. The mandate almost universally specifies toil reduction as a capability goal: build the service scaffolding tool, build the CI pipeline configurator, build the secret provisioning interface. Capability goals are measurable at ship time and produce a velocity metric — number of tools shipped per quarter — that creates an incentive to ship tools regardless of whether engineers adopt them. The adoption incentive surface is the set of factors that determines whether engineers actually switch from their existing workflows to the platform's tools: whether the tool is the only path to a required outcome (forced adoption) or one option among several (optional adoption); whether the tool is faster than the existing workflow once the engineer has learned it; whether the tool's failure modes are recoverable without platform team assistance; and whether the engineer's squad has time to learn a new interface when the existing workflow produces acceptable outcomes. A mandate that measures capability delivery has no mechanism for distinguishing between a tool that is available and a tool that is used, because adoption is not in the success criterion. The adoption incentive structure that produces high adoption in optional-adoption contexts has two components: the platform team must measure adoption as a first-class outcome metric (not a secondary metric after capability delivery) and must have a defined response to low adoption — an investigation into whether the tool's design is the gap or whether the adoption gap is a demand signal that the workflow was lower-priority than the coverage definition assumed. Connect this property to the developer experience decision record: the DX measurement framework decisions — what instrumentation is used to measure engineering friction, how friction surveys are structured, and what baselines are established for each workflow category — determine whether the platform team has the data to distinguish between a tool adoption problem (the tool doesn't serve the workflow variation engineers actually use) and a coverage definition problem (the workflow was added to the golden path based on platform team interpretation rather than measured engineer demand); without DX measurement, the platform team has only capability metrics and adoption counts, with no signal for why adoption is low or what would change it.

Property 2: The self-service coverage definition and the golden path completeness gap. The self-service coverage definition is the decision about which engineering workflows the platform team is responsible for automating. The coverage definition is the most consequential decision the platform team makes, because it determines where the team's capacity goes and which sources of engineering friction the team is responsible for eliminating. The coverage definition is almost always formed from the platform team's interpretation of where toil is highest — based on the workflows that generated the most infrastructure tickets, the workflows that the head of engineering cited in the platform team's launch announcement, or the workflows the platform team's senior engineers found personally painful in their prior roles. Systematic measurement of engineering friction across all workflows is rarely conducted before the coverage definition is set, which means the golden path is built on the platform team's prior experience rather than on a data-driven understanding of where total friction is highest. The golden path completeness gap is the difference between the platform's coverage scope and the full set of workflows that contribute meaningfully to engineering friction. The gap is structurally invisible at any given moment because the platform team's adoption metrics measure adoption within covered workflows — a platform team that achieves 80% adoption in four covered workflows has no visibility into whether those four workflows represent 20% or 80% of total engineering friction, because the friction measurement is not conducted outside the coverage scope. The coverage definition should be based on systematic friction measurement conducted before the golden path scope is committed: a time-tracking audit across all infrastructure-adjacent workflows, an interruption log analysis of the platform team's own ticket queue, and DORA metric correlation to identify which workflows are in the critical path for deploy frequency and change lead time. Connect this property to the developer portal decision record: the portal's self-service scope decisions and the platform mandate's coverage definition are co-dependent — the portal exposes the golden path workflows that the mandate has designated as covered, and the portal's discoverability gap (the workflows engineers cannot find a self-service path for) is a direct reflection of the mandate's golden path completeness gap; a portal that presents a navigable interface to three covered workflows while engineers spend more time on eight uncovered workflows is not a portal discoverability problem, it is a mandate scope problem that the portal's adoption data will reveal if DX friction measurement is conducted across all workflows rather than only within the portal's coverage.

Property 3: The inner source model and the contribution governance surface. The inner source model is the decision about how non-platform engineers can contribute to the developer platform. The inner source principle — contributions from all squads are welcome — is a meaningful commitment that has the potential to scale the platform's coverage beyond what the platform team can build alone and to route squad-specific workflow knowledge into the platform rather than into squad-private repositories. The inner source model collapses when the contribution governance surface is opaque — when would-be contributors cannot predict whether their proposed contribution will be accepted before investing the work, and learn the acceptance criteria only by submitting contributions that are rejected. The contribution governance surface is the set of decisions a contributor must navigate: whether the problem is in scope for the platform, whether the proposed solution is architecturally compatible with the platform's existing abstractions, and whether the maintenance burden the contribution creates is within the platform team's staffing model. When the governance surface is not documented as explicit acceptance criteria, the platform team evaluates contributions against implicit criteria that are clear to the platform team but not to contributors. Each rejection teaches the contributor something about the criteria they would have needed to know before starting — but the lesson arrives after the work is done, and the lesson is specific to the rejected contribution rather than generalizable to future contribution candidates. Engineers who receive a rejection after weeks of work, or who hear about colleagues' rejections, rationally conclude that the contribution path is not worth the investment, and route their platform-adjacent work into squad repositories where acceptance criteria are determined by the engineer's own judgment. The inner source model requires an explicit contributing guide that specifies in-scope problem categories, architectural compatibility requirements, and maintenance burden expectations before the model is announced. Connect this property to the platform team ADR on infrastructure constraints: the infrastructure constraints that bound the platform team's self-service scope — what workflows can be automated without human approval at runtime, what external dependencies the platform team will accept, what operational responsibilities the platform team will own — are the same constraints that determine what contributions are structurally eligible for acceptance; publishing the infrastructure constraints as the acceptance criteria boundary for inner source contributions makes the contribution governance surface explicit before contributors invest work in proposals that the constraints would prevent from being accepted. The WhyChose extractor finds the platform engineering mandate decisions buried in your AI chat history — the formation session where the mandate was written as "eliminate developer toil" without specifying an adoption success criterion, the sprint planning session where the coverage definition was formed from the platform team's interpretation of pain rather than a friction measurement, and the inner source launch session where "contributions are welcome" was written without specifying what a contributable problem looked like.

The platform engineering mandate ADR: five sections

Section 1: Toil reduction mandate scope and adoption success metric specification. Specify the outcome the platform team is responsible for producing, measured in terms of adoption outcomes rather than capability delivery. For each coverage area the platform team is responsible for, the mandate should specify: the current state (how engineers accomplish the workflow today, how long it takes, how often they do it), the target state (the platform tool that will serve the workflow, and what "served" means in terms of adoption percentage and time reduction), the adoption metric that will be measured quarterly (not "tool available" but "percentage of engineers who use the tool as their primary workflow path"), and the adoption response policy (what the platform team does when the adoption metric is below threshold — investigate tool design, improve onboarding, or remove the workflow from coverage and redirect capacity to higher-value coverage). The mandate should also specify the adoption incentive mechanism for each optional-adoption tool: whether the tool will replace the prior workflow path (forced adoption) or be offered alongside it (optional adoption), and if optional, what the adoption incentive is (faster outcome, better reliability, required for new capabilities, required for compliance). Optional-adoption tools with no stated incentive mechanism have a structural adoption gap that the mandate must address before the tool is shipped. Connect this section to the platform engineering decision record: the IDP tool selection decisions — whether the platform team builds on Backstage, Port.io, or a custom internal platform — determine the surface area within which the mandate's covered workflows can be implemented; the mandate scope must be bounded by what the selected IDP can support without requiring the platform team to maintain significant custom infrastructure, because adoption of a platform tool is partly determined by the tool's reliability, and a custom platform that the platform team cannot maintain at adequate quality will have adoption problems independent of the mandate's incentive structure.

Section 2: Self-service coverage definition methodology and scope rationale. Specify how the platform team determined which workflows to cover with the golden path, with the friction measurement data that justifies the coverage selection. Before defining the golden path scope, the platform team should conduct: a time-tracking audit of all infrastructure-adjacent workflows across all product squads (two weeks of structured time tracking covering service scaffolding, CI configuration, environment setup, secret management, deployment, cross-service test setup, database migration coordination, dependency management, API contract validation, and any workflow category that engineering managers identify as friction sources); an interruption log analysis of the platform team's own ticket queue and Slack DM history for the prior quarter (identifying which workflow categories generate the most platform team interruptions, because interruptions are a proxy for the manual steps that self-service automation would eliminate); and a DORA metric correlation to identify which workflow categories are serialization points in the deploy frequency and change lead time paths (because serialization points have higher leverage for self-service automation than workflows that are parallel with the critical path). The coverage definition output is a prioritized list of workflows with: friction-hours consumed per quarter per workflow, estimated implementation cost in platform team weeks, and the ratio of friction-hours to implementation cost as the primary prioritization criterion. The documented rationale for coverage selection should include both what is in scope and why, and what is explicitly out of scope and why — the explicit out-of-scope list prevents scope expansion into low-leverage coverage areas and provides a documented response to engineers who propose coverage of out-of-scope workflows. Connect this section to the team topology decision record: the team topology decisions determine which squads are platform teams and which are stream-aligned; the platform team's coverage definition must be bounded by the platform team's mandate relative to other enabling and complicated-subsystem teams in the topology; coverage areas that overlap with other enabling teams' responsibilities should be explicitly coordinated, because coverage overlap produces competing platform abstractions that engineers must navigate when the two teams' tools interact.

Section 3: Golden path completeness criteria and gap identification cadence. Specify the criteria for evaluating whether the golden path is complete relative to total engineering friction, and the cadence at which the coverage definition is evaluated against new friction measurement data. The golden path is complete when the covered workflows account for at least 70% of total engineering friction-hours across all workflow categories — measured by the same time-tracking and interruption-log methodology used to establish the initial coverage definition, repeated quarterly. The gap identification cadence requires: a quarterly DX survey covering all workflow categories (not only covered ones) with a consistent question set that measures friction on a defined scale; an annual time-tracking audit to recalibrate the friction-hours baseline as the engineering team grows and the workflow distribution changes; and a coverage review after each engineering organization-level change (new squad, new technology adoption, new compliance requirement) that may have introduced new high-friction workflows outside the current coverage scope. The coverage expansion trigger is a workflow category that scores above 3.0 on the five-point DX friction scale in two consecutive quarterly surveys and that is not currently covered by the golden path — this trigger initiates a coverage assessment (friction-hours estimate, implementation cost estimate, fit within the platform team's capacity) rather than an automatic coverage commitment. The coverage reduction trigger is a covered workflow with adoption below 40% after 90 days of availability and two rounds of tool improvement and onboarding investment — this trigger initiates a mandate review to evaluate whether the workflow should be removed from coverage and the platform team capacity redirected. Connect this section to the developer experience decision record: the DX measurement model decisions — which metrics are tracked, how friction surveys are structured, and what the response protocol is when friction scores increase — provide the measurement infrastructure for the golden path completeness evaluation; the platform team mandate's completeness criteria are only evaluable if the DX measurement model produces friction data across all workflow categories, not only the categories the platform team has already covered.

Section 4: Inner source model governance and contribution acceptance criteria. Specify the acceptance criteria for platform contributions, the contribution process, and the review turnaround commitment, before the inner source model is announced. Contribution scope criteria (in-scope): the problem must be a workflow that is used by at least three engineering squads, must fit within the platform's existing abstraction layer without requiring changes to the platform's core contracts, and must be a workflow the platform team has confirmed is on the golden path roadmap or has agreed to add based on the contribution's friction-hours justification. Contribution scope criteria (out-of-scope): the problem is used by only one squad and is not generalizable to other squads; the problem requires a new external dependency the platform team has not evaluated; the problem requires the platform team to accept operational responsibility for a capability the team hasn't staffed for; the problem requires changes to the platform's core infrastructure contracts. Architectural compatibility criteria: the contribution must use the platform's specified SDK and toolchain versions, follow the platform's configuration schema conventions (documented in the platform's contributing guide), and not require changes to the platform's public-facing API contracts with the services that consume the platform. Maintenance burden criteria: the contribution must include a test suite with coverage of the specified failure modes, documentation at the platform's documentation standard, and a designated squad-side maintainer who will own the contributed capability for at least 12 months and respond to issues opened against the contribution within two business days. Review turnaround commitment: the platform team will provide an initial response to any contribution within five business days — either a provisional acceptance (merged pending test coverage and documentation requirements), a rejection with a specific reference to the criterion the contribution does not meet, or a scope discussion request for contributions whose fit is ambiguous. Connect this section to the platform team ADR on infrastructure constraints: the infrastructure constraints documented in the infrastructure constraints ADR are the same constraints that determine what contributions are structurally eligible for acceptance; publishing a reference to the infrastructure constraints ADR in the contributing guide, with a summary of the constraint categories most relevant to contribution scope, makes the out-of-scope boundary navigable for contributors before they begin work.

Section 5: Platform team effectiveness review cadence and mandate revision threshold. Specify the cadence for evaluating the platform team's mandate effectiveness and the signals that trigger a mandate revision. Quarterly effectiveness review: the platform team presents adoption metrics for all covered workflows, DX survey friction scores for covered and uncovered workflows, and the capacity ratio (percentage of platform team capacity spent on advancing the golden path versus maintaining existing tools). The quarterly review evaluates three questions: Is adoption above threshold for all covered workflows? (If not, investigate tool design or remove from coverage.) Does the uncovered workflow with the highest friction score represent a higher-leverage investment than the current platform roadmap? (If so, initiate a coverage assessment.) Is the capacity ratio above 50% on advancement? (If not, evaluate whether coverage reduction is needed to restore capacity for advancement.) Mandate revision triggers: (1) a covered workflow with adoption below 40% for two consecutive quarters after tool improvement investment — initiate a coverage removal assessment; (2) an uncovered workflow category scoring above 3.5 friction in two consecutive quarterly surveys — initiate a coverage addition assessment; (3) the platform team's maintenance capacity ratio above 50% for three consecutive quarters — initiate a scope reduction review; (4) the engineering organization growing by more than 50% since the last coverage definition review — initiate a full friction measurement cycle to recalibrate the coverage definition against the new team's workflow distribution. The mandate revision process must include the head of engineering and at least one squad lead from each product squad, because the mandate's coverage definition determines where engineering friction is addressed and where it is not, and those affected by uncovered workflows must have input into coverage priority decisions. Mandate revisions are recorded as a new ADR version with a supersedes reference to the prior version, documenting what changed, why, and what friction data drove the change. Connect this section to the developer portal decision record: the portal's success metric model decisions — which adoption metrics are used to evaluate whether the portal is fulfilling its discoverability purpose — should be evaluated in the same quarterly review as the platform mandate's adoption metrics; the portal adoption data (which self-service workflows engineers find and complete through the portal) and the mandate adoption data (which golden path workflows engineers use as their primary workflow path) together provide the full picture of whether the platform team's covered workflows are both available and being used as intended.

FAQ

Further reading

• Platform engineering decision record — the internal developer platform tool selection decisions (Backstage, Port.io, custom platform) that determine the surface area within which the mandate's covered workflows can be implemented; the IDP selection determines the platform team's maintenance cost model and the coverage ceiling — the mandate scope must be bounded by what the selected IDP can support without requiring the platform team to maintain significant custom infrastructure beyond their staffing capacity.
• Team topology decision record — the team structure decisions that determine which teams are platform teams and which are stream-aligned; the platform mandate scope must be coordinated with the topology decisions so that coverage areas don't overlap with other enabling or complicated-subsystem teams' responsibilities, producing competing platform abstractions that engineers must navigate when the two teams' tools interact.
• Developer experience decision record — the DX measurement model decisions that establish how engineering friction is measured and which metrics are tracked; the platform team's mandate effectiveness evaluation depends on friction measurement conducted across all workflow categories, not only covered ones; without a DX measurement model that spans uncovered workflows, the golden path completeness gap is invisible until a formal DX survey reveals it.
• Developer portal decision record — the self-service portal scope and success metric decisions; the portal's discoverability gap and the mandate's golden path completeness gap are the same gap expressed in different terms — the portal exposes the workflows the mandate has designated as covered, and workflows outside the mandate's coverage scope have no portal path; the portal's adoption data is one signal for evaluating whether the mandate's covered workflows are being used as intended.
• Platform team ADR on infrastructure constraints — the infrastructure constraints that bound the platform team's self-service scope; these same constraints determine what inner source contributions are structurally eligible for acceptance; publishing the infrastructure constraints as the boundary for contribution scope makes the contribution governance surface explicit before contributors invest work in proposals that the constraints would prevent from being accepted.
• Open-source extractor — find the platform engineering mandate decisions buried in your AI chat history: the team formation session where the mandate was written as "eliminate developer toil" without specifying an adoption success criterion, the sprint planning session where the coverage definition was formed from the platform team's interpretation of pain rather than a friction measurement, and the inner source launch session where "contributions are welcome" was written without specifying what a contributable problem looked like.