MVP vertical slice: deterministic-first model selection, placement, and acquisition proof

[mark-e-deyoung]

Purpose

Turn #16/#17 into one bounded, falsifiable post-identity MVP rather than a broad model platform.

Governing principle from the Generator–Validator thesis:

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.

Critical path

This issue is downstream of #9/#12. Do not start implementation that depends on unresolved artifact identity semantics.

1. Finish the identity fixture increment (Increment 1: capture metadata-only provider fixtures #12) and minimum identity resolver from MVP: resolve and observe external model identities #9. Prove exact/strongest available identity from captured provider evidence without model downloads.
2. Define the smallest project-facing request and response contracts. Request: capability + operating envelope + placement policy. Response: selected model/representation/runtime/target plus evidence/qualification state. Keep UNKNOWN first-class.
3. Define a static private resource inventory contract. Only enough fields to distinguish the first real targets (OS/arch/RAM/VRAM/runtime/provider instance). No scheduler, utilization daemon, autoscaler, or fleet database.
4. Implement deterministic fast-path planning first. Known qualified tuple lookup, hard constraint rejection, deterministic ranking, exact identity resolution. No LLM/model generator required for known cases.
5. Add one bounded UNKNOWN/candidate path. Reuse existing public/provider evidence and existing fit tools where useful to propose a small candidate set. Do not build a general crawler/recommender.
6. Implement one provider-native acquisition path. Hugging Face first, using native shared cache and exact revision; no duplicate Foundry blob store.
7. Integrate one real consuming project. Remove its direct provider/download/cache-selection mechanics and leave a capability/dependency declaration plus runtime consumption of the returned native handle.
8. Run the project-owned quality validator plus a bounded performance/resource measurement. Emit a deterministic qualification receipt bound to exact artifact + representation + runtime/toolchain + target + workload.
9. Prove the determinization ratchet. Repeat an equivalent in-envelope request and require deterministic catalog resolution without candidate generation/research. Then change one material target/envelope variable and require either a known alternate or explicit UNKNOWN -> bounded exploration.
10. Only after this proof, add a second consumer/provider/runtime to test generality. Statistical prediction, public catalog UI, community submission hosting, broad multimodal support, dynamic placement, and global catalog ingestion remain deferred.

MVP falsification criteria

The concept is not proven merely because it can download a model. The vertical slice should fail/redirect if it cannot demonstrate most of the following:

• a real consumer loses meaningful provider/model acquisition logic;
• exact artifact identity is preserved across selection, acquisition, and qualification;
• at least two plausible model/representation/runtime/placement candidates can be deterministically accepted/rejected for explicit reasons;
• project-owned quality evidence participates in qualification without being centralized into Foundry;
• one target/environment change materially changes a selection or produces UNKNOWN;
• an equivalent repeat request bypasses Generator–Validator exploration;
• provider-native storage/cache ownership is preserved;
• the qualification receipt is reproducible and useful enough to drive a future decision.

Candidate-consumer disposition

First integration candidate: SemperSupra/desktop-ui-cv

Preferred first consumer for the broker/interface proof because it already has direct Hugging Face model acquisition (from_pretrained), explicit model/cache/device knobs, model provenance/deployment metadata, benchmark/validation surfaces, and is not currently in the middle of BHADA's release-critical stabilization chain. Keep the first slice to one capability/model path; do not absorb its project-specific registry/evaluators into Foundry.

Second / stronger falsification candidate: mark-e-deyoung/BHADA

BHADA is not too simple. Its multilingual ASR surface has multiple Whisper model sizes, two backend families (faster_whisper / whisper), explicit cache/download behavior, and natural quality/performance measures (e.g. transcription quality + real-time factor). It is a strong test of selection/acquisition determinization and would directly avoid building a separate repo-local artifact catalog/mirror. However, BHADA issue #83 currently has a release/stabilization critical path and issue #88 is follow-on artifact work, so do not inject the first shared-substrate implementation into the current merge/release gates. Use BHADA after the first Foundry slice is stable, and require at least two target profiles/backends so the test is not merely "choose Whisper size".

Later stress test: mark-e-deyoung/ml-depth-pro

Excellent heterogeneity test, poor first MVP consumer. Its current sync_models.py spans direct HTTP, Hugging Face, archives, entire repos, renamed files, unavailable stubs, and multiple checkpoint formats. Use it only after the basic interface/acquisition path is proven; otherwise its edge cases will drive premature abstraction.

Stop / scope guard

Do not build a web catalog, generalized benchmark service, statistical capability predictor, new artifact warehouse, cluster scheduler, broad provider matrix, or generic model ontology to satisfy this issue.

The MVP exists to prove that repeated project-local model research/acquisition can become a progressively deterministic shared engineering capability.

[mark-e-deyoung]

Red-team refinement: do not let the observatory become the blocker

The critical path should use a minimum identity gate, not require all of #9 to be complete before the first consumer proof.

Gate A — identity sufficient for first vertical slice

For the first Hugging Face consumer, require only the portions of #12/#9 needed to make the qualification claim safe:

• captured HF provider evidence for the selected model;
• normalized locator -> immutable repository revision identity;
• explicit identity strength;
• enough file/LFS evidence to bind the observation;
• deterministic fixture-based resolver output;
• no secrets/model bytes in public fixtures.

Once that works, the first desktop-ui-cv HF vertical slice may proceed. Ollama/Civitai/hosted-provider fixtures, longitudinal drift history, experiment-binding generalization, and CycloneDX/SPDX export remain valuable thin-observatory work but must not automatically block proving selection/acquisition value unless the consumer actually requires them.

Refined MVP gates

0. HF identity gate — minimum exact identity semantics from Increment 1: capture metadata-only provider fixtures #12/MVP: resolve and observe external model identities #9.
1. Contract gate — minimal capability/envelope/placement request, resource profile, deterministic response, and first-class UNKNOWN.
2. Deterministic planner gate — known-qualified lookup + hard constraint rejection + transparent ranking; no stochastic generator required.
3. HF acquisition gate — exact revision through native HF cache; verify and return provider-native handle.
4. First consumer gate (desktop-ui-cv) — move one KV-Ground path off direct from_pretrained acquisition mechanics; project retains its evaluator/domain semantics.
5. Qualification/determinization gate — record exact artifact/runtime/target/workload receipt, then repeat the same request and prove it resolves without candidate exploration.
6. Selection falsification gate (BHADA) — multilingual ASR with multiple model sizes/backends and at least two materially different target/runtime profiles; require a target/envelope change to change the answer or produce UNKNOWN.
7. GO / NARROW / KILL review — only after these gates consider another provider, ml-depth-pro, statistical prediction, UI, or broader catalog work.

This is the WoW small-batch correction: prove the narrow dependency needed by the next real consumer, then continue the observatory in parallel rather than serializing the whole program behind infrastructure.

[mark-e-deyoung]

Red-team refinement: current main is a successful prior PoC, not the new product architecture

Current main is still materially organized around the completed Faster-Whisper-tiny curated OCI artifact proof (CURRENT_TASK.md marks that proof COMPLETE and explicitly stopped further platform expansion). It contains candidate/catalog/source schemas, GHCR workflows, harvest_poc.py, hydrate.py, and an approved Faster-Whisper artifact.

Do not assume those structures are the starting architecture for the new selection/placement MVP merely because they already exist.

Reuse from the prior PoC

Treat the existing work as proven mechanisms/specification donors for:

• exact upstream revision binding;
• artifact/file hash verification;
• immutable digest semantics;
• R4 hydration behavior;
• qualification evidence tied to runtime versions;
• optional OCI acquisition/mirror behavior when policy/availability actually requires it.

Do not inherit by default

Do not make these old-PoC choices mandatory for the new design:

• Foundry-owned copy of every model;
• GHCR/OCI as the default acquisition path;
• the old approved-artifact catalog as the universal model-parts catalog;
• harvesting/publishing workflows as the center of the runtime path.

The new #16 invariant remains: prefer provider-native ownership (HF cache, Ollama store, runtime-native directories) and copy/mirror only when there is an affirmative availability/transformation/legal/consumer-format reason.

Implementation consequence

Before extending old PoC code, classify each reusable component as either:

1. retain/adapt — generic identity/hash/receipt/hydration logic that fits Architecture: unified model dependency resolver and acquisition broker #16/MVP vertical slice: deterministic-first model selection, placement, and acquisition proof #18;
2. optional adapter — OCI-specific source/materialization support;
3. historical PoC — leave intact as evidence but do not route the new MVP through it.

Do not refactor the whole repository before the vertical slice. Make this classification only for files touched by the first HF consumer path, and prefer new narrow interfaces beside the PoC over premature migration of every historical artifact.

[mark-e-deyoung]

Consumer architecture state

The first consumer architecture is now documented before implementation:

• SemperSupra/desktop-ui-cv#17
• draft SemperSupra/desktop-ui-cv#18 — AS-IS, TO-BE, and executable R4 migration plan
• SemperSupra/model-artifact-foundry#19 — minimum Foundry contract dependency for that slice

BHADA has also been realigned:

• mark-e-deyoung/BHADA#89 — consumer boundary
• draft mark-e-deyoung/BHADA#90 — durable architecture doc
• old BHADA-local artifact-control issue #88 closed not planned in its original form

Critical sequencing remains: prove the local-handle seam and minimum HF identity/acquisition contract with desktop-ui-cv; prove determinization; then use BHADA as the stronger multi-model/backend/target falsification case.

[mark-e-deyoung]

Critical-path restart after documenting the deferred producer/publisher sidequest: SemperSupra/desktop-ui-cv#19 is now the next bounded proving-consumer increment. It characterizes and freezes the current KV-Ground provider/loading behavior without introducing Foundry. After that, Increment 1 adds the explicit local-handle loading seam; only then does Foundry's minimum HF identity/acquisition gate become the blocking shared dependency. This preserves the small-batch WoW sequence and prevents #20/PR #21 from pulling attention off the MVP.

[mark-e-deyoung]

Research-method dependency captured in SemperSupra/engineering-governance-private draft PR #119: docs/sops/multilingual-technical-research.md.

Apply it to future Foundry research on model/runtime engineering, quantization, multimodal runtimes, heterogeneous placement, provider-native acquisition, and evaluation methodology when non-English ecosystems may contain independent evidence. Chinese-language primary sources should be considered explicitly where applicable.

This is a research-method requirement, not an MVP dependency. It must not serialize the current first-consumer path or broaden provider/model scope before the existing GO/NARROW/KILL gates.