Platform · Release Authority
Make an exact AI release defensible
LeanLogix is the control plane between model creation and production admission. It binds a candidate to local evidence, enforces independent approval, and produces a portable release record. The public signed-selection proof is live; the authenticated release workflow is implemented and tested but still depends on production authentication, database, signing, and serving configuration.
Readiness, not a demo queue
Four states, with the boundary beside each claim
This matrix replaces seeded release rows with facts that can be checked. A live public receipt is deliberately separated from the private release contract and from production infrastructure that still needs configuration.
| Area | State | Evidence | Current boundary |
|---|---|---|---|
| Public proof | LIVE | The public proof API can create a signed selection receipt and verify its integrity under the configured authority. | A selection receipt records a catalog decision. It is not release approval, artifact identity, inference, or production execution. |
| Release contract | IMPLEMENTED + TESTED | Server-side code derives a release record from an authoritative completed job, applies local policy, and rejects approval by the trainer. | A real production release still requires configured authentication, database state, signing authority, and an eligible completed job. |
| Authenticated control plane | CONFIGURATION REQUIRED | Private routes are designed to fail closed when the session or data authority is unavailable. | Production session secrets, Supabase migrations, member profiles, and a complete authenticated exercise remain operational prerequisites. |
| Serving admission | CONDITIONAL | The narrow base-serving gate requires valid release evidence and a configured upstream exact-model ID; otherwise it refuses the request. | LeanLogix does not yet prove loaded weights or a physical deployment boundary. Fork serving remains unavailable and returns HTTP 503. |
The authority invariant
The trainer cannot authorize the same candidate
The differentiated product is not another registry or eval dashboard. It is the local decision boundary that consumes those inputs, names who may approve, and refuses promotion when the authority contract is incomplete.
Enforced in the contract
The server compares authenticated identities and rejects self-approval. A client-side label cannot satisfy or bypass the invariant.
Evidence stays attributable
The candidate, evaluation, policy result, trainer, approver, and decision remain part of one canonical release record.
Trust is independently pinned
A signature proves integrity only when the verifier also pins the expected authority. The public developer path makes that distinction explicit.
The artifact contract
What a release passport can prove
A configured release workflow can sign canonical data about an exact candidate, its evidence, and its approval. It cannot prove a loaded runtime weight or a physical location unless a separate trusted attestation supplies that fact.
candidate_id: "job_…"
artifact_digest: "sha256:…"
policy_verdict: "passed"
trainer: "principal:…"
approver: "principal:…"
authority_fingerprint: "spki-sha256:…"
signature: "ed25519:…"
runtime_attestation: null # not inferred
Values above are placeholders that show the contract shape. Canonical passport bytes are a private authenticated export; the public catalog exposes only a privacy-safe, server-verified summary.
The release contract
Six decisions from candidate to governed admission
The sequence is implemented and tested as a software contract. Calling it production-ready still requires the authenticated database workflow, keys, users, upstream serving identity, and a post-deploy exercise to be configured and verified.
Framework support
Evidence that can support AI RMF and ISO/IEC 42001 work
LeanLogix maps release controls to durable evidence artifacts. That can make an organization's governance work easier to demonstrate, but it is not certification, legal advice, or proof that a deployment complies with a framework.
NIST AI RMF
Govern · Map · Measure · Manage
- —Govern — make the decision authority and independent approver explicit.
- —Map — bind the exact candidate to its lineage and deployment plan.
- —Measure — retain local evaluation and policy evidence with the decision.
- —Manage — refuse admission when required evidence is absent or stale.
ISO / IEC 42001
Management-system evidence
- —Lifecycle records — preserve what decision occurred and which evidence supported it.
- —Roles — distinguish the principal who produced a candidate from the principal who approved it.
- —Traceability — bind artifact identity, policy, evaluation, decision, and authority.
- —Change control — require a new decision when material release evidence changes.
Inspect the proof before trusting the platform
Start with the live, bounded selection receipt and its pinned-authority verifier. Then review the implemented release contract and the production prerequisites that remain deliberately visible.