Baseline belongs in architecture decisions

A browser feature becoming available does not automatically make it the right architecture.

The Navigation API, service-worker modules, container queries, popovers, and other platform capabilities can remove code and improve semantics. They can also create compatibility gaps, incomplete fallback paths, and testing obligations if the team does not connect availability to its actual audience.

Baseline 2026 gives developers a clearer view of features available across major browser engines. I want that signal inside an architecture decision record alongside product need, audience data, progressive enhancement, and removal of the old path.

Baseline answers whether a feature has broad platform availability. The product team still has to answer whether its users, constraints, and failure modes make adoption appropriate today.

That is where modern CSS and web APIs become engineering judgment instead of demo code.

Start with the user need

Architecture should explain which product behavior or maintenance cost the platform feature improves.

I would pressure-test that decision with four questions:

• What becomes better?
• Who experiences it?
• What code can disappear?
• What happens without it?

The failure mode here is adopting a feature because it reached a compatibility milestone. In frontend architecture where teams choose between native web platform features, progressive enhancement, polyfills, libraries, fallbacks, and browser support promises that affect performance and maintenance, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a user-need statement at the top of the decision. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a platform choice tied to useful product change. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a user-need statement at the top of the decision beside the question “What becomes better?” before the first implementation review. The next pass would use “Who experiences it?” to test the boundary, then “What code can disappear?” to expose the state most likely to be missed. I would keep “What happens without it?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a platform choice tied to useful product change.

Read the Baseline status correctly

Newly available and widely available describe platform reach, not the complete support promise of one product.

The practical review starts here:

• What status applies?
• Which engines are included?
• When did availability begin?
• Does the feature have partial behavior?

Those questions keep treating a badge as universal historical support from becoming the default. I would capture the decision in a dated Baseline status reference, then use it while the work is still cheap to change. For durable frontend architecture, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like a more accurate compatibility assumption. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a dated Baseline status reference part of the working surface. I would use it to answer “What status applies?” while scope is still flexible, and “Which engines are included?” before code or content becomes expensive to unwind. During QA, “When did availability begin?” and “Does the feature have partial behavior?” become concrete checks rather than discussion prompts. That sequence turns durable frontend architecture into something the team can operate and gives me a specific outcome to report: a more accurate compatibility assumption.

Compare audience evidence

Product analytics, enterprise requirements, embedded webviews, and assistive technology can matter more than global browser share.

Before implementation, I would answer:

• Which browsers do users run?
• Are webviews involved?
• Which contracts promise support?
• Which cohort faces exclusion?

The artifact is an audience support table beside the Baseline signal. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is using worldwide averages for a specific product; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is adoption timed to the real audience. That connects Web Platform Baseline as one input to an explicit compatibility decision rather than a trivia badge to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which browsers do users run?” easy to answer. The boundary should force a decision about “Are webviews involved?” and “Which contracts promise support?.” I would record both in an audience support table beside the Baseline signal, including the part that stayed unresolved after the first pass. The final check, “Which cohort faces exclusion?,” is where the artifact earns its place: it either supports adoption timed to the real audience, or it shows exactly why another iteration is needed.

Design progressive enhancement

The baseline experience should complete the task before the enhanced feature adds convenience or polish.

I would use these prompts during the working review:

• Can the core action finish?
• What semantic HTML remains?
• Does server navigation work?
• Which enhancement is optional?

If the team slips into calling a broken fallback progressive enhancement, the product can still look complete while its operating rule stays ambiguous. I would make a baseline-versus-enhanced behavior map the shared reference and keep it small enough to update as evidence changes.

The standard is a product that remains useful under capability differences. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a baseline-versus-enhanced behavior map, review it against “Can the core action finish?,” implement the narrowest useful path, and then return with evidence for “What semantic HTML remains?.” I would use “Does server navigation work?” to inspect product consequence and “Which enhancement is optional?” to decide whether the result is stable enough to ship. This keeps calling a broken fallback progressive enhancement visible as a known risk and makes a product that remains useful under capability differences the release receipt rather than a hopeful conclusion.

Treat polyfills as dependencies

A polyfill adds code, execution, compatibility assumptions, and removal work that need the same review as a library.

I would pressure-test that decision with four questions:

• How large is it?
• What globals change?
• Does it fully match behavior?
• Who removes it?

The failure mode here is adding compatibility code with no lifecycle owner. In frontend architecture where teams choose between native web platform features, progressive enhancement, polyfills, libraries, fallbacks, and browser support promises that affect performance and maintenance, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a polyfill receipt with exit condition. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is less permanent fallback infrastructure. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a polyfill receipt with exit condition beside the question “How large is it?” before the first implementation review. The next pass would use “What globals change?” to test the boundary, then “Does it fully match behavior?” to expose the state most likely to be missed. I would keep “Who removes it?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports less permanent fallback infrastructure.

Test behavior, not detection

Capability detection can pass while semantics, focus, history, performance, or error recovery still fail.

The practical review starts here:

• Does the task complete?
• Is focus correct?
• Does history behave?
• Can the enhanced path recover?

Those questions keep testing only whether the API exists from becoming the default. I would capture the decision in a cross-browser behavior matrix, then use it while the work is still cheap to change. For durable frontend architecture, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like evidence that both paths keep the product contract. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a cross-browser behavior matrix part of the working surface. I would use it to answer “Does the task complete?” while scope is still flexible, and “Is focus correct?” before code or content becomes expensive to unwind. During QA, “Does history behave?” and “Can the enhanced path recover?” become concrete checks rather than discussion prompts. That sequence turns durable frontend architecture into something the team can operate and gives me a specific outcome to report: evidence that both paths keep the product contract.

Include accessibility support

Browser availability does not guarantee consistent assistive-technology behavior or an accessible interaction model.

Before implementation, I would answer:

• Which semantics exist?
• How does keyboard interaction work?
• What is announced?
• Which combinations were tested?

The artifact is an accessibility test note for native and fallback paths. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is assuming native automatically means accessible in every use; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is more dependable inclusive behavior. That connects Web Platform Baseline as one input to an explicit compatibility decision rather than a trivia badge to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which semantics exist?” easy to answer. The boundary should force a decision about “How does keyboard interaction work?” and “What is announced?.” I would record both in an accessibility test note for native and fallback paths, including the part that stayed unresolved after the first pass. The final check, “Which combinations were tested?,” is where the artifact earns its place: it either supports more dependable inclusive behavior, or it shows exactly why another iteration is needed.

Measure bundle and runtime impact

Native platform adoption should reduce shipped code or complexity, not create a permanent duplicate system.

I would use these prompts during the working review:

• What code is removed?
• What branch remains?
• Does performance improve?
• How much test surface grows?

If the team slips into keeping the old library and adding the native feature beside it forever, the product can still look complete while its operating rule stays ambiguous. I would make a before-and-after bundle and complexity receipt the shared reference and keep it small enough to update as evidence changes.

The standard is platform adoption that simplifies the product. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a before-and-after bundle and complexity receipt, review it against “What code is removed?,” implement the narrowest useful path, and then return with evidence for “What branch remains?.” I would use “Does performance improve?” to inspect product consequence and “How much test surface grows?” to decide whether the result is stable enough to ship. This keeps keeping the old library and adding the native feature beside it forever visible as a known risk and makes platform adoption that simplifies the product the release receipt rather than a hopeful conclusion.

Plan the removal review

Every fallback, polyfill, and compatibility branch needs a date and evidence threshold for reconsideration.

I would pressure-test that decision with four questions:

• When is support reviewed?
• Which usage threshold matters?
• Who owns deletion?
• What documentation changes?

The failure mode here is making temporary compatibility code permanent by default. In frontend architecture where teams choose between native web platform features, progressive enhancement, polyfills, libraries, fallbacks, and browser support promises that affect performance and maintenance, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a revisit issue linked from the decision. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is an architecture that becomes smaller as the platform matures. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a revisit issue linked from the decision beside the question “When is support reviewed?” before the first implementation review. The next pass would use “Which usage threshold matters?” to test the boundary, then “Who owns deletion?” to expose the state most likely to be missed. I would keep “What documentation changes?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports an architecture that becomes smaller as the platform matures.

Show browser judgment as proof

A portfolio artifact can connect a modern feature, audience evidence, fallback, cross-browser tests, and eventual code deletion.

The practical review starts here:

• Why was the feature chosen?
• Who needed fallback?
• What complexity left?
• Which behavior was verified?

Those questions keep listing browser APIs without the support decision behind them from becoming the default. I would capture the decision in a Baseline decision record with the rendered paths, then use it while the work is still cheap to change. For durable frontend architecture, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like credible evidence of durable frontend engineering. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a Baseline decision record with the rendered paths part of the working surface. I would use it to answer “Why was the feature chosen?” while scope is still flexible, and “Who needed fallback?” before code or content becomes expensive to unwind. During QA, “What complexity left?” and “Which behavior was verified?” become concrete checks rather than discussion prompts. That sequence turns durable frontend architecture into something the team can operate and gives me a specific outcome to report: credible evidence of durable frontend engineering.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a user-need statement at the top of the decision
• a dated Baseline status reference
• an audience support table beside the Baseline signal
• a baseline-versus-enhanced behavior map
• a polyfill receipt with exit condition

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because Web Platform Baseline as one input to an explicit compatibility decision rather than a trivia badge becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# feature
Navigation API for app transitions
Baseline 2026 signal; improves cancellation and route lifecycle for supported browsers.
# fallback
server links plus current router
Core navigation, history, focus, and analytics remain correct without the enhancement.
# revisit
Q1 2027 support review
Track fallback share, errors, bundle delta, embedded webviews, and removal issue owner.

Resource path

The practical follow-up I would build is a Baseline architecture decision record with user need, feature, availability status, audience support data, fallback, enhancement boundary, bundle impact, accessibility, test matrix, owner, and revisit date. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• What becomes better?
• What status applies?
• Which browsers do users run?
• Can the core action finish?
• How large is it?
• Does the task complete?
• Which semantics exist?
• What code is removed?
• When is support reviewed?
• Why was the feature chosen?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For durable frontend architecture, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• evidence that both paths keep the product contract
• more dependable inclusive behavior
• platform adoption that simplifies the product
• an architecture that becomes smaller as the platform matures
• credible evidence of durable frontend engineering

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• A Baseline decision connects platform availability to product support.
• Platform adoption should remove complexity over time.
• Availability and consequence create different adoption choices.
• The Baseline record should make deletion part of adoption.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to frontend architecture where teams choose between native web platform features, progressive enhancement, polyfills, libraries, fallbacks, and browser support promises that affect performance and maintenance: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through Web Platform Baseline as one input to an explicit compatibility decision rather than a trivia badge. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

A Baseline decision record is a hiring signal because it shows I can use modern browser capabilities without confusing novelty, availability, and product support.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.