The status model

What the parity matrix's statuses mean — Native, Shimmed, Consumed, Lifecycle alternative, Partial, Missing — and how covered/gap, implemented/verified, and public/internal relate.

The parity matrix uses a small, deliberate vocabulary. This page defines it — and the principle that produces it.

The governing principle

Every WebDriver BiDi capability must be reachable through the engine. Only capabilities representing a useful user intention should receive dedicated CLI commands or MCP tools.

Engine implementation status

How a specification capability is realized inside the bl engine:

Status	Meaning	Counts as covered?
Native	The engine integrates the BiDi command or event directly.	Yes
Shimmed	The user intention is met another way — e.g. an injected-script or request-interception shim — while a native integration may still be desirable.	Yes
Consumed event	The engine subscribes to and routes the event internally to power features like auto-waiting, recordings, or dialog handling.	Yes
Lifecycle alternative	The intention is served by browserlane's own lifecycle machinery (daemon, process teardown) rather than the spec command.	Yes
Partial	Some of the capability's surface is reachable, some is not.	Counted per the matrix — read the row
Missing	No integration identified in the engine. This is a real gap.	No

Native, shimmed, consumed, and lifecycle-alternative are deliberately not flattened into one label: the matrix shows which kind of coverage each capability has, and the expanded row describes the implementation.

Covered vs. gap

Covered means the capability is reachable through the engine by one of the mechanisms above. Gap means it is not — the engine cannot serve that capability today. The engine coverage percentage is simply covered ÷ total. Gaps are listed in the matrix like everything else; tracking them publicly is the point.

Implemented vs. verified

Implementation and proof are separate columns:

Test status (engine): whether a direct parity test exists — Verified, Test pending (implemented, direct test still needed), or Not tested.
Chrome verification: whether the integration has been exercised against Chrome at runtime — Verified, Integrated · test pending, or Not integrated.

A capability can be genuinely implemented and still show pending verification. The matrix never upgrades "implemented" to "verified" without evidence.

Chrome browser support vs. Browserlane on Chrome

Two independent facts per capability:

Chrome browser BiDi — what Chrome itself implements. Recorded as Not verified until confirmed against WPT results or a runtime check; browser support is evidence-gated, never assumed.
Browserlane on Chrome — whether browserlane's integration of the capability works against Chrome.

A capability could be missing in the engine while Chrome supports it, or integrated in the engine while Chrome's own support is unverified. Conflating the two would hide exactly the information the matrix exists to show.

Exposure: public, advanced, internal, raw, admin

The exposure decision records what kind of dedicated surface a capability earns, per the governing principle:

Decision	Meaning
Semantic public	A first-class, everyday CLI command / MCP tool expresses this intention.
Advanced public	Exposed for advanced or debugging use.
Internal	Reachable through the engine only — no dedicated surface, by design.
Raw only	Only sensible as a raw protocol passthrough.
Admin	Operational surface (setup, daemon, wiring).

The CLI and MCP columns then record what actually ships today for that intention (Shipped, Proposed, Internal, Not exposed) and at which exposure level. A capability marked Internal is not a gap — engine parity and surface exposure answer different questions.

Skill status

The Skill is not another protocol implementation — it teaches an agent token-efficient CLI workflows. Its column therefore records documentation status, derived from the CLI surface:

Documented — a user-facing CLI workflow exists for this intention, so the Skill's CLI teaching reaches it.
Planned — a CLI workflow is proposed but not shipped.
N/A — engine-internal plumbing with no user-facing CLI intention.

Where the data lives

The matrix renders from a canonical, machine-readable dataset checked into the repository (parity/bidi-parity.json), validated on every site build — duplicate IDs, unknown statuses, inconsistent totals, or covered capabilities without an implementation description fail the build. Every number on this site is computed from that data, so the pages update as coverage changes.