prometeu-studio/docs/pbs/agendas/17.4. Compatibility Workshop 4 - Artifact and PBX Compatibility Policy.md

PBS Compatibility Workshop 4

Status: Active

Purpose

Run the fourth focused discussion for 17. Compatibility and Evolution Policy.md on artifact compatibility:

• PBX compatibility,
• runtime-loading compatibility,
• and how artifact-line changes are versioned and promised.

Why This Slice Last

This slice should come last because artifact policy is the most backend-dependent and should be informed by the broader domain and matrix decisions first.

Proposed Meeting Order

1. Reconfirm the source, stdlib, cartridge, and matrix policy already chosen.
2. Decide whether artifact compatibility is an independent policy track.
3. Decide PBX and runtime-loading promise boundaries.
4. Decide how artifact-line changes are versioned and communicated.
5. Record final integration tasks for 17, 15, and 19.

Decisions To Produce

1. Whether artifact compatibility is independent from source compatibility.
2. The promise boundary for PBX and loader compatibility.
3. The versioning and communication policy for artifact-line changes.
4. The relationship between artifact policy and published cartridge support.

Candidate Decisions

1. Artifact Compatibility Is A Distinct Policy Track

Candidate direction:

• PBX and emitted-artifact compatibility should be named explicitly rather than assumed from source compatibility.

Rationale:

• Binary and loader compatibility carry different risks and evolution constraints.

2. Runtime Loading Promise Must Be Stated By Supported Line

Candidate direction:

• artifact compatibility should be expressed against explicit runtime and artifact lines,
• not as a timeless blanket guarantee.

Rationale:

• This keeps the promise honest and testable.

3. Artifact-Line Breaks Require Explicit Version Signaling

Candidate direction:

• incompatible artifact changes require an explicit line or major-boundary signal,
• plus migration or tooling guidance when older published cartridges are affected.

Rationale:

• This aligns artifact evolution with the broader compatibility policy.

Questions To Resolve In The Room

1. How strong should PBX compatibility promises be?
2. Are published cartridges protected mainly by source compatibility or by explicit artifact-line support?
3. What counts as an artifact compatibility break?
4. Must artifact-line changes always align with major language-version changes?
5. How should loader support boundaries be documented and tested?

Expected Outputs

1. a decision record for artifact compatibility policy,
2. a PBX/runtime promise note,
3. and final section targets for 17.

Explicit Deferrals

• exact PBX layout details,
• exact loader algorithms,
• and binary test harness implementation.

Inputs

• docs/pbs/specs/6.2. Host ABI Binding and Loader Resolution Specification.md
• docs/pbs/specs/13. Conformance Test Specification.md
• docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md
• docs/pbs/specs/17. Compatibility and Evolution Policy.md
• docs/pbs/specs/19. Verification and Safety Checks Specification.md
• docs/pbs/agendas/17.3. Compatibility Workshop 3 - Compatibility Matrices and Published Claims.md