Product definition v1 — what "usable" means and why it is achievable¶

Date: 2026-09-06 · Reframed: 2026-09-08 by ADR-011 · Amended: 2026-09-09 by ADR-002 registry/planner/host independence and ADR-012 repository-native distribution · Source: ADR-011 primary-source review, local AIConfigurator and Hugging Face Hub documentation review · Authority: ADR-002, ADR-004, ADR-005, ADR-011, ADR-012

0a. Why this product has to be shipped¶

The problem¶

Teams first have to decide which model or model system can perform their real work, at what quality, time and cost. They then have to turn that choice into an endpoint that fits, boots, meets the serving SLO and preserves the measured task outcome. Public leaderboards, custom evaluations, managed model APIs and self-hosted deployment tools each answer part of this decision, but the evidence is rarely joined across the exact task, application scaffold, model/API, artifact, runtime and hardware that produced it.

When someone tries to self-host a model with vLLM, they may additionally download large weight artifacts, wait for the engine to boot, and only then discover whether the selected artifact, hardware and configuration work together. Volatile package-download counts are not used as a proxy for the number of deployment users.

vLLM already catches many config errors before boot: its pinned source contains checks for TP divisibility, incompatible dtypes and other known misconfigurations. It also auto-derives max-model-len when passed -1, solving one common failure class. These exist, they work, and the product acknowledges them; a syntactic count of raise statements is not called a count of semantic validators.

What vLLM does NOT catch: whether the model fits in VRAM at all before loading, every scheme/backend/kernel compatibility failure, and what to do when a boot fails. Issue #54318 is the concrete counterexample: a Qwen3.8 FP8 artifact passed generic configuration construction on A100/SM80 and failed later in a Triton fused-MoE kernel. It does not establish a universal FP8-versus-Ampere rule or a verified correction. GitHub issue snapshots contain repeated startup-failure reports, but no defensible query establishes a total number of deployment failures or the subset Apron can correct. The addressable gap between static prediction and GPU execution is real and deliberately left unquantified.

Each failure costs 30 minutes to hours — downloading weights, booting, crashing, diagnosing, retrying. An IBM engineer described it in issue #29325: "30 minutes to several hours, only to realize the setup cannot run."

The 2am moment¶

It's 2am. You rented a 4090 on RunPod at $0.69/hour. You downloaded 65 GB of Qwen3-32B — that took 45 minutes. You ran vllm serve with flags from a Reddit thread. Crash: "Engine core initialization failed." You asked Claude. "Try --enforce-eager." Different error. "Try lowering max-model-len." Still crashes. Two hours gone. $1.38 burned on a GPU that served nothing. 65 GB downloaded for nothing. You still don't know if this model fits on this card.

Before you rent the GPU, before you download anything, you type one command. Apron calculates a prediction from immutable model metadata, version-pinned engine constraints, and the declared hardware target, then returns a candidate plan with its uncertainty and unknowns exposed. It does not call this a vLLM test. When vLLM executes on the GPU, the product records the actual result as a measurement; if boot fails, it matches the failure fingerprint to a deterministic correction, proves the mechanism by corrected boot, and separately checks that the accepted request still passes.

What already works (and what doesn't)¶

The ecosystem is working on this problem. Acknowledging what exists:

The product fills the joint gap none of them covers alone: accepted task outcome → solution comparison → computed feasibility before download → exact deployment → task and serving reproduction → diagnosis after failure → version-pinned requalification. Existing evaluation and serving systems are adapters, evidence sources and execution targets; they make Apron stronger rather than redundant.

Inference providers, GPU platforms and model labs may contribute scoped credits, credentials, quota or dedicated capacity because reproducible records, integrations and qualified workloads can benefit their ecosystems. They never purchase placement or conclusions. The first conformance loop and minimum evidence operation have an owner-controlled budget path with no contributed resources; grants only expand coverage or reduce project out-of-pocket cost. Every affected record discloses resource provenance and separates market-equivalent/user-relevant cost from subsidy and project spend. Relationship terms such as partner or sponsor require an actual agreement; ordinary adapter support does not imply endorsement.

Why no LLM can give this answer¶

This project's own LLM-generated competitive analysis got 5 of 8 vLLM version facts wrong and concluded "DeepSeek-V3 FP8 needs 8×H100 minimum" for weights that don't fit in 640 GB. vLLM releases every two weeks; a flag that exists in v0.28 may not exist in v0.29. Reddit users describe using Claude and Codex for vLLM config as "trial and error." The product makes the answer auditable: Claude calls the MCP tool, receives a version-pinned prediction, and receives a verified answer only when matching GPU execution evidence exists. Claude is the consumer, not the authority. Sources: vLLM source at the pinned commit; reddit.com/r/BlackwellPerformance/1snk6h8; reddit.com/r/LocalLLM/1vtsid0; internal research findings.

Why nobody else has built the full loop¶

In issue #29325, at least five distinct commenters explicitly offered to collaborate, contribute or implement. One proposed vllm serve --dry-run—an upstream preflight adjacent to this product's prediction-and-measurement loop, not proof that vLLM can be validated without a GPU. A project member responded, but no project owner committed to implementation before the stale bot closed the issue. The issue itself, rather than a mutable volunteer total, is the demand evidence.

This does not mean the ecosystem is failing — it means the engine team builds the engine, the hardware vendor builds for datacenter customers, and the evidence-plus-diagnosis layer is nobody's priority. If any of them build part of it, the product calls their code and gets better (ADR-003, ADR-008). Sources: github.com/vllm-project/vllm/issues/29325; github.com/vllm-project/vllm/issues/39749; github.com/ai-dynamo/aiconfigurator; internal research findings.

Why "it boots" and "it scored well" are both insufficient¶

The difference between a basic setup and the right config for a workload (inference engineering knowledge base):

• Decode is memory-bandwidth-bound: the same model on the same GPU gives 5 tok/s or 40 depending on max_num_seqs, max_num_batched_tokens, and quantization choice.
• A coding agent needs low total response time; a chat app needs low TTFT; a RAG pipeline needs high concurrent throughput. Different workloads need different configs.
• A public benchmark or task score belongs to the exact task suite, prompt/agent/tool scaffold, judge and model/API configuration that produced it. It does not prove that a different quantization, endpoint or application preserves the result.
• Cost per token or per attempted task is not cost per accepted result. Failures, retries, tool calls, judges, idle capacity and availability requirements can reverse the ranking.
• FP8 and FP4 compatibility depends on artifact, scheme, backend, kernel, hardware, model, and engine version. Issue #54318 is retained as a scoped external GPU failure observation with no verified correction; issue #55008's successful Marlin remediation belongs to a different incident and is not silently transferred.
• KV cache takes 80%+ of post-weights VRAM. A "2× params" estimate is wrong by up to 16× for GQA/MQA/MLA models.

The product keeps task evidence, serving evidence, version-pinned prediction and GPU-executed engine evidence separate, then joins them only through exact fingerprints. Every execution record carries predicted beside measured, and every qualified solution shows which accepted outcome and serving constraints it actually reproduced.

How trust is earned¶

The 2am person doesn't need to trust the maintainer. They need the answer to be right once.

1. Try — cost is 2 minutes (one command or one Compose file). Cost of NOT trying is 30-60 minutes of trial-and-error.
2. Verify — nvidia-smi shows the VRAM. The record said the predicted value. It matches. They checked a number, not trusted a claim.
3. Come back — vLLM releases every two weeks. The product tracks per-tag diffs and tells them what changed.
4. Find it without searching — the MCP tool the agent already calls, the catalogue the search finds, the vLLM issue the record is attached to (posted by the maintainer to existing open issues).

Precedent: the Open LLM Leaderboard demonstrates trust in auto-generated benchmark results through reproducible methodology rather than human attestation per entry. club-3090 demonstrates adoption of per-model Compose files with measured numbers. These are precedents, not guarantees or universal comparisons between every planner and catalogue. The supported product inference is narrower: people can directly reuse a working configuration.

Expected 90-day outcome: 0–100 stars. The base rate in this niche for a solo tool is near zero. The concept says this upfront and has a decision rule for when the targets fail.

The selling points¶

1. Each failure is expensive — 30 min to hours per attempt; 16–65 GB downloaded before you learn the config is wrong
2. The gap is specific — model evaluation, managed serving and engine benchmarking exist; the missing product joins task outcome to an exact provider-neutral solution, deployment, diagnosis and requalification
3. No LLM can do it — ground truth changes biweekly; Claude is the consumer via MCP, not the competitor
4. People copy configs, not install tools — the catalogue form factor outperforms every tool in this niche (one precedent: club-3090)
5. Trust comes from reproducibility — predicted beside measured, verifiable with nvidia-smi

0. What the product is¶

The product is a task-to-qualified-inference-solution decision and evidence system. Given an accepted task outcome, quality floor, serving SLO, policy and authorization envelope, it discovers managed, self-hosted or compound candidates; evaluates their task behavior; calculates and deploys feasible endpoints; reproduces the outcome on the exact retained solution; measures total outcome economics; and returns a qualified solution, bounded comparison, or proven fix with prediction beside measurement.

It is an evidence, qualification, planning, verification and placement-optimization layer across evaluation systems, managed APIs and inference engines. Apron owns the canonical decision and evidence graph, deterministic selection rules and a GPU-free, mechanism-aware predictor built from immutable artifact metadata, explicit architecture dispatch, versioned engine constraints and calibrated observations. It integrates established evaluation engines rather than treating generated benchmarks or LLM judges as unexamined truth. vLLM's physical cache specification comes from instantiated model layers, while its memory profile and actual compatibility paths require GPU execution; those are the conformance and measurement oracle, not a universal CPU calculator.

It is not merely a calculator, platform, website, or competitor to an engine. A resource calculator is nevertheless a required product component: it creates useful pre-download candidates where no matching record exists. The evidence and replay loop is what makes those calculations auditable and improves them over time.

It is a product rather than a leaderboard or dataset because the loop closes: an accepted outcome produces a replayable task protocol; candidates are evaluated; a solution and its endpoint plans are derived; deployment either works or becomes diagnosis evidence; task and serving outcomes are reproduced on the retained solution; and every material task, application, model, runtime or provider change invalidates or requalifies the scoped result.

1. The experience¶

A person or coding agent may begin with the task and let Apron compare authorized solutions. The following uses qualify as illustrative syntax; the CLI verb is not frozen by ADR-011 and requires its own naming review:

apron qualify --tasks ./evals/support-agent --application ./agent.yaml --quality success_rate:0.95 --slo p95_e2e:8s --optimize cost_per_accepted_task

The resulting DecisionReport exposes the compared managed, self-hosted and compound candidates, exclusions, scores, serving evidence, outcome economics and uncertainty. Once accepted, apron deploy DECISION_ID retains the selected solution and reproduces the accepted task outcome against it.

An explicitly selected model remains a valid constrained request rather than a separate product:

apron deploy Qwen/Qwen3.8-27B --workload coding-agents --concurrency 6 --context 32768 --optimize balanced

The same operation is available over local MCP:

deploy_model(model="Qwen/Qwen3.8-27B", workload="coding-agents", concurrency=6, context=32768, optimize="balanced")

The MCP server is the same binary in server mode:

apron mcp

Claude Code configuration:

{"command": "apron", "args": ["mcp"]}

After that, when a user asks Claude "deploy Qwen3.8-27B on my 4090," Claude calls the MCP tool silently. The user never types apron — the agent does. One package, two doors into the same engine.

The public service receives only what the user chooses to share. Task data, prompts, traces, outputs, model files, credentials and filesystem contents remain local by default. Sending task material to an external candidate, judge or evaluation service requires an accepted data policy and matching authorization; evaluation never implies telemetry or publication.

1a. Telemetry¶

The 90-day checkpoint requires instrumented, privacy-respecting event counting with published counting rules. No custom scaffolding — two existing tools:

Install tracking: Scarf gateway wrapping the PyPI package. Zero code. Counts installs and shows which organizations are using it.

Usage telemetry: PostHog open-source analytics. Python SDK, opt-in, free tier (1M events/month). Events carry only bounded categories the product already defines — capability-signature class, mechanism class, hardware class, outcome and engine tag — never media contents, exact high-cardinality private signatures, model files, credentials, prompts, or filesystem contents. The counting rules are published in the docs.

Events that map to the 90-day checkpoint:

PostHog can be self-hosted if needed. The dashboard is built-in — no custom analytics backend, no custom event pipeline.

Demand signals for the agentic pipeline. Every CLI, MCP or repository-Action invocation may capture the same categorical deployment signals locally: capability-signature class, mechanism class, workload type, hardware class, concurrency, applicable token/media shape bands and outcome. Accepted requests and local failures are the direct demand inputs to Tier 1 evidence-gap ranking (phase-plan.md §demand-driven), alongside claim scope, missing/stale/contested evidence, prediction uncertainty/error, unresolved failures, freshness, adequate external coverage and cost. With opt-in telemetry, only the bounded categories above are transmitted. Without opt-in, they feed only the invoking local or repository workflow and are not sent to Mondegreens. No prompts, media, filesystem contents, exact private signatures or credentials are captured. Dated fallback signals may come from multiple model registries, provider catalogues, engine issues/releases, recipes, external planners and evidence systems. Every source's snapshot, normalization, deduplication and contribution are recorded; no single popularity counter, including Hub downloads, defines eligibility or silently wins a tie.

1b. Tech stack¶

No custom frameworks. Proven libraries, well-maintained, well-documented.

Typer + Rich is the standard Python CLI combo in 2026. Typer handles the interface, Rich handles the output. Pydantic handles the data contracts. httpx handles the network. Nothing custom, nothing exotic.

1c. Repository setup (2026-09-07; stack decisions corrected 2026-09-11)¶

Notes on §1b: Scarf's PyPI gateway records IP-derived location and company on every download before any opt-in; either disclose that in §1a or drop Scarf for PyPI's public statistics. Credentials never live in the TOML config (INV-13): environment or OS keyring only; TOML holds presets and preferences.

The GitHub account boundary is fixed by ADR-012:

Version and dependency policy (engineering-standards.md §11): the matrix tests the declared floor and the newest stable Python release rather than the versions between them; a new release is added within a stated window and a release is dropped at upstream end of life. Direct dependencies update as grouped minor/patch proposals with security updates separated and a cooldown before an update becomes eligible for automatic merge. ADR-009 requires full-commit-SHA action pins, which are kept current by automated update proposals — a pin policy without an update mechanism produces stale dependencies rather than reviewed ones. The number of simultaneously supported engine minor versions is stated explicitly: the engine releases every two weeks with backward compatibility guaranteed for a limited number of minors, so an unstated window is either an unaffordable revalidation obligation or an unsupported currency claim.

Repository settings: a repository ruleset on the default branch (pull requests only, CI required, linear history), not classic branch protection; secret scanning with push protection, which is the only protection a new public repository receives automatically; CodeQL default setup, Dependabot alerts and security updates, and private vulnerability reporting, each enabled by hand; Dependabot for dependencies and Actions with a cooldown; the per-user open-pull-request cap for users without write access; fork pull-request workflow approval set to all external contributors; immutable releases enabled before the first tag; SECURITY.md; CODEOWNERS over the claim-bearing paths; issue template "numbers from your rig" in the recipes-compatible shape; pull-request template asking for the record id behind any rule change (INV-2) and carrying a one-line AI-disclosure field (public-development-strategy.md §4c); CITATION.cff; repository topics, social preview and a compact evidence-bearing badge set. Licenses in commit one: Apache-2.0 code, CDLA-Permissive-2.0 records, CC-BY-4.0 docs. public-development-strategy.md §5 carries the source for each setting.

Documentation: a Zensical site on GitHub Pages (methodology, invariants, metrics, ADRs) with mkdocstrings for the API reference and the mike fork for versioning; catalogue pages generated into the same site from records. The generator changed from mkdocs-material on 2026-09-11 and the reasoning is in public-development-strategy.md §8; the choice is not an architecture decision and does not change what the site publishes.

Community routing: GitHub Discussions receives Q&A and exploratory integration conversations; Issues receive actionable bugs/features and structured failure/evidence intake. A public organization Project may expose evidence gaps and contribution-ready work without importing private research planning.

mondegreens/apron-action is released when the canonical structured input/output schema for its first repository check is stable and an external fixture repository reproduces the expected Check Summary. The Action's hosted-runner path is GPU-free and must distinguish calculation, transferred evidence, proven constraints and measurement. GPU work is reachable only through the ordinary accepted-protocol, execution-target and authorization contracts; fork pull requests receive no secrets or side-effect authority. The Action is eligible for GitHub Marketplace because repository-native installation is the distribution mechanism, not because Marketplace presence is evidence of use.

Corrections applied 2026-09-11. Five statements in this section were changed, each because a primary source checked that day contradicted them, and each is recorded here because framework-spec.md §4 forbids a silent correction. The Python floor moves from 3.11 to 3.12: tomllib was the stated reason and it is in the standard library from 3.11, so the reason no longer distinguishes the two, and 3.11 is security-only with end of life in October 2027. The documentation generator moves from mkdocs-material to Zensical, because mkdocs-material's security fixes end on 2026-11-05 and MkDocs 2.0 removes the plugin system. The hook runner moves from pre-commit to prek, which reads the same configuration. The Sigstore cosign step is removed from release.yml, because PyPI accepts no separate signature upload and trusted publishing already produces PEP 740 attestations. "Branch protection on main" becomes a repository ruleset, and the claim that a new public repository arrives with Dependabot and code scanning is corrected: only secret scanning and push protection do. The ty rationale is rewritten, because the sentence that its stable path "still lists first-class Pydantic support as outstanding" was overtaken when that support shipped in July 2026; the decision is unchanged and the reason for it is now beta status rather than a missing feature. public-development-strategy.md §8 and its Corrections section carry the sources.

Not needed: self-hosted runners (Tier 1 calls the provider API from a hosted runner), coverage or code-quality SaaS, a repository per adapter, separate docs/MCP/evidence repositories, or a republished engine-image registry. Publish an Apron OCI image to GHCR only when a supported hermetic Apron runner or remote MCP deployment requires one. Introduce a GitHub App only when a required installation-scoped asynchronous or cross-repository workflow cannot be expressed safely as the Action. GitHub Discussions remains the public community surface unless support and moderation demand justifies another channel. FUNDING.yml and GitHub Sponsors remain disabled while the project accepts contributed compute access but not money.

2. The ten-step product loop¶

The self-hosted calculation/deployment path remains materially de-risked by llmcalc's RunPod implementation and deployment history. The genuine builds are the canonical decision/evidence graph, mechanism-aware calculator, bounded solution optimizer and proven diagnosis/requalification loop. Evaluation execution is integrated through conforming adapters; Apron does not need to recreate every task runner, sandbox, trace store or judge implementation to own the decision.

2a. The full product scope — every question the product answers (2026-09-07; expanded 2026-09-09 by ADR-011 and ADR-013)¶

Source: advocacy session — comprehensive feature verification against the production chain.

The product calculates on demand for capability signatures whose artifact/component execution mechanisms it recognizes, using its own GPU-free predictor and versioned engine constraints. It returns explicit unknowns for unsupported mechanisms, modality combinations, artifact transformations, kernels or topology effects. Quantized choices refer to real immutable checkpoint artifacts, not flags imagined over a base repository. GPU records verify and calibrate predictions over time; discovered engine capability is never mislabeled as calculator, endpoint or task evidence.

Claims the product refuses to manufacture:

• "Which model is generally best?" has no context-independent answer. Apron can identify a best-observed or measured-efficient solution only for an accepted task suite, application, serving workload, candidate set, policy, objective and evaluation protocol.
• An opaque managed API is not assigned an invented artifact, engine or hardware fingerprint. It can be qualified through observed behavior while its hidden fields remain provider_opaque.
• Hardware, mechanism or capability-signature support that has no conforming adapter is unsupported or unknown, not silently approximated. A publisher modality claim, engine-resolved signature and configured endpoint are separate scopes. Apple Silicon and CPU are valid architecture targets when their hardware/engine adapters and evidence exist; they are not excluded from the product model merely because the initial vLLM/CUDA execution path does not implement them.
• A remote image, audio or video URL is not fetched merely because a model accepts that modality. Retrieval needs accepted data-destination policy and an authorization envelope; adapters enforce domain/redirect and decoded-size limits, isolate media processing and keep private media and derived embeddings out of logs and published evidence by default.
• A Hugging Face id, model card, registry tag, provider mapping or external planner recommendation is not artifact, capability or qualification truth. The source observation remains visible; immutable content identity and the applicable deterministic or executed evidence decide what can be promoted.

How strongly Apron may state a result:

These statuses are independent from the authority level of the evidence source. A prior measurement—even from a very similar stack—remains prior evidence; when used for another proposed execution it contributes to a new predicted result and never becomes that execution's measurement.

How results are produced — the qualification chain:

The product does not pre-compute the Cartesian product of every model, API, role assignment, artifact, runtime and target. It discovers from the accepted request, performs cheap deterministic pruning, and spends evaluation or GPU budget only on candidates whose expected information can change the decision.

1. Discovered and capability-eligible: Candidate managed APIs, self-hosted artifacts and compound solutions are discovered through attributed sources and resolved far enough to match the accepted input combination, operation and output representation and to apply tool/API, context, license, privacy, policy and known compatibility constraints. Self-hosted identity comes from the immutable resolved manifest and content/component digests, not a registry name. Public benchmarks, model cards, planner outputs and prior records are attributed priors, not proof for the user's task.
2. Task-evaluated: Conforming evaluation adapters execute the accepted EvaluationProtocol. Every attempt, failure, retry, score, trace reference, time and attributable cost remains available. This evidence is scoped to the exact task suite, application and candidate solution.
3. Calculated and deployment-verified: For supported self-hosted mechanisms, Apron resolves immutable artifact facts and target facts, calculates endpoint candidates GPU-free, and may ingest conforming external PlanningClaims before using actual GPU execution for engine conformance, boot and measurements. Planner disagreement remains visible; no planner label promotes the candidate. Managed APIs receive observed health and behavior evidence while hidden runtime fields remain opaque. Produced evidence may come from the maintainer pipeline, explicit local verification, or user-authorized provider resources billed directly to the user.
4. Serving-verified and task-reproduced: Native serving benchmarks measure latency, throughput and goodput at the accepted ServingWorkloadSpec; they do not measure correctness. The accepted task protocol is replayed against the exact retained solution. Only the combination can satisfy final qualification.
5. Qualified, ranked and requalified: The optimizer filters failed task, serving, policy and authorization constraints, then ranks the remaining comparable solutions by the accepted objective. Material changes to tasks, application, model/API, artifact, runtime, evaluator, provider, pricing or serving workload invalidate or trigger reassessment of the exact qualification.

Each stage returns what it has and labels both evidence authority and epistemic status honestly (§2a answer ladder). Publication remains a separate consented action.

Selection follows a permanent qualification-obligation graph: cheap capability and policy checks establish eligibility and authorization bounds; task evaluation and applicable deployment/serving checks may then be scheduled in the cheapest authorized order; exact retained-solution task reproduction and every applicable serving SLO are required before objective-based ranking can promote a qualified solution. Implementations may interleave measurements to reduce cost, but cannot skip a qualification obligation. Availability can remove an option but does not make the next option efficient. An unavailable preferred SKU may be substituted without new authorization only inside declared adaptation rules and hard cost/security/credential/data bounds. A request to measure a specific GPU makes that hardware part of the claim and forbids substitution.

The result vocabulary reflects the proof obtained: discovered candidate, task-evaluated candidate, calculated deployment candidate, verified endpoint, qualified solution, or measured-efficient solution. The last term means best observed among disclosed comparable candidates under one task, application, serving, economics and evaluation protocol. Measuring or qualifying one candidate proves that it works within that scope; it does not prove optimality.

The dimensions the GPU-free candidate sweep represents:

The candidate matrix can contain thousands of combinations, but the planner never manufactures them by crossing arbitrary flags. GPU-free calculation traverses only resolved artifact/transform nodes and applicable typed adapters, prunes provably incompatible choices with versioned constraints, and exposes unsupported or uncertain states. GPU execution validates selected runtime paths. Viable, rejected and unresolved candidates remain auditable rather than disappearing behind one answer.

2b. The answer ladder: what the user gets at every level of coverage¶

Only the last level is an empty room. Coverage is cheaper than the record count suggests: infeasible combinations fail in seconds for cents and are still records; lineage inheritance lets one boot cover many derivative checkpoints; and the catalogue form factor lets others add records on cards the lab never rents.

2c. Why records publish at every evidence level, not only when fully benchmarked (2026-09-07)¶

Source: advocacy grilling — "prove that publishing without throughput data is not lazy."

The user's questions come in order: (1) "does it appear to fit?" (2) "what candidate flags should I try?" (3) "does it actually boot and how fast is it at my workload?" Questions 1-2 can receive a labeled prediction before GPU rental. Question 3 requires GPU execution. If every prediction required a benchmark before publication, the user would rent blind; if prediction were labeled validation, the product would manufacture certainty it does not have.

Precedents: club-3090 published boot-and-VRAM records before full benchmark suites; contributors who copied the Compose file then submitted full benchmarks later [W: github.com/noonghunna/club-3090]. NVIDIA's aiconfigurator produces plans without throughput data for cards outside its silicon database and says to verify results in real benchmarks [S: aiconfigurator README].

Budget math: 4 benchmark presets × 60 feasible model+GPU combinations = 240 runs = $14-41 in GPU time — 20-60% of Phase 1b budget on benchmarks alone. Publishing feasibility-only records for lower-priority combinations preserves budget for benchmarking the top-demanded ones.

Each evidence level answers a different question:

Design rule: answer immediately at the cheapest level available, label the evidence level honestly (§2a ladder), and upgrade when budget, consented contributor submissions, or on-demand paid verification produces the next level. Local verification does not enter the public evidence corpus unless the user runs apron submit.

When a verified or related-artifact record's engine tag is more than two minor releases behind the user's detected or declared engine version, both the prediction and measured evidence display their engine/source version visibly, and the output invites the user to run apron verify against an explicit target. A prediction is correct only for its recorded rules and inputs; it is not execution evidence for the user's engine version. The resulting report stays local unless separately submitted.

3. First public product proof¶

The internal Phase 1a conformance fixture proves the deployment/diagnosis engine; it is not the complete public product claim. The first public proof begins with an accepted task suite, evaluates a disclosed candidate set, calculates and deploys at least one self-hosted endpoint, measures serving behavior, reproduces the accepted task outcome on the exact retained solution, reports outcome economics, and demonstrates request-preserving diagnosis or a qualification regression. Managed APIs and compound solutions use the same permanent contracts even when a particular proof does not exercise every solution class.

A web app, generated pages, broad engine coverage and community-scale evidence are not prerequisites for this proof, but neither are they defined out of the architecture. The usability bar is a reproducible DecisionReport and useful retained solution or honest no-qualifying-candidate result. If comparison coverage is insufficient, the endpoint may be qualified but is not called best or optimal.

3a. Where v1 is weak, and the three strengtheners¶

Weak: zero records until the first sitting; the first question people ask ("what GPU do I need") is answered for free by an LLM at roughly 80 percent accuracy, so the tool wins only on exact flags at a pinned tag, verification, and diagnosis; diagnosis starts at six proven classes; reaching the tool takes an install or an MCP configuration; the oracle value depends on others consuming it.

Strengtheners, in order of leverage:

1. Diagnosis at the point of failure. apron run -- vllm serve ... wraps the engine, captures the failure, and returns the corrected command in the same terminal with its proving record. No pasting, no page. This is the "I no longer think about deployment" experience and is Phase 1 scope.
2. Repository qualification where changes happen. A pinned mondegreens/apron-action converts model, artifact, engine, workload and deployment changes into the same canonical Apron check. The workflow reference keeps Apron present in the engineering loop; only completed checks and downstream actions count as use.
3. MCP where agents already look. Publish the same package to conforming MCP registries with a one-line install, so an agent uses it silently and the user never needs the tool's name.
4. Upstream preflight. If a vLLM dry-run lands upstream, Apron can consume it in the GPU execution path; CPU predictions and measured records retain their separate authorities (ADR-003, ADR-008).

3a-1. Retention versus acquisition (2026-09-07)¶

Evidence: Study of 115,466 GitHub repos (arxiv 2507.21678): user interaction weight is the #2 predictor of project survival. Solo planning-only tools (calculators, config generators) in this niche have zero survivors past 1 year — all are episodic (user asks once, gets answer, leaves). Solo serving tools (LocalAI 3.5yr, oobabooga 3.7yr) survived because users engage continuously.

The one-shot apron deploy is one acquisition surface. The GitHub Action is repository-native acquisition because a model, engine, application or deployment change can invoke Apron without a separate visit. The retention surfaces — how someone stays — are:

1. apron run -- vllm serve ... — wraps every deployment, captures every failure, returns corrections. The user runs this instead of bare vllm serve. Every deployment is a touch point.
2. apron mcp — an agent calls the tool on every deployment question. The user never types apron; the agent does. Every agent interaction is a touch point.
3. mondegreens/apron-action — a pinned workflow re-evaluates relevant repository changes and identifies invalidated evidence. Every completed material check is a touch point; installation, a badge view or a skipped workflow is not.

The distinction matters because the 90-day checkpoint must measure RETENTION, not just ACQUISITION. A user who planned once is the calculator pattern (death). A user whose agent calls the MCP tool on every deployment question is the serving pattern (survival).

3a-2. Community record submission (2026-09-07)¶

Evidence: club-3090 got 11 hardware profiles from 22 contributors at $0 to the maintainer — each contributor ran report.sh --full (~35 min) on their own GPU. Renting those 8 additional SKUs for Tier 1 would cost $800–1,600/month.

The catalogue's coverage is bottlenecked by the maintainer's rented hardware (Phase 1b: 3 SKUs). Users with uncovered cards (3090, L4, A6000, RTX 5090, DGX Spark) find nothing and leave.

apron verify PLAN --target TARGET executes the verification suite on an explicitly selected local, remote or rented GPU and saves a structured VerificationReport locally. apron report RUN_ID only displays or exports that result. apron submit RUN_ID sanitizes, previews and explicitly publishes it. The same verification pipeline serves Tier 1 and users; execution, inspection and publication are separate Phase 1a contracts.

Each record-submitting contributor has: used the tool, learned the format, owns hardware the maintainer doesn't, and has a reason to come back when vLLM updates.

3b-1. Public-facing feature presentation (2026-09-07)¶

The concept documents are written in design language. The repo must speak in two voices to two audiences, both in the same README, separated by writing style, not by labels.

Top of README — the user who has a GPU and wants to run a model. They may not know what vLLM is. They may not know what tensor parallelism means. They want: "type this command, copy this file, it works."

Content: the 2am pitch (§0a), the one-command example (§1), the result they get (the Compose file + "fits / doesn't fit"), and the three selling points: (1) answers before you commit — 10 seconds, $0; (2) fixes when it breaks — corrected command with proof; (3) stays current — tracks biweekly vLLM releases. No architecture terms. No invariant numbers. No jargon. The writing does the job. The user reads the top and has everything they need.

Bottom of README — the developer building an inference stack. They know vLLM. They want: the MCP tool schema, the Python API, the record format, the interop with recipes/aiconfigurator/InferenceX, how to consume the dataset, how to contribute records.

Content: MCP server configuration, API reference link, record schema overview, interop format examples, verify/report/submit contributor and consent guide, link to the full docs site.

The transition between the two is natural, not labeled. A heading like "## How it works" or "## API & MCP" shifts the tone. The user stops scrolling. The developer keeps going. Nobody is called a beginner.

Pattern: the same structure used by vLLM (pitch → architecture), club-3090 (Compose example → benchmark methodology), FastAPI (10-line example → full feature list).

Additional surfaces:

• PyPI long_description — mirrors the README.
• MCP registry listing — one-line: "Verified vLLM deployment planning — fits-or-not before download, diagnosis after failure, working Compose files with measured numbers."
• GitHub Marketplace Action — repository-native qualification and evidence invalidation from the same released core; the listing leads with the Check Summary rather than generic CI claims.
• GitHub Pages docs site (Zensical, §1c) — the full methodology, invariants, metrics, ADRs, catalogue pages, architecture-dispatch-proof.md. For contributors and upstream consumers.

The content exists in the concept. The packaging is an implementation deliverable — write it when the first record exists, not before. A README that says "0 verified records" is honest (§3b Honesty rule) but a README with a working example is better.

3b. CLI cautions (2026-09-06)¶

4. Usability risks and mitigations¶