what Ember 1.0 has to earn

a version number is a promise about what other people can build on top of.

the problem: 0.x means everything may change

the v0.1 changelog is blunt about what its version number means: the Rust experiment API is explicitly unstable, and the v0.2 activation-artifact schema carries no compatibility guarantee (CHANGELOG.md). that was the right posture for a research engine discovering its own shape. it is the wrong posture for the thing this series has been describing, a workflow that a researcher who never reads Rust can run and verify, with artifact schemas that must survive transport and time.

the series has argued, post by post, that Ember's real output is contracts: hook sites with defined semantics, artifacts with defined layouts, specifications that resolve deterministically. this post asks what those contracts have to become before the version number can honestly say 1.0.

what 1.0 requires

the criteria, stated as commitments rather than features:

1. stable experiment schema. ember.experiment.v1 stops meaning "v1 within 0.5.x".
2. stable bundle schema. ember.bundle.v1 artifacts remain verifiable by future binaries.
3. stable semantic hook meanings. the six sites keep their frozen descriptor semantics (ember.hook.v1).
4. compatibility and migration policy. a documented rule for what breaks, what fails closed, and how old artifacts migrate.
5. clean installation. build, model download, and verification steps that work from the documentation alone on a supported machine.
6. reproducible examples. the reference morphology workflow runs and verifies from pinned hashes (examples/experiments/ already does this).
7. clear validation status. the ladder in docs/validation.md is current, and "supported" never silently means "golden-validated".
8. at least one successful external user. a person who did not write Ember has run and verified an experiment, and said so.
9. no major public-interface redesign required. the 1.0 interfaces are the interfaces 1.1 will extend, not replace.

the contracts that already exist

four versioned contracts are in place (docs/v05-research-contract.md): the experiment specification (ember.experiment.v1), the bundle (ember.bundle.v1), the semantic hook descriptor table (ember.hook.v1), and the execution plan (v04-plan/1). the compatibility policy is written down: unknown schema majors fail closed; a newer minor with only optional recognized-compatible fields is tolerated; and the policy is explicit that "v1 means stable within Ember 0.5.x, not that every future field is frozen forever" (contract section 17).

that last clause is the honest statement of where the project is: the schemas are versioned and fail-closed, but the versions are still the project's own. a 1.0 release is when the contract stops being a statement about the project and becomes a statement about everyone who built on it.

the gaps between v0.5.1 and each criterion

read honestly: six of the nine are only partially met, two are met, and the one that matters most for external trust, a researcher outside the project who has run and verified an experiment, is the one not yet earned. that is the point of the list: 1.0 is defined by what other people can rely on, and the series ends where that definition stops being a wish.

what 1.0 does not mean

• a performance milestone. Ember is not a throughput product, and 1.0 changes nothing about llama.cpp being the external performance reference.
• that every architecture is golden-validated. validation status is a ladder with pending rows; 1.0 means the status reporting is trustworthy, not that every row is green.
• that the null result becomes positive. the pilot's finding is a null in the tested matrix, scoped to the validated rows, not externally reproduced.
• that the experiment API becomes a free-for-all. stability means documented fail-closed behavior, including the right to refuse.

the series thesis, restated

building an inference engine that gets faster without becoming harder to trust. every post in this series was one answer to one half of that sentence: v0.1 made the engine legible, v0.2 made it intervenable, v0.3 kept quantized weights honest, v0.4 planned execution without hiding tensors, v0.5 made the experiment verifiable, and the null result made the instruments earn their keep. 1.0 is the point where the trust stops being the author's claim and becomes a contract other people build on. nothing in this post makes that happen; it only says what must, and in what order.