Before the component

Independent public study. This project is not affiliated with Netflix, was created without Netflix internal access, and does not describe Netflix policy. Its rules and classifications are prototype proposals.

Open the live study · Inspect the source contract

Before a component is chosen, what has already been decided?

Public material about Hawkins shows how a design system can create, extend, maintain, and release reusable components. Without making claims about Netflix's internal practice, this study proposes a layer above that public lifecycle: deciding what kind of experience a situation calls for before a component is selected.

It asks three questions:

• What must this moment help someone do?
• What content must remain true?
• Who has enough context and authority to decide the rest?

The result is not merely a component recommendation. It is a combined response—component, language, behavior, accessibility, reasons, and receipt—that makes the shared system, a domain extension, and human judgment legible before implementation begins.

Try the 90-second path

1. Repair one exact collection-label failure and watch the rule run again.
2. Continue to a destructive decision whose exact checks pass but whose risk still requires a person.
3. Continue to a Games interruption that is UNKNOWN until its scoped extension is enabled.
4. Inspect or download the receipt that records each route, rule, owner, and status.

The study includes three deliberately different experience kinds:

Situation kind	Prototype identifier	What the experience must accomplish
Discovery	discovery.collection_row	Help someone understand and explore a meaningful group of choices.
Decision	decision.destructive_confirmation	Make consequences clear before a difficult-to-reverse action.
Recovery	recovery.blocking_interruption	Explain why progress stopped and offer an accurate next step.

These identifiers are a prototype taxonomy created for this study. They are not Netflix or Hawkins terminology.

What the framework returns

Each situation is routed through four inputs:

• Purpose — the job the experience must do for a person.
• Content — the information, sequence, and language obligations that make that job possible.
• Context — the conditions that can change what is appropriate, such as market, platform, product domain, or consequence.
• Authority — who is qualified to make claims the shared system cannot safely make on its own.

Those inputs produce an experience contract: a small, readable statement of the experience kind, required content moves, shared rules, permitted extensions, constraints, and unresolved human decisions.

The contract and the response are shown together. The goal is not to pretend that a classification can replace judgment; it is to make the boundary around judgment explicit.

One response, three kinds of ownership

The framework separates responsibility without separating the resulting experience:

• Shared base — reusable intent, required content moves, terminology, accessibility obligations, and rules that should remain consistent.
• Domain extension — valid context supplied by a product area, market, or specialist community within declared extension points.
• Human decision — claims or tradeoffs that require accountable judgment, especially when legal, policy, localization, safety, or product truth is unsettled.

A domain extension may add accurate context. It cannot silently remove the obligations of the shared base. When the available evidence is insufficient, the honest system response is to defer and name the owner—not manufacture certainty.

Four statuses

Every decision receipt uses one of four exact states:

Status	Plain-language meaning
PASS	This response conforms to the active prototype contract.
FAIL	An exact, adopted rule is broken.
REVIEW_REQUIRED	The exact checks hold, but accountable human judgment is still required.
UNKNOWN	The system lacks an authorized kind, locale, extension, or valid contract boundary and emits no final language.

Statuses describe the prototype decision, not the state of any Netflix product or workflow.

Run it locally

Node.js 18 or newer is enough. There are no runtime dependencies and no install step.

git clone https://github.com/calebstacy/before-the-component.git
cd before-the-component
npm run compile
npm test
npm run check
npm start

The scripts are intentionally separate:

• npm run compile builds the public artifact from its source contracts.
• npm test checks the routing rules and expected outcomes.
• npm run check runs the complete release check.
• npm start serves the compiled study locally.

The included local protocol server exposes the same evaluator to an agent:

npm run mcp

Its three tools evaluate a situation, list the active contracts, and verify a receipt. The browser and protocol server call the same source function.

What the artifact proves

Public role problem	Working proof in this repository
Taxonomy and terminology	Three named experience kinds and an exact, repairable collection-label rule.
Language inside component constraints	One response binds component variables, copy, interaction, and accessibility.
Decentralized extensions within shared guardrails	Games adds a recovery kind without editing or overriding the base contract.
Locale, accessibility, and risk boundaries	An unsupported locale fails closed; accessible behavior is checked; a high-risk decision stops for human review.
Portable use by people and agents	A versioned manifest, deterministic receipts, CI, and the local protocol server all use the same evaluator.

What this study does—and does not—claim

This project is shaped by the public responsibilities described in Netflix's Staff Systems Designer, Language posting: structurally encoded language standards, terminology and taxonomy, reusable content-pattern logic, decentralized extensions, cross-functional constraints, and a releasable system for human and agent use.

It is evidence of a proposed method, not evidence about Netflix's internal implementation.

• It does not claim to reproduce Hawkins.
• It does not claim that these rules, identifiers, statuses, or scenarios are used by Netflix.
• It does not use confidential information or internal access.
• It treats Wiki Chaves's Hawkins case study as public practitioner evidence.
• It treats DesignMD's Netflix page as a third-party, reverse-engineered observation—not an official Netflix specification.
• It does not demonstrate production localization, Hawkins integration, or an organizational migration, deprecation, and adoption lifecycle.

See SOURCES.md for the exact public references and evidence boundaries. See spec/FRAMEWORK.md for the framework in plain language.

License

MIT. See LICENSE.