Platform · Release & Evidence
Ship a model with a passport, not a promise
A regulated release has to answer one question on demand: prove this model is what you say it is. LeanLogix enforces separation of duties at the approval gate — the reviewer is never the trainer — and seals each approved build into a signed, re-verifiable passport: the same record a procurement reviewer and an auditor can both check. The gate is live; the first models are moving through it now.
The control that matters
Separation of duties — the trainer cannot approve their own model
The most common governance gap is the simplest one: the person who built the model also signs off on it. LeanLogix makes that impossible. Approval requires a distinct identity, and the system records who approved what — so the evidence shows an independent reviewer, every time.
Enforced, not advised
The approval action is gated on a different identity than the one that trained the build. There is no checkbox to override it — self-approval is structurally unavailable.
The approver is in the record
The passport names the reviewer and the basis for approval. "reviewer ≠ trainer ✓" is not marketing copy — it is the literal attestation stored with the release.
Pending is visible
A build awaiting compliance or security review sits in pending state with its evidence still building. Nothing is promoted on someone's say-so while the review is open.
The artifact
The model passport
A passport is a signed, re-verifiable record of everything that decides whether a model is safe to run: what it learned from, how it was built, how it scored, who approved it, and a hash that lets any party re-check the whole thing. This is the passport schema the gate seals on approval — the signature and verified fields fill in the moment a build's artifact is stored, hashed, and signed.
model: "sprintloop-7b"
version: "v3"
base: "Qwen2.5-Coder-7B-Instruct"
dataset: "sprintloop-corpus@2800"
method: "LoRA / MLX"
eval: { readiness: "passed", leakage: 0 }
approver: "reviewer ≠ trainer"
content_hash: "sha256:9f2c…b41e"
signature: "ed25519:a7d3…" # verify offline
Hash and signature values shown are illustrative. A passport seals into a real, re-checkable digest the moment a build's artifact is stored and hashed — the registry shows the working state, never a seal it cannot back.
The release queue
What is approved, what is pending
Every release carries a verdict, a named approval basis, and an evidence state. Pending builds wait for their reviewer; only a signed passport ships.
rel-312 has cleared review and is staged for seal — its passport finalizes the moment the artifact is stored and hashed. rel-318 and rel-319 are held in pending — one awaiting compliance, one awaiting security — with evidence still building. The queue is the audit trail: nothing is approved until a different person signs it, and the constraint that the approver is never the trainer is enforced in the data layer, not just asked for here.
The gate, end to end
Six steps from build to monitored release
The release gate is a fixed sequence. Each step writes to the passport, and step 3 — review by a different person — is the one that makes the rest defensible.
Mapped to the frameworks
Evidence that maps to AI RMF and ISO/IEC 42001
A passport is not just internal hygiene — it is the artifact a regulated buyer and an auditor ask for. LeanLogix maps the release controls to the two frameworks regulated teams are measured against.
NIST AI RMF
Govern · Map · Measure · Manage
- —Govern — separation of duties is enforced at the approval gate, with the reviewer named in the record.
- —Map — lineage links base, dataset, and method so the model's context is explicit.
- —Measure — the ten-category eval suite produces the readiness and leakage numbers in the passport.
- —Manage — production monitoring reopens the gate on regression, closing the loop.
ISO / IEC 42001
AI management system controls
- —Documented lifecycle — the six-step gate is the operational record of how a model is released.
- —Roles and responsibilities — the trainer and the approver are distinct, recorded identities.
- —Records and traceability — the signed passport is the re-verifiable artifact the standard expects.
- —Continual improvement — the autoresearch loop and production monitoring feed the next cycle.
Framework mapping describes how the release controls correspond to AI RMF and ISO/IEC 42001 expectations. It is a mapping of controls to artifacts, not a claim of third-party certification.
Release a model an auditor can verify
Open the studio, run a build through the gate, and watch the passport seal — separation of duties enforced, evidence signed, re-verifiable from the hash.