m2-market/docs/fedlearn-coordination.md

Coordination note: m2-market ↔ fedlearn MVP

Addressed to: the fedlearn MVP effort (plan: /home/m2/m2o/.planning/federated-learning/PLAN.md — referenced here, not edited; that plan is fedlearn's to own).

From: m2-market spec 001-market-first-wedge (research.md §R2, §R3, §R5; contracts/apply-adapter.md; contracts/registry-layout.md; data-model.md §Solution).

1. Context

m2-market froze schemas/solution.schema.json v1 on 2026-07-02. This happened because the fedlearn manifest freeze (fedlearn's own Task 1.1) had not landed yet. We verified the same day that none of the expected fedlearn rails exist: no m2/m2-core repo, no capture or curator CLIs. Per the m2-market constitution (Principle VII, "Simplicity & Sequenced Wedges"), blocking indefinitely on an unlanded dependency wasn't an option, so we froze our own side and are coordinating via this note rather than waiting or forking fedlearn's in-flight work (constitution: "consume, not fork").

This is not a request for fedlearn to change direction — it's a record of what we assumed, so fedlearn's actual manifest freeze can either confirm compatibility or tell us we need a v1→v2 migration on our side.

2. The compatibility ask

solution.schema.json v1 embeds a "manifest-core" subset of fields that we shaped to match the fedlearn submission/manifest design as we understood it from the fedlearn plan. When fedlearn's Task 1.1 manifest freeze lands, we're asking that it remain field-compatible with this core — same field names, same types/shapes. Everything outside this list is fedlearn's to define freely; we have no opinion on it.

The frozen manifest-core fields, as they appear in solution.schema.json v1 (specs/001-market-first-wedge/data-model.md §Solution):

Field	Type
schema_version	const string (ours is m2.solution.v1)
applicability.image_classes	array
applicability.roles	array
applicability.tool_requirements	array
tenant_scope	string (m2-core or a tenant id)
evidence	array of {source, excerpt?, machine?, session?, tokens?, wall_time?}
content_hash	string, sha256
scrub_status	object (present when tenant_scope is a tenant id; carries double_scrubbed)

If fedlearn's manifest freeze diverges on any of these (different field name, different shape), tell us — we'll plan a schema migration at integration rather than silently drift.

3. The commercialize seam

When fedlearn's curation pipeline lands, we'd like its commercialize disposition to emit a PR against m2/market-registry (the Forgejo repo we stood up as registry-of-record — see research.md §R2), in the shape defined by specs/001-market-first-wedge/contracts/registry-layout.md §Publish protocol. In short:

• A branch listing/<listing_id> adding/updating listings/<listing_id>/ (a listing.json, a solution.json, and an evidence/ directory).
• A PR carrying an evidence summary, price, a permissions diff, and a rollback note.
• CI validates the PR mechanically (schema-validate against the mirrored frozen schemas, evidence non-empty, tenant-firewall rules, content_hash matches the attached release asset) before any human looks at it.
• Human review resolves via label: veto → closed/back to draft; approved + merge → published, which triggers catalog re-index.

This is the same PR/veto shape m2-market's own listing builders use — fedlearn's commercialize disposition would be just another producer of this PR shape, not a new protocol.

4. The adapter swap

m2-market ships a frozen ApplyAdapter protocol (contracts/apply-adapter.md) with two implementations in v1: local (real, ships now) and m2core-sync (a stub that raises RailsNotLanded, CLI exit 6). When fedlearn's m2-core-sync / m2-core pull --apply lands, it becomes the real backing for the m2core-sync adapter — no changes needed to m2-market's CLI or Store, because they only ever talk to the ApplyAdapter interface.

Acceptance for the swap: all quickstart.md scenarios pass unchanged with adapter = m2core-sync selected (config.toml: apply_adapter = "m2core-sync" or --adapter m2core-sync). See contracts/apply-adapter.md for the full protocol (plan/apply/verify/rollback, all idempotent) and the state-file merge expectation (~/.m2-market/state.json merging with fedlearn's state.json design).

5. What m2-market does NOT need from fedlearn

To keep expectations tight on both sides:

• No ledger. Value movement and balances are m2-market's own m2-ledger service (append-only tx table); fedlearn doesn't need to model credits, payouts, or grants.
• No catalog. market:catalog is a memory-api partition owned and indexed by m2-market-indexer from m2/market-registry; fedlearn's manifest doesn't need catalog- or listing-shaped fields (pricing, seller, revenue split, listing status) — those live only in m2-market's solution.json/listing.json, layered on top of the manifest-core.
• No store dependency. The M2 Store (cargstore fork) talks to market:catalog and shells out to the m2-market CLI for installs; it has no direct dependency on fedlearn services.

Questions about this note → m2-market spec 001-market-first-wedge (research.md §R3, "Open coordination items").