# 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`