Skip to content

PATTERN Cited by 1 source

End-to-end use case first (platform bring-up)

Pattern

When building a cross-cutting platform (a privacy primitive, a governance system, a new runtime feature) that will eventually serve many customers and many requirement shapes, ship one concrete end-to-end use case first — all the way through all the integration targets — before generalizing. Defer abstraction until at least one customer has flowed through the full stack in production.

Motivation

The pattern's canonical statement is the first "lesson learned" from the 2024-08-31 Meta PAI post:

"Initially, we developed Policy Zones for batch-processing systems with some basic use cases. However, we realized that our designs for function-based systems were quite abstract and the adoption for a large-scale use case resulted in significant challenges, consequently, requiring considerable effort to map patterns to customer needs. Furthermore, refining the APIs and building missing operational support made it work effectively end-to-end across multiple systems. Only after addressing these challenges were we able to make it more generic and proceed with integrating Policy Zones across extensive platforms."

Meta's framing: the function-based design was too abstract before a real large-scale use case flowed through it. The fix required "refining the APIs and building missing operational support" — the kind of work that's invisible until you try to use the platform end-to-end.

Mechanics

  • Pick one real requirement owner + one real data asset + one full pipeline and drive it from annotation → zone creation → violation surfacing → remediation → logging-to-enforcement flip in production.
  • Resist premature generalization. Abstract APIs, pluggable backends, configurable hooks — these earn their keep only once you know what they need to be configurable for.
  • Invest in the missing operational support that the first use case surfaces: Meta's PAI post names "refining the APIs and building missing operational support" as the specific fruits of this approach.
  • Generalize only after the first customer is green.
  • Generalize-first platform — build the abstraction layer before any customer flows through it; the abstractions inevitably don't match real customer needs and need to be rebuilt.
  • Horizontal-slice first — ship step 1 of the pipeline to all customers, then step 2 to all customers. At the end you have no customer live end-to-end; the missing vertical-slice work is still in front of you.

Applicability beyond privacy

The pattern is not Meta-PAI-specific. Any cross-cutting platform (governance, observability, compliance, scheduling, multi-tenancy, feature flagging) can benefit. The Meta PAI post is the canonical wiki statement.

Seen in

Last updated · 319 distilled / 1,201 read