DueCare is shared infrastructure that has to run cheaply at NGOs, support worker-controlled and on-device-oriented deployments, behave well in many corridors and many languages, and be inspectable end-to-end. Gemma 4 lets us target all four bars in one stack.
A useful rule of thumb for where AI gets dramatically better, fast.
capability spike ≈ verifiability × training attention × data coverage × economic value
Migrant worker exploitation scores low on every factor. Outcomes are hard to verify. Training corpora rarely emphasize labour law or recruitment-fee scams. Public data is thin and scattered across regulators, NGOs, and court filings. The economic incentive to optimize a frontier model for this domain is small relative to coding or search.
Stock models, no matter how large, give plausible-sounding answers that miss the cited statute, under-estimate corridor risk, or paraphrase a recruiter euphemism instead of flagging it.
Until inherent capability arrives, the gap has to be closed by structure: deterministic grep rules that fire before the model speaks, retrieval against vetted corridor packs, tool calls that ground claims in verified sources, and a harness ecosystem that can refuse, narrow, anonymize, evaluate, or train around an answer when needed. Gemma 4 makes that structure practical: it ships with native tool-calling and supports local, edge, and on-device-oriented deployment paths.
Each reason maps to something concrete a partner or worker actually feels.
Open weights mean an NGO can run DueCare on its own server, and a worker/mobile deployment can target device-local inference where the selected quantized build is available. With Gemma 4, raw casework can stay inside worker-controlled, NGO-controlled, or tenant-controlled environments, and sensitive PII can be anonymized locally before any optional submission.
Gemma 4 gives DueCare a practical open-weights inference path at the sizes the project uses. Most users of DueCare are NGOs and labour-ministry teams; their tooling budget is small. Efficient local inference is what makes “run the relevant harnesses on every job post” or “answer every worker question with a cited draft” plausible in real deployments.
Gemma 4 emits a structured tool-call format out of the base model. The harness uses it directly. That is how grep-rule outputs, knowledge-pack lookups, and license-registry checks get composed into a single answer. That removes a whole category of brittle prompt-engineering between the model and the tools.
The harness can pair base packs for general behaviour with per-corridor adapters for the language and idioms a corridor actually uses. A closed API would force every deployment to carry the same broad context. With Gemma 4, the training and adapter path can stay aligned to the corridor and deployment environment.
The small quantized model path is what makes worker-controlled mobile packaging plausible: a worker can receive cited guidance through a trusted app or partner channel without sending raw chats to the public hub. The current Kaggle and local runtimes demonstrate the same harness and sensitive-data handling path while mobile packaging is integrated.
Researchers can reproduce our evals against the same weights we ran. They can replay an audit feed, pull the same pack version, run it through the same model, and see whether the answer matches. With a closed API, “reproducible” degrades to “snapshot of someone else’s output”.
Each row is something DueCare needs. The Gemma 4 column is what we pay; the others are what we’d give up.
| What we need | Gemma 4 | Closed frontier API | Older small open model |
|---|---|---|---|
| Open weights, redistributable | Yes | No | Often yes |
| On-device-oriented deployment | Small quantized path | N/A. cloud-only | Sometimes. quality drops |
| Inference cost at NGO scale | Efficient local path | Recurring API cost | Cheap, but capability gap |
| Native tool-call format | Built-in | Yes (proprietary) | Bolt-on, brittle |
| Fine-tune per corridor | LoRA adapters; supported | Limited; closed pipeline | Yes. but starts further behind |
| Multilingual coverage of corridors | Strong on target languages | Strong, opaque | Spotty; needs heavy adapter work |
| Reviewer can reproduce outputs | Yes. same weights | Snapshots only | Yes |
| Vendor-lock risk | None | High | None |
Gemma 4 is the substrate. The harness, knowledge packs, tools, evals, and corridor adapters are what make it useful.
Signed corridor knowledge with public-source citations. The model never claims a fact a pack can’t cite.
Cheap deterministic detectors that run before the model. Catch obvious patterns without an inference call.
Allow-listed lookups (license registers, embassy contacts) called via Gemma 4’s native tool-call format.
Small LoRA adapters per corridor + sector, layered on top of the same base weights.
Reproducible evaluation packs. reviewers run the harness against pinned pack versions and replay outputs.
Refusal logic, citation enforcement, sensitive-data handling, judging, training, and audit emission. Gemma 4 doesn’t do this on its own; the harnesses do.
Each is a zero-inference kernel under kaggle/A-2N-*/ that lands the canonical 4-file v1.0 bundle via duecare.appendix_primitives.write_v1_bundle(). Reviewers can run all three in under three minutes with no GPU.
Five-statute compliance corpus loaded into a single Gemma 4 context window. Three cross-statute QA pairs each correlate 2–3 statutes in one thinking step. See kernel →
Server-Sent Events replay at real Gemma 4 E4B-IT latencies (~500 ms first token, ~25 ms subsequent). Live first-token + token-rate stats. See kernel →
One Gemma 4 thinking step emits a 3–4-tool plan; runtime fans out; one synthesized response returns. ~3× speedup vs the chat-loop equivalent. See kernel →
The same harness ecosystem, the same packs, the same audit feed, on infrastructure you control.