Releases: ModelJars/modeljars
Release list
ModelJars 0.1.54
API-compatible System One calls
systemOne(questions, state) takes named questions and returns answers under the same names — the shape a System One call already has, so code written against a hosted System One carries over without restructuring.
try (ModelJarDecisionRuntime runtime = Harriet.open()) {
Map<String, Verdict> answers = Harriet.systemOne(runtime, Map.of(
"urgency", new Noul("Is this urgent?"),
"department", new Choice("Which team handles this?", List.of("billing", "technical"))),
"my invoice was charged twice and nobody answers the phone");
double urgent = answers.get("urgency").probabilityOfTrue();
}The previous batch call, decideAll(List<AnswerSpace>, String), was positional — porting a System One caller meant flattening a map, tracking the order and zipping results back, which fails silently when the two lists drift. systemOne delegates to it, so the evidence is still prefilled once and resumed per question.
Catalogue
system-1is a category. Both System One compositions carry it, and featured domains are pinned into the visible filters — the domain facet sorts by count and cuts to nine, so a two-member category would never have rendered.- Composition descriptions now lead with the task rather than the internals.
granite-answerabilitywas pinned at 0.1.48 while Central had 0.1.53; both compositions are now pinned to this release.
Fixed
Harriet's detail page threw downloadBytes is not defined and showed "Catalog unavailable". renderModel read a binding declared in another function. The second failure of this kind on this page, so the test now calls renderModel for every joined catalog entry and fails on a ReferenceError or TypeError — the previous test only exercised a summary helper, so 291 tests passed while the page was broken.
Coordinates
org.modeljars.composite:harriet:0.1.54
org.modeljars:modeljars:0.1.54
org.modeljars:modeljars-core:0.1.54
org.modeljars:modeljars-catalog:0.1.54
org.modeljars:modeljars-cli:0.1.54
Built on com.integrallis:models:0.3.46. Base weights Qwen3.5-4B Q4_K_M, frozen and unmodified, Apache-2.0, sha256 00fe7986ff5f6b463e62455821146049db6f9313603938a70800d1fb69ef11a4.
ModelJars 0.1.53
Maven Central artifacts for 0.1.53 were published on 2026-09-24 and finalized on 2026-09-25. This release exists to tag the commit they were built from and to produce the native CLI binaries, which had not been built for any version since 0.1.48.
Harriet 0.1.53
Typed, calibrated decisions from a frozen Qwen3.5-4B in one forward pass. Measured on a dedicated CCX33:
| before | 0.1.53 | |
|---|---|---|
| video-shape decision | 1.67 s | 1.09 s (1.54x) |
| warm shared-evidence question | 0.444 s | 0.408 s |
| JevBench Intelligence (120 items) | 72.2 | 88.0 |
The gain came from a rubric that costs nothing — everything before the criterion is shared across every question about one piece of evidence — plus reading the answer off the prefill, and a grouped-decision path that is refused unless the backend states it preserves answers.
Coordinates
org.modeljars.composite:harriet:0.1.53
org.modeljars:modeljars:0.1.53
org.modeljars:modeljars-core:0.1.53
org.modeljars:modeljars-catalog:0.1.53
org.modeljars:modeljars-cli:0.1.53
Built on com.integrallis:models:0.3.46. Base weights are Qwen3.5-4B Q4_K_M, frozen and unmodified, Apache-2.0, pinned by sha256 00fe7986ff5f6b463e62455821146049db6f9313603938a70800d1fb69ef11a4.
Note on release mechanics
publish.yml reads the latest tag to compute the next version but does not create one, and cli-release.yml triggers on a published release. So 0.1.49 through 0.1.53 reached Maven Central without tags, GitHub releases, or CLI binaries. This tag restores the baseline; 0.1.49–0.1.52 remain untagged and are available on Central only.
ModelJars 0.1.48
ModelJars 0.1.48
First qualified hybrid composition.
- New composite recipe module
org.modeljars.composite:granite-answerability: a typed facade for the Granite 4.1 3B answerability hybrid. It opens the qualified Q4_K_M base and the Integrallis-trained answerability activated LoRA through the public API, sharing one physical KV prefix. Callers need--enable-native-access=ALL-UNNAMED. - Catalog composition
granite_4_1_3b_answerability_hybrid, qualified on evidence in integrallis/models at 3ca004e8:- a clean-host run on a fresh machine with both markers resolved from Maven Central, 12 of 12 measurements byte-identical to the qualification arms;
- SQuAD v2 dev 0.878 and MS MARCO v2.1 validation 0.833 on evidence-confirmed labels, against base scores of 0.529 and 0.515, structured and physically shared on all 200 cases per suite;
- kernel identity 10 of 10 per suite against pure Java;
- 50.2% lower latency at a 4,096-token prefix, with unique inference state down from 2.01 GB to 0.68 GB.
- Scope: single-turn answerability on the rust-ffm backend. Multi-turn is not qualified, and on the original dataset labels the MS MARCO suite scores 0.725.
Models runtime: 0.3.42.
ModelJars 0.1.47
ModelJars 0.1.47
- Composite recipe module org.modeljars.composite:granite-answerability for the Granite 4.1 3B answerability hybrid (typed facade, opens base + component through the public API on the qualified rust-ffm backend; callers need --enable-native-access=ALL-UNNAMED).
- Activated compositions select the backend from the base qualification (ModelLoadOptions.backend); a component and its base must be qualified on the same backend, and the build rejects a component pinned to a base that does not advertise it.
- Superseded note: component qualification kind
first-party-rag-specialistfor adapters trained by the publisher. It carries every check ofupstream-rag-specialistplus pinned training provenance (training and prepared-data manifests byte-verified at the training commit, adapter and config hashes bound to the training manifest, training-data licenses) and requires each task suite to strictly beat the base. Suites may declare evidence-confirmed labels (labelSource,labelsSha256, original accuracy retained). - Runtime registry recognises the new kind; older runtimes reject unknown kinds, so this release precedes any first-party component marker.
Models runtime: 0.3.42.
ModelJars 0.1.46
ModelJars 0.1.46
- New component qualification kind
first-party-rag-specialistfor adapters trained by the publisher. It carries every check ofupstream-rag-specialistplus pinned training provenance (training and prepared-data manifests byte-verified at the training commit, adapter and config hashes bound to the training manifest, training-data licenses) and requires each task suite to strictly beat the base. Suites may declare evidence-confirmed labels (labelSource,labelsSha256, original accuracy retained). - Runtime registry recognises the new kind; older runtimes reject unknown kinds, so this release precedes any first-party component marker.
Models runtime: 0.3.42.
ModelJars 0.1.45
- Runtime adopts Models 0.3.42. Fixes an early stop affecting qualified Qwen models: ordinary-text
</s>tokens (every Qwen2 vocabulary, and Gemma 3) were treated as terminators, so generation stopped and the text was dropped whenever a model wrote them. - Also from Models 0.3.42: chat-template end-of-turn provenance in diagnostics, GGUF alignment validation, two more named performance cliffs, LangChain4j cancellation on the activated-tool streaming path.
- From ModelJars main since 0.1.44: corrected memory figures from the computed memory-fit tables (Gemma 4 26B 16.9 GiB, previously 19.4), template end-of-turn tokens in generation profiles, a CI tool-call round-trip gate for tool-qualified models, and the schema for a measured repetition-loop stop rate (no values yet).
ModelJars 0.1.44
- Runtime adopts Models 0.3.41: min-p sampling, typed stop reasons with cancellation, opt-in repetition-loop detector, full end-of-generation token set, loader size assertions, named performance cliffs.
ModelJars 0.1.43
Fixed
- The Granite 4.1 3B Q4_K_M marker could not be used in 0.1.40–0.1.42. Its jar carries a qualification file from before the catalog's launch target was corrected, stamped with the same
generatedAtas the corrected bundled catalog, so the registry refused both withConflicting RAG qualification catalog metadata at the same generation instant. With that marker on the classpath every ModelJars call failed, including calls for other models. The bundled catalog now carries a later generation instant and wins; the published marker is unchanged and opens. - Qualification prompt templates resolve to runtime chat templates. The Granite RAG qualification records the harness envelope
granite-documents, which is not a runtime chat template id, so the runtime would have rejected it next. It now maps explicitly togranite(identical user and assistant turns; only the documents block differs). Unknown templates still fail loudly. - The CLI Spring Boot configuration for Granite now writes
chat-template: granite.
Guards
- The build fails if any bundled RAG or tool qualification names a template the runtime cannot render.
- A test loads the qualification file from the published Granite marker jar beside the bundled catalog.
- A CI gate fails any qualification-manifest change that does not advance
generatedAt.
Added
modeljars coordinates <model> --spring-boot | --spring-aiandmodeljars demo <model> --spring-ai | --spring-boot(#157).- Generation profiles and computed memory-fit tables in
modeljars showand on modeljars.org (#156).
Verified end to end: the unchanged Granite marker from Maven Central opens on Models 0.3.40 and generates text; all 45 published markers load and resolve their templates.
ModelJars 0.1.42
- Runtime adopts Models 0.3.40: native worker pool 5 ms poll budget, Java executor parked under the native backend, vectors 0.1.22 (+45 % pure-Java decode on dedicated cores).
ModelJars 0.1.41
- Runtime adopts Models 0.3.39 (Qwen3 8B Rust/FFM tool path, activated-adapter fixes).
- Catalog records the Qwen3 8B Q4_K_M Rust/FFM tool qualification (models-tool-conformance-v2, 14/14) and advertises the verified backend; the marker moves to 3.0.0-q4_k_m.2.
- Publication planner no longer treats a moved registry report-fetch revision as a change to every tool-qualified marker.