The AI release control plane
Govern what goes live.
LeanLogix binds an exact model candidate to local evaluation, policy, independent approval, and portable release evidence before serving is admitted.
- 01Private evaluation
- 02Independent approval
- 03Signed release evidence
- 04Fail-closed admission
Release candidate v6
- Candidate digest
- sha256: 82f4…e19c
- Policy set
- regulated-release / v3
- Release authority
- 2-person approval
Evidence chain
Release record
- CandidateCompleted source job and candidate digest boundBound
- EvaluationLocal policy and leakage evidence reviewedReviewed
- Release authorityIndependent reviewer required by separation of duties1 of 2
- Release passportCanonical evidence prepared; signing remains gatedWaiting
One governed release record
Every control. One decision boundary.
LeanLogix turns a scattered release process into one inspectable path from candidate evidence to serving admission.
- 01
Evaluate
Run local behavior, safety, and leakage checks against the exact release candidate.
Inspect control - 02
Authorize
Apply policy and separation of duties before release authority can be granted.
Inspect control - 03
Sign
Bind the candidate, evidence, policy, and authority into a portable release passport.
Inspect control - 04
Admit
Refuse serving when the release authority or configured serving identity does not match.
Inspect control
Public verification
Trust the bytes, not the interface.
Re-check the configured release proof for SprintLoop-7B against the exact signed passport bytes. A release is shown as verified only when signature and drift checks return successfully.
- Access
- No account required
- Method
- Ed25519 verification
- Response
- Privacy-safe summary
curl -s https://leanlogix.ai/api/verify/sprintloop-7bThe demonstration target uses synthetic data. The public endpoint performs the actual configured signature and drift checks and returns a privacy-safe summary. No success state is simulated.
Built to be inspected
Proof your team can run without us.
Start with a public verification call, then use the developer quickstart to create a receipt, verify it offline, change one field, and watch verification fail.
$ curl -s https://leanlogix.ai/api/verify/sprintloop-7b
verified boolean
passport_sha256 string | null
pubkey_fingerprint string | null$ node examples/verify-selection-receipt.mjs
Example response shape. Runtime verification remains authoritative.
Release-control briefings
Evidence, authority, and fail-closed serving.
The shortlist and the decision: how to actually choose a model in 2026
The leaderboards stopped being decisions this year: the top tier sits inside the confidence interval, the harness moves scores more than capability, and production traffic barely correlates with rank. How to use the boards as a shortlist, price the workload instead of the token, and make the decision with your own deterministic evals.
Read briefing- 01Economics7 min readThe meter is the leak: why per-token billing is a governance decision, not a pricing oneA per-token meter is usually filed under cost. In a regulated boundary it is a data-egress decision in disguise — every metered call is a conversation that left, and a record someone else now keeps. The case for a deployment-dependent private-model architecture with no external meter in the inference path.
- 02Provenance7 min readTrust you can re-run: the signed passport, and why a screenshot is not provenanceMost AI trust claims are screenshots of a dashboard you have to believe. LeanLogix signs canonical release evidence and separates a privacy-safe public verification summary from the authenticated raw proof an auditor can recompute offline. What separation of duties looks like when the proof is the product.
- 03Evaluation6 min readA correct answer is not a safe one: why regulated AI needs its own benchmarkGeneral-purpose leaderboards grade the answer. A payer or a bank is liable for the run where a correct answer leaked an identifier or obeyed an injection — failures of the journey, not the destination. What a regulated benchmark scores instead, and why the audit trail is part of the score.
Platform questions
Release control, explained plainly.
What teams need to know about evidence, authority, verification, and the current product boundary.
What is LeanLogix?
LeanLogix is the governed AI release control plane for one invitation-only workspace. It records candidate and evaluation evidence, applies local policy, enforces separation-of-duties approval, signs release passports, and governs a narrow base-serving path. It is not a general inference cloud, GPU host, or claim that every training and serving lane is operational. LeanLogix is built by LockedIn Labs for regulated teams.
How is a model foundry different from a fine-tuning platform or an inference host?
A fine-tuning platform creates weights and an inference host runs them. LeanLogix governs whether an exact release candidate may be promoted and admitted to serving: local evidence, policy, independent approval, a signed passport, and a fail-closed gate. Generic base training and quantization are retired, and fork serving remains unavailable. The product boundary is release authority and evidence, not raw GPU execution.
Can LeanLogix fine-tune open models like Qwen, Llama, or Mistral?
Not through a generic production lane today. Generic base-model training, fine-tuning, and quantization execution are retired pending authoritative base-model and dataset sources. A constrained fork workflow can seal a non-routable candidate artifact, but that does not deploy it, attest loaded weights, mint published lineage, or authorize serving.
What is a signed model passport?
A model passport is canonical release evidence signed with Ed25519: release identity, source job, evaluation and policy results, and independent approval. The anonymous verification endpoint exposes only a privacy-safe server-verified summary. Raw canonical passport bytes, signature, and public key are authenticated member exports; those exported bytes can be verified offline. Selection receipts are a separate public proof format with a zero-dependency Node 22 verifier in the source checkout.
Does LeanLogix prove which model was selected and why?
LeanLogix can seal a route-selection decision into a portable receipt containing the chosen catalog entry, rationale, inputs, body digest, signing fingerprint, and signature state. The zero-dependency source-checkout verifier checks receipt integrity offline; callers must pin the expected authority fingerprint separately to establish authority trust. A selection receipt does not prove artifact identity, loaded weights, execution, or release authority.
How does LeanLogix help with EU AI Act and ISO/IEC 42001 compliance?
LeanLogix supplies process and evidence controls that can support an AI-management-system program: separation of duties, explicit evaluation and policy gates, canonical signed release evidence, and a defensible release trail mapped to AI RMF and ISO/IEC 42001 themes. It is not itself a certification. Public verification is a privacy-safe server-verified summary; authenticated members can export raw proof for offline review.
How does LeanLogix evaluate models for regulated use?
APEX for Regulated AI records deterministic local evidence for failure modes a regulated release owner is liable for: PHI leakage under governance, prompt-injection resistance, separation-of-duties violations, and consent controls. APEX-Regulated is a program in formation: Health-Admin has real probes; Compliance and Modernize are published methodology with development sets forming. Real results, candidate targets, and in-training checkpoints remain explicitly labeled, and LeanLogix does not publish a competitor leaderboard or claim certification.
Where does the model run, and is my data metered or sent out?
LeanLogix is not a general inference cloud. Its narrow base-serving path requires a configured upstream exact-model ID and valid release evidence, and fails closed when those are absent. Current receipts do not prove the exact loaded weights or physical deployment boundary. Fork serving is unavailable and returns HTTP 503 until a real per-fork deployment and loaded-weight attestation exist.
How does LeanLogix relate to MOEModels?
MOEModels owns the upstream decision about the exact model artifact, public evidence, hardware fit, and deployment-validation plan. LeanLogix owns the downstream private release decision: local policy and evaluations, separation of duties, signed passport, serving admission, and runtime evidence. LeanLogix can accept a bounded MOEModels-compatible payload as a read-only blocked draft, but intake never becomes training, release, or serving authority and currently remains blocked without an immutable artifact digest.