Compatibility and evidence¶
ASIF 0.4 is a proposal with two locally authored reference implementations. This page separates executable checks, authored scenarios and integration work. It is not a list of certified providers. Both reference implementations share authorship; independent exchange evidence remains zero.
Capability matrix¶
| Capability | Python reference | TypeScript reference | Evidence and limits |
|---|---|---|---|
| Parse and validate ASIF sessions | Implemented subset | Implemented subset | Structure and selected semantic invariants; Python results, TypeScript results. Full semantic coverage remains open. |
| Project a selected request context | Implemented | Implemented | Ordered typed inputs, resource references, tools and settings; no provider encoding or measured token budget. |
| Exchange packages and signatures | Locally checked | Locally checked | Bidirectional local checks; shared authorship, no independent interoperability claim. |
| Restore selected plain file trees | Implemented subset | Implemented subset | Fresh destination only; Git administration, symlinks and native stores are unsupported. |
| Assess continuation declarations | Implemented subset | Implemented subset | Synthetic reports; no live capability, credential or account verification. |
| Represent agents with different roles | Synthetic fixture checked | Synthetic fixture checked | Shared-brief example; no real providers or live coordination. |
| Export real native agent sessions | Not implemented | Not implemented | Requires a source adapter and stable identity mappings. |
| Import into a native agent and continue | Not implemented | Not implemented | Requires a destination adapter, authorization and observed next-interaction evidence. |
| Independent session exchange | Not demonstrated | Not demonstrated | Requires independently authored implementations and independently produced sessions. |
The reference guide describes numeric, archive and path-pattern differences. Successful validation establishes only the stated check scope.
What a provider support claim needs¶
A named provider or runtime belongs in a compatibility report only after an implementer supplies reproducible evidence. Record source and destination versions, adapter revision, ASIF/profile versions, transferred fields, unsupported state and results for each direction. A successful export does not establish import or continuation support.
An adapter can start with a narrow claim such as readable conversation and resource export. If effective model inputs are unknown, label their fidelity accordingly. Expand the claim as additional capabilities are demonstrated. Use the adapter guide and implementation evidence record.
Next evidence milestones¶
- Export a real source session with a documented mapping and a sanitized, reproducible fixture.
- Assess it for a named destination; make supported, adapted and blocked subjects explicit.
- Demonstrate an authorized next interaction and export its results back with stable identities and recorded losses.
- Have an independently authored implementation repeat the exchange with its own source session.
These are desired evidence milestones, not scheduled releases or completed work. GAPS.md tracks outstanding implementation and release requirements; governance defines proposed maturity gates.