Future architecture: model producer/publisher plane and multi-venue release adapters

[mark-e-deyoung]

Purpose

Capture a future requirement without expanding the current model-selection/acquisition MVP: some portfolio projects create/fine-tune model artifacts and will eventually need a controlled way to promote and publish them to one or more venues.

This is producer-side work. It is distinct from the current consumer-side Foundry MVP (#18/#19) and must not block that critical path.

Architectural boundary

The current Foundry direction primarily answers:

project requirement -> select/qualify model -> acquire/materialize -> consume

Future producer/publisher capability would answer:

project-produced model -> validate release candidate -> promote -> package/adapt -> publish to approved venue(s) -> verify published identity -> register provenance/location

Do not make Foundry itself the universal model host merely because it knows how to publish. Prefer venue-native ownership and return/register the authoritative published identities/locations.

Producer responsibilities

The producing project remains authoritative for:

• training/fine-tuning code and dataset lineage;
• model-specific quality acceptance;
• release intent/version semantics;
• documentation/model card content specific to the model;
• legal/rights assertions that require project/owner review.

Shared publisher responsibilities

A future shared publisher may provide:

• versioned release-candidate manifest/schema;
• exact payload-set hashing and immutable identity;
• transformation lineage (conversion/quantization/packaging) using existing provenance standards where practical;
• release gates for quality, safety/serialization, license/redistribution policy, notices, and secret/private-data scanning;
• target-specific publication adapters;
• credentials isolated from producing projects where appropriate;
• idempotent publish/verify behavior;
• post-publication verification and receipt capture;
• publication state such as candidate / approved / published / deprecated / withdrawn;
• links from the private/public model catalog to authoritative published venues.

Possible venue classes

Do not choose or implement venues in this issue. Future adapters may include:

• public model hubs;
• gated/private model hubs;
• OCI-compatible registries for permitted packaged artifacts;
• project/organization-controlled gated distribution;
• provider/runtime-specific registries or stores where a native publishing mechanism exists.

The publication mechanism must preserve venue-specific semantics rather than forcing every model into one packaging format.

Gated/private publication

A future private/gated distribution mechanism may be useful for models that are not ready or permitted for public release. Requirements should include:

• explicit authorization/access policy;
• immutable identity and provenance;
• credential isolation;
• auditability;
• revocation/withdrawal state;
• no assumption that a private venue grants redistribution rights;
• no leakage of private training data, secrets, internal evaluations, or strategic project metadata into a public catalog.

Generator–Validator relationship

Publication should be predominantly deterministic. Generator–Validator may assist only where residual uncertainty exists (for example, generating candidate model-card text or checking ambiguous metadata), but release acceptance must be controlled by deterministic policy, project-owned validators, explicit owner gates, and reproducible evidence.

Canonical rule:

Deterministic machinery owns what we know. Generator–Validator works the frontier of what we don't yet know. Successful work at that frontier should move the boundary outward.

Way of Work / R4

Any future implementation should follow Observe/Discover -> Plan -> Act -> Verify and be reproducible, repeatable, reversible where the venue permits, and idempotent.

Publishing is an external mutation and should use explicit release/owner/credential gates. Prefer a non-mutating plan/validate phase, then explicit publish, then pull/read-back verification against the exact published identity.

Deferred until

Do not implement this until at least one producing project has a model that is actually approaching a release/promotion decision and the consumer-side Foundry MVP has established its identity/qualification contracts.

At that point, use the first real model release as the bounded vertical slice rather than designing a generalized publishing platform in advance.

Non-goals now

• no public model-hosting service;
• no gated portal/UI;
• no generalized model release platform;
• no automatic legal conclusion engine;
• no requirement that all project-generated models enter Foundry;
• no impact on the current desktop-ui-cv / BHADA proving sequence.

[mark-e-deyoung]

Decision confirmed 2026-09-01: retain this as deferred producer/publisher architecture and return engineering attention to the consumer-side MVP critical path. Draft PR #21 carries the durable architecture note. No publisher implementation, venue selection, gated-hosting buildout, credentials, or external publication should begin until a real internally-created model is approaching release and the consumer-side identity/qualification contract has been proven.

[mark-e-deyoung]

2026-09-04 ORAS/OCI disposition and provider-role red-team

A review of current blob/storage/provider semantics supports the existing producer/publisher boundary but sharpens the terminology.

ORAS is useful here, but it is not a universal provider abstraction

For internally produced/fine-tuned artifacts, an OCI registry is a strong candidate publication/distribution venue and ORAS is a strong client/transport mechanism:

project release candidate
  -> deterministic release gate
  -> ORAS/OCI publish to approved registry
  -> immutable OCI manifest digest + per-blob digests
  -> read-back verification/publication receipt
  -> consumer ORAS/OCI pull when that representation is selected
  -> local representation-specific handle

The registry (for example GHCR/zot/another OCI implementation) is the storage/distribution venue. ORAS is the standardized OCI artifact client/tooling. Neither should be promoted into a generic ProviderPlugin that also owns metadata discovery, selection, qualification, or runtime inference.

Preserve provider-native storage for externally sourced models

The current HF consumer path should remain:

exact HF observation
  -> HF provider-native materialization/cache
  -> verified local handle
  -> consumer runtime

Do not insert an automatic HF -> OCI repack/upload -> OCI pull hop merely for Foundry uniformity. That would duplicate bytes, credentials, storage lifecycle and identity relationships without solving a current first-consumer problem.

Where OCI/ORAS earns its place

Use it when a producing project actually needs a controlled publication venue and OCI packaging is permitted/appropriate. It offers content-addressed manifest/blob identities and supports attached/referrer artifacts, which can later carry provenance/SBOM/evaluation/signature material without storing the model bytes in Git.

Preserve natural sharding rather than forcing a huge model directory into one archive/layer; registry-specific layer/upload limits remain a venue concern to validate at publication time.

Identity rule

Do not collapse these into one digest:

• producing-project release identity/version;
• payload/file-set identity;
• OCI manifest digest;
• individual OCI blob digests;
• provider/hub source revision;
• local materialized path.

A publication receipt should bind the transformation/package lineage plus the authoritative venue-native published identity. A filesystem path remains local state, not durable artifact identity.

Surviving architecture rule

Externally sourced bytes remain provider-native by default. Internally produced bytes remain producer-owned until publication. Foundry owns/control-binds identity, qualification, resolution and publication/materialization evidence; it need not own the bytes.

This remains deferred producer-side work and does not add an ORAS/OCI task to the current KV-Ground consumer critical path.