prometeu-studio/docs/pbs/agendas/17.1. Compatibility Workshop 1 - Compatibility Domains and Promise Levels.md

PBS Compatibility Workshop 1

Status: Active

Purpose

Run the first focused discussion for 17. Compatibility and Evolution Policy.md on the top-level policy model:

• which compatibility domains PBS recognizes,
• and what strength of promise applies to each.

Why This Slice First

This slice should come first because every deprecation, migration, and matrix policy depends on a clean definition of domains and promise levels.

Proposed Meeting Order

1. Reconfirm already-settled governance and versioning inputs.
2. Close the compatibility domains.
3. Close the promise level for each domain.
4. Close behavioral versus binary compatibility terminology.
5. Record migration and matrix issues for later workshops.

Decisions To Produce

1. The compatibility domains PBS speaks about normatively.
2. The promise level for each domain.
3. The behavioral versus binary compatibility split.
4. The relationship between claim level and compatibility promise.

Candidate Decisions

1. Recognize Separate Domains

Candidate direction:

• PBS should distinguish at least: source compatibility, stdlib compatibility, cartridge/runtime compatibility, artifact compatibility, and conformance-claim compatibility.

Rationale:

• Different breakages affect different users and toolchains.

2. Promise Strength Differs By Domain

Candidate direction:

• source and published-cartridge behavior get the strongest promise,
• stdlib and artifact domains may have tighter line-based conditions,
• partial conformance claims get narrower promises than full ones.

Rationale:

• This avoids one vague compatibility slogan that means too many things.

3. Separate Behavioral From Binary Compatibility

Candidate direction:

• source-level and runtime-observable behavior compatibility is not the same as artifact binary compatibility,
• and the policy should state both explicitly.

Rationale:

• This prevents PBX policy from silently driving all evolution policy.

Questions To Resolve In The Room

1. What are the minimum compatibility domains that PBS must name explicitly?
2. Which domains deserve the strongest guarantees?
3. Is cartridge compatibility mainly behavioral, binary, or both?
4. How does staged conformance affect compatibility promises?
5. Does stdlib compatibility belong as its own domain or inside source compatibility?

Expected Outputs

1. a decision record for compatibility domains,
2. a promise-level matrix draft,
3. and terminology targets for 17.

Explicit Deferrals For Workshop 2

• deprecation windows,
• migration-tooling duties,
• and artifact-line change policy.

Inputs

• docs/pbs/specs/2. Governance and Versioning.md
• docs/pbs/specs/13. Conformance Test Specification.md
• docs/pbs/specs/17. Compatibility and Evolution Policy.md
• docs/pbs/decisions/Conformance Claim Levels Decision.md
• docs/pbs/agendas/17. Compatibility and Evolution Policy Agenda.md