PATTERN Cited by 1 source

Policy proof-of-concept branch

What it is

When rebuilding an authorization engine — or any system whose correctness is defined by an accumulated corpus of existing rules — port all existing rules into the new system on a throwaway branch, run the full existing test suite, and don't ship anything until every test passes. The branch itself may be discarded afterward; the point is the process of porting.

Why it matters

• Proof that the new model can express every existing behavior. If a rule can't be ported, either the new model needs extension or the rule itself needs questioning.
• Codified understanding of the domain. "Through this work we were able to learn all the little intricacies of the permissions rules that engineers had added over the years and the product reasoning behind them." (sources/2026-04-21-figma-how-we-built-a-custom-permissions-dsl) The porting process forces every author / reviewer to surface latent product decisions, regulatory constraints, and historical exceptions.
• A green CI run against hundreds of existing tests is the best available evidence of correctness. Figma: "These were hundreds of tests written over many years, so we were fairly confident that what we had worked."
• Surfaces model inadequacies early. Figma's first PoC established the model worked but also surfaced the two key weaknesses (the attached_through abstraction was clumsy, imperative apply? couldn't cross platforms) that drove the pivot to a JSON-serializable ExpressionDef.

Process

1. Fork the codebase to a dedicated branch.
2. Implement the minimum viable new system (data model + evaluator).
3. For each existing rule, port it to the new system — don't skip edge cases, don't "just cover the 80%," don't refactor the rule while porting.
4. Run the full existing test suite against the new system. Iterate until green.
5. Review what you learned — both about the domain and about the new model's weaknesses. The branch may be thrown away; the design insights are the payoff.
6. If the new model is fundamentally inadequate, iterate the model before starting the production migration.

Figma describes the outcome: "After a few weeks of painstaking back and forth with CI and lots of iteration, we ended up with what we needed: a branch where all the permissions were expressed in policies and all tests passing in CI/CD."

Relationship to other shadow / dual-run patterns

• patterns/shadow-migration — runs both systems against live production and statistically reconciles. Policy PoC branch is pre-production: only the existing test suite, no real traffic.
• patterns/shadow-validation-dependency-graph — runs the new derived structure alongside the live authoritative path and reports divergences. Also production-time; again, policy PoC is earlier.
• These compose. Figma's full journey was likely: PoC branch → shadow against production before flipping evaluator read path → live switchover (shadow-migration step not explicitly documented in the source article, but structurally implied by the eventual production rollout).

Caveats

• Throwaway work is an upfront cost. Engineering time spent on a branch that gets discarded is a "wasted" investment unless the team values the design insights as first-class output (Figma explicitly did).
• Test suite quality is a prerequisite. A green PoC branch is only as meaningful as the test coverage it passes. If the existing test suite doesn't exercise the real edge cases, green-on-branch is a false signal.
• The first PoC's design will probably be wrong. Figma's was; the iteration is what pays off.

Seen in

• sources/2026-04-21-figma-how-we-built-a-custom-permissions-dsl — named as "the biggest step to de-risk the project." First PoC ported every existing has_access? method into AccessControlPolicy + apply? and hit green; revealed the attached_through + imperative-function limitations that drove the pivot to JSON-serializable ExpressionDef.