Appropriate use
Use when planning cross-platform coverage, defining supported combinations, onboarding hardware, or evaluating release exposure.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use to imply untested combinations are safe, treat vendor labels as equivalent environments, or create an unlimited Cartesian product without prioritisation.
- 8
- versioned workflow phases
- 3
- explicit approval gates
- 6
- defined result states
- 9
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Support-policy preflight Gate 1 · approve source set
Resolve officially supported platforms, minimum versions, deprecation policy, customer concentration, contractual commitments, and available laboratory inventory.
support policy · telemetry · inventory · contract · deprecation
Phase 2: Dimension discovery
List meaningful dimensions such as player type, browser engine, OS, device model, firmware, chipset, orientation, resolution, role, tenant, region, network, and feature flags.
dimensions · allowed values · unknowns · aliases
Phase 3: Equivalence-group analysis
Group combinations only when architecture, rendering engine, API behaviour, hardware capability, and historical evidence support equivalence.
equivalence rule · evidence · exceptions · expiry
Phase 4: Risk enrichment
Add usage share, defect history, incident history, update fragmentation, hardware variance, accessibility, performance, security, and customer criticality.
risk score · confidence · customer exposure
Phase 5: Coverage selection
Select required, representative, optional, deprecated, unsupported, and unavailable combinations using explicit rules.
must test · representative · sample · exclude · reason
Phase 6: Laboratory feasibility
Map combinations to real devices, emulators, cloud browsers, remote labs, customer-assisted checks, or unavailable coverage.
asset ID · owner · access · firmware · availability
Phase 7: Review and approval Gate 2 · approve matrix
Present coverage, equivalence assumptions, unavailable combinations, residual risk, maintenance owner, and review cadence.
coverage tiers · gaps · owner · next review
Phase 8: Publish and maintain Gate 3 · publish matrix
Generate machine-readable and human views, assign stable platform IDs, and invalidate entries when support policy, telemetry, firmware, or architecture changes.
matrix version · platform IDs · change log · expiry
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve source set | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve matrix | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · publish matrix | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
REQUIRED
This combination must pass for the defined release or support commitment.
REPRESENTATIVE
This combination represents an evidence-backed equivalence group.
OPTIONAL
Coverage adds confidence but is not required by current policy.
UNAVAILABLE
The combination is supported or material but no valid test path exists.
DEPRECATED
The combination is in an approved removal period with explicit expectations.
UNSUPPORTED
The combination is outside the current support policy.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Support commitment | Versioned policy or contract | The scope and effective dates are explicit. |
| Usage | Version-attributed telemetry | Sample, region, and freshness are known. |
| Equivalence | Architecture and historical evidence | Why one combination represents another is documented. |
| Device identity | Asset and firmware inventory | Model aliases and hardware revisions are normalised. |
| Risk | Defect and incident references | Historical signals remain relevant to the current architecture. |
| Coverage status | Execution reports | Last-tested build, date, and outcome are linked. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
No unsupported inference
Same OS major version does not automatically mean equivalent browser, firmware, or hardware behaviour.
Runtime control
Telemetry privacy
Usage data is aggregated and access-controlled.
Runtime control
Expiry
Equivalence and representative choices expire and require review.
Runtime control
Inventory integrity
Real device firmware and hardware revision are recorded, not assumed from marketing name.
Runtime control
Visible gaps
Unavailable supported combinations remain risks rather than disappearing from coverage percentage.
Runtime control
Change invalidation
Vendor updates, architecture changes, or support-policy changes trigger review.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
MATRIX INVALID
Sources, identifiers, or support policy are too inconsistent to rely on.
CRITICAL GAPS
Required supported combinations lack a valid test path.
APPROVED WITH GAPS
Known unavailable or optional combinations have accepted residual risk.
APPROVED
Required coverage and equivalence rationale are current and executable.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Real customer fleets may contain undocumented firmware and hardware revisions.
- Limit 2. Usage telemetry can underrepresent offline or privacy-restricted devices.
- Limit 3. Cloud browsers do not reproduce hardware decoding and embedded-player behaviour.
- Limit 4. Vendor updates can change behaviour without an application release.
- Limit 5. Regional services and network policies can create additional dimensions.
- Limit 6. The matrix needs an owner and review cadence or it will become stale.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
matrix-context.jsonVersioned output produced by the workflow.
dimension-catalog.yamlVersioned output produced by the workflow.
platform-inventory.csvVersioned output produced by the workflow.
equivalence-groups.yamlVersioned output produced by the workflow.
risk-register.yamlVersioned output produced by the workflow.
coverage-matrix.csvVersioned output produced by the workflow.
gaps.mdVersioned output produced by the workflow.
matrix-review.jsonlVersioned output produced by the workflow.
platform-matrix.htmlVersioned output produced by the workflow.
artifacts/qa/platform-matrix/<run-id>/ ├── matrix-context.json ├── dimension-catalog.yaml ├── platform-inventory.csv ├── equivalence-groups.yaml ├── risk-register.yaml ├── coverage-matrix.csv ├── gaps.md ├── matrix-review.jsonl └── platform-matrix.html
Example
Example request and controlled output
Input
Create a platform matrix for YouTube playback across SCOS, PIXI, Tizen 4/6.5/7, webOS 4/6, Chrome, Windows, and Android.
Output excerpt
Matrix status: APPROVED WITH GAPS Required separate groups: - Tizen 4 - Tizen 6.5 - Tizen 7 - webOS 4 - webOS 6 - SCOS - PIXI - Android - Desktop Chromium Gap: No valid webOS 4 laboratory device is currently available. Important: Tizen versions are not treated as one equivalence group because observed embedded-content behaviour differs materially.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/platform-matrix
Builds and maintains a defensible compatibility matrix across browsers, operating systems, devices, firmware, resolutions, roles, regions, and feature states.