Baseline browser compatibility: an audit framework for custom AI web systems

Baseline is a shared way to describe whether web-platform features are supported across a defined set of core browsers. Google’s web.dev documentation identifies three conditions: Limited availability, Newly available and Widely available. Newly available applies once a feature works across the entire core set. Widely available applies after the documented maturity interval of 30 months from that point.

The practical answer is to connect those statuses to release decisions. A public marketing journey may require Widely available features or a tested fallback, while an authenticated application can sometimes accept a newer feature if its actual browser population supports it. That policy is CreatikLab methodology, not a promise made by Baseline. Baseline does not certify conversion tracking, accessibility, speed, security or commercial performance.

Chrome initiated Baseline, while its definition is now governed by the WebDX Community Group. The core set covers Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS. A feature remains in Limited availability before it works across that set. Newly available marks interoperability across the set, while Widely available includes the documented 30-month maturity period.

The official page also identifies implementation tools. Lighthouse includes a Baseline Features audit; Browserslist supports Baseline queries; Visual Studio Code and Chrome DevTools expose Baseline information; and ESLint can enforce Baseline CSS usage. Baseline Checker can use Google Analytics data to help select a target. These capabilities establish an evidence layer, but the official guidance does not specify which target every business should choose or guarantee that a compatible feature works correctly in a particular product journey.

Custom AI systems often combine a conventional website with streaming interfaces, interactive forms, account areas, browser APIs and third-party measurement. The engineering risk is not simply that a page fails everywhere. More often, one unsupported feature weakens a critical step for a subset of visitors: a control does not respond, a generated answer cannot be copied, a form state disappears, or a measurement event never fires. Those are diagnostic scenarios, not claims about Baseline behavior.

Compatibility therefore needs an owner before development begins. Product should define the journeys that cannot fail. Marketing should identify paid and organic entry pages. Engineering should record feature dependencies. Analytics should verify that observed browser usage is trustworthy. Baseline then supplies a common vocabulary for discussing support instead of relying on statements such as “works on modern browsers,” which are too ambiguous for release approval.

The CreatikLab decision framework considers journey criticality, audience evidence, fallback quality and the consequence of failure. It deliberately separates official Baseline status from the business decision made on top of it.

• Public acquisition page — evidence: browser distribution, landing-page entries and the lead or revenue path; decision: prefer Widely available features or provide an equivalent fallback; owners: marketing and frontend engineering.
• Authenticated tool — evidence: supported-device policy and actual user environment; decision: Newly available may be considered when audience evidence and regression tests support it; owners: product and engineering.
• Internal operational interface — evidence: managed browser inventory; decision: a narrower compatibility policy may be acceptable when it is documented and enforced; owners: IT and product.
• Experimental AI interaction — evidence: feature flag, failure telemetry and fallback path; decision: isolate Limited availability features from essential actions; owners: engineering and product.
• Shared design system — evidence: component inventory and dependency map; decision: prevent an unsupported primitive from spreading through multiple journeys; owners: design systems and engineering.

This matrix is not a universal browser-support rule. It is a governance method for turning compatibility evidence into an accountable choice.

Start by defining the browser-support policy in the repository and release documentation. Name the selected Baseline target, the exceptions process and the journeys considered essential. Configure compatible tooling where appropriate, such as Browserslist queries or CSS linting, so the policy is checked during development rather than remembered at final QA.

1. Inventory web-platform features used by critical components, including forms, navigation, media, authentication and AI response interfaces.
2. Run the Lighthouse Baseline Features audit on representative templates and record findings as release evidence.
3. Inspect flagged CSS in supported development tools and trace each feature to the component and user journey that depends on it.
4. Choose whether to replace the feature, progressively enhance the experience, add a fallback or document an approved audience limitation.
5. Test the production build in the browsers covered by the organisation’s policy; a status label does not replace functional testing.
6. Store the decision, evidence, owner and retest condition with the release record.

The workflow creates an auditable chain from feature status to business consequence. It does not assume that automated checks can judge usability.

A compatibility programme should be measured at journey level. Capture browser family and version only within the organisation’s privacy and consent rules. Compare page loads, interaction completion, form validation, submission success, authentication completion and client-side error patterns across supported environments. For lead generation, connect successful submissions to CRM outcomes so a technically completed form is not mistaken for a qualified opportunity.

Use a measurement specification with four fields: event, diagnostic dimension, business interpretation and owner. For example, form submission is the event; browser environment and component version are diagnostic dimensions; accepted sales opportunity is the business interpretation; analytics and revenue operations share ownership. Investigate gaps rather than declaring causation from a browser correlation alone.

Baseline status should appear in release reporting as engineering context, not as a success metric. The commercial metrics remain completed journeys, qualified leads, valid purchases or other explicitly agreed outcomes. No official Baseline guidance promises improvements in those outcomes.

• Evidence: written browser-support policy. Action: define the Baseline target and exception criteria. Owner: product lead.
• Evidence: analytics-derived browser distribution with consent controls. Action: compare the policy with the real audience. Owner: analytics lead.
• Evidence: component and feature inventory. Action: map platform features to critical journeys. Owner: frontend lead.
• Evidence: Lighthouse Baseline audit output. Action: triage findings by journey impact rather than raw count. Owner: QA lead.
• Evidence: Browserslist, linting or editor configuration. Action: make policy drift visible during development. Owner: engineering lead.
• Evidence: fallback demonstrations. Action: verify that essential actions remain possible when enhancement is unavailable. Owner: QA and design.
• Evidence: error and completion telemetry. Action: investigate environment-specific abandonment without assuming causation. Owner: analytics and engineering.
• Evidence: release decision log. Action: record acceptance, remediation, responsible person and retest trigger. Owner: product operations.

A provider should be able to show this evidence, not merely promise cross-browser quality. Buyers should compare the clarity of the support policy, test coverage, exception handling, measurement design and handover documentation.

Do not assume that Widely available means bug-free, accessible, fast or visually identical in every environment. Do not assume that Newly available is unsafe, or that Limited availability can never be used. The decision depends on the audience, journey, fallback and cost of failure. Do not infer support for embedded browsers, unusual devices or third-party scripts unless they are tested under the project’s own policy. The official Baseline page does not specify prices, product eligibility or business-performance outcomes.

For an AI automation or custom-systems engagement, a concrete expert deliverable to define in the project scope is a compatibility decision pack: browser-support policy, feature inventory, Baseline findings, critical-journey test record, fallback decisions, telemetry specification and a remediation register with evidence, action and owner. Explore AI automation and custom systems and confirm scope and availability before commissioning work. To prepare an actionable request, open Lia in MarketingPro and submit the critical journeys, known audience browsers, current test evidence and points of failure or uncertainty. Do not include confidential credentials or personal data.

What is Baseline in web development?

Baseline describes the cross-browser availability of web-platform features using Limited availability, Newly available and Widely available statuses.

Which browsers are included in the core Baseline set?

The official set covers Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS.

Does Widely available guarantee that a feature is bug-free?

No. It describes availability and maturity across the core browser set, not implementation quality, accessibility, speed or freedom from browser defects.

Can a business use Newly available features?

Potentially, if audience evidence, criticality, fallback quality and functional testing support that decision. Baseline does not prescribe one target for every organisation.

Which tools can help enforce a Baseline policy?

The official guidance identifies tools including Lighthouse, Browserslist, Visual Studio Code, Chrome DevTools, ESLint and Baseline Checker.

How should compatibility be linked to lead quality?

Measure journey completion by environment, then connect valid submissions to CRM qualification. Browser correlation should trigger investigation rather than an automatic causal conclusion.