Why LeanLogix

The question is not only what model to use. It is who can authorize the exact release.

LeanLogix is the governed release control plane between AI creation and production. It consumes artifact and evidence inputs from the systems teams already use, applies private policy, enforces independent approval, signs the decision, and fails closed at serving admission. The public selection receipt is live; authenticated production release still requires configuration and an end-to-end exercise.

Verify the public proofRead the product boundary

LIVE

Public signed selection receipt · not release approval

TESTED

Server-derived release and independent-approval contract

503

Fork serving remains unavailable by design

NOT PROVIDED

Loaded-weight or physical-boundary attestation

The authority loop

Identity, decision, and enforcement stay connected.

The product becomes valuable when the same exact candidate flows through local policy, accountable approval, signed evidence, and a gate that refuses when the decision no longer applies.

Exact release identity

Start from authoritative server-side candidate facts and an immutable artifact identity. Do not let a UI declaration become provenance.

Independent local authority

Apply private evidence and policy, require a different approver, and sign the resulting allow-or-refuse decision under an authority the verifier can pin.

Conditional runtime admission

Recheck release evidence and exact upstream identity at serving time. Refuse when either is absent, while leaving unproved runtime facts explicitly unknown.

Strong systems already exist

Build, registry, eval, observability, policy, and signing tools create essential evidence.

LeanLogix does not need those categories to be empty. It becomes more useful when it can ingest their artifact identity, measurements, controls, and attestations as attributable inputs.

The LeanLogix decision

Is this exact candidate authorized for this local production context?

LeanLogix binds the candidate to private evidence and policy, requires a different approver, signs the resulting decision, and lets a serving gate refuse when authority or identity is missing.

The product boundary

LeanLogix owns the release decision, not every system around it.

The strongest positioning is additive: artifact, evaluation, registry, governance, policy, signing, and serving systems remain valuable. LeanLogix turns their attributable inputs into one local decision and makes the refusal path enforceable.

A · the release-authority handoff

DimensionLeanLogix authorityEvidence sources / infrastructure
Exact candidate identity

The release contract derives from a server-loaded, typed, completed job and its artifact identity. Client-supplied lineage cannot become release truth by assertion.

Current state: implemented and tested locally; production database reconciliation and an eligible completed job are still required.

Builders and registries remain the upstream sources for artifact, version, lineage, and lifecycle facts.

Local evidence and policy

The deploying organization decides which private evaluations, risk thresholds, and exceptions make this candidate eligible for this workload.

Product boundary: LeanLogix consumes attributable evidence; it does not claim to replace every evidence producer.

Evaluation, observability, security, and policy systems can supply measurements and decisions without becoming the local release authority.

Independent approval

The authenticated approver must be distinct from the trainer. The server rejects self-approval rather than depending on a UI label or checklist.

Current state: the separation-of-duties invariant is implemented and tested; production users and session configuration remain prerequisites.

Governance and workflow systems can manage organizational reviews, controls, inventories, and reporting around the same release.

Portable decision proof

Canonical release data can be signed under a configured authority. A verifier must pin the expected authority as well as check signature integrity.

Boundary: a signature authenticates its record. It does not independently prove loaded runtime weights, execution, or physical location.

Signing, provenance, and attestation standards provide useful trust primitives and interoperable formats for the broader supply chain.

Serving admission

The narrow base-serving gate requires valid release evidence and a configured upstream exact-model ID, and refuses the request when either is absent.

Current state: conditional base admission exists; fork serving is unavailable and loaded-weight and physical-boundary attestations are not provided.

Serving infrastructure still runs the model. A future trusted runtime attestation can add endpoint-to-weight and deployment facts to the decision.

Exact candidate identity

LeanLogix authority

The release contract derives from a server-loaded, typed, completed job and its artifact identity. Client-supplied lineage cannot become release truth by assertion.

Evidence sources / infrastructure

Builders and registries remain the upstream sources for artifact, version, lineage, and lifecycle facts.

Current state: implemented and tested locally; production database reconciliation and an eligible completed job are still required.

Local evidence and policy

LeanLogix authority

The deploying organization decides which private evaluations, risk thresholds, and exceptions make this candidate eligible for this workload.

Evidence sources / infrastructure

Evaluation, observability, security, and policy systems can supply measurements and decisions without becoming the local release authority.

Product boundary: LeanLogix consumes attributable evidence; it does not claim to replace every evidence producer.

Independent approval

LeanLogix authority

The authenticated approver must be distinct from the trainer. The server rejects self-approval rather than depending on a UI label or checklist.

Evidence sources / infrastructure

Governance and workflow systems can manage organizational reviews, controls, inventories, and reporting around the same release.

Current state: the separation-of-duties invariant is implemented and tested; production users and session configuration remain prerequisites.

Portable decision proof

LeanLogix authority

Canonical release data can be signed under a configured authority. A verifier must pin the expected authority as well as check signature integrity.

Evidence sources / infrastructure

Signing, provenance, and attestation standards provide useful trust primitives and interoperable formats for the broader supply chain.

Boundary: a signature authenticates its record. It does not independently prove loaded runtime weights, execution, or physical location.

Serving admission

LeanLogix authority

The narrow base-serving gate requires valid release evidence and a configured upstream exact-model ID, and refuses the request when either is absent.

Evidence sources / infrastructure

Serving infrastructure still runs the model. A future trusted runtime attestation can add endpoint-to-weight and deployment facts to the decision.

Current state: conditional base admission exists; fork serving is unavailable and loaded-weight and physical-boundary attestations are not provided.

B · the MOEModels portfolio handoff

DimensionLeanLogix · downstream authorityMOEModels · upstream decision
Model and artifact decision

Consumes an upstream decision only as a bounded, blocked draft. Intake performs no remote fetch, persistence, training, promotion, or serving mutation.

Boundary: an upstream recommendation is evidence for a later workflow; it is never release authority by itself.

MOEModels owns the upstream exact model, artifact revision, public evidence, hardware fit, and deployment-validation plan.

Immutable release identity

Requires the local candidate and digest to be resolved from authoritative release inputs before promotion can be considered.

Current intake remains blocked when the plan lacks an immutable artifact digest.

MOEModels should carry an exact artifact and revision into the handoff so the local workflow can validate rather than guess identity.

Private authorization

Owns private evaluation, local policy, independent approval, the signed release record, and the allow-or-refuse decision.

Portfolio principle: upstream intelligence and downstream authority should remain explicit, composable responsibilities.

MOEModels can explain upstream fit and selection rationale without seeing or controlling the deploying organization's private approval policy.

Runtime responsibility

Owns the release-admission check and runtime evidence contract, while refusing when required release or upstream identity is missing.

Neither product should claim loaded-weight or physical-boundary proof until a trusted runtime attestation actually establishes it.

MOEModels owns the deployment-validation plan; serving infrastructure executes it and must eventually provide trusted runtime facts.

Model and artifact decision

LeanLogix · downstream authority

Consumes an upstream decision only as a bounded, blocked draft. Intake performs no remote fetch, persistence, training, promotion, or serving mutation.

MOEModels · upstream decision

MOEModels owns the upstream exact model, artifact revision, public evidence, hardware fit, and deployment-validation plan.

Boundary: an upstream recommendation is evidence for a later workflow; it is never release authority by itself.

Immutable release identity

LeanLogix · downstream authority

Requires the local candidate and digest to be resolved from authoritative release inputs before promotion can be considered.

MOEModels · upstream decision

MOEModels should carry an exact artifact and revision into the handoff so the local workflow can validate rather than guess identity.

Current intake remains blocked when the plan lacks an immutable artifact digest.

Private authorization

LeanLogix · downstream authority

Owns private evaluation, local policy, independent approval, the signed release record, and the allow-or-refuse decision.

MOEModels · upstream decision

MOEModels can explain upstream fit and selection rationale without seeing or controlling the deploying organization's private approval policy.

Portfolio principle: upstream intelligence and downstream authority should remain explicit, composable responsibilities.

Runtime responsibility

LeanLogix · downstream authority

Owns the release-admission check and runtime evidence contract, while refusing when required release or upstream identity is missing.

MOEModels · upstream decision

MOEModels owns the deployment-validation plan; serving infrastructure executes it and must eventually provide trusted runtime facts.

Neither product should claim loaded-weight or physical-boundary proof until a trusted runtime attestation actually establishes it.

These tables describe ownership and integration boundaries, not unsupported claims that adjacent products lack features. Product states are labeled as live, implemented and tested, conditional, or configuration-dependent where that distinction matters.

Why the evidence matters

One decision record can support several review conversations.

Release evidence becomes more valuable when engineering, security, risk, procurement, and audit can inspect the same artifact. LeanLogix can support that work without claiming certification or automatic compliance.

01

Candidate and decision traceability

Bind the candidate, artifact identity, evaluation, policy, approver, and decision so reviewers can reconstruct why release was allowed or refused.

02

Accountable approval evidence

Record authenticated trainer and approver identities and enforce their separation in the release contract, not only in process documentation.

03

Truthful scope and exceptions

Preserve what the decision does and does not establish. Unknown runtime or deployment facts remain unknown instead of being inferred from a signature.

Mapping these artifacts to NIST AI RMF, ISO/IEC 42001, or a buyer's internal controls can support governance work. It is not legal advice, certification, accreditation, or proof that a deployment complies with a framework.

What can be checked now

The public proof, release contract, and serving gate are different claims.

The live surface is a bounded selection receipt. The private release contract is implemented and tested. Authenticated production release and serving still require the configuration and evidence stated beside them.

LIVE PUBLIC PROOF

Signed selection receipt

The bounded public API records which curated catalog entry was selected and why, then verifies receipt integrity under the configured authority. It proves neither release approval nor inference.

Run the developer proof IMPLEMENTED + TESTED

Release authority contract

The server-derived release path binds a completed job to policy, independent approval, and signed evidence. Production authentication and database state must still be configured and exercised.

Inspect the release contract CONDITIONAL

Governed serving admission

The narrow base path requires valid release evidence and a configured upstream exact-model ID. It fails closed without either and does not prove loaded weights or physical location.

Read the serving boundary

Fork serving remains unavailable and returns HTTP 503 until a real per-fork deployment and loaded-weight attestation exist. Canonical passport bytes are a private authenticated export; the public catalog exposes a privacy-safe verified summary.

Common questions

What buyers ask about governed release authority

Source-true answers about release evidence, independent approval, verification, serving boundaries, and how LeanLogix differs from a builder, registry, or inference host.

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.

Inspect the authority contract before trusting the claim

Start with the live bounded receipt and pinned-authority verifier. Then review how an authenticated local workflow can bind a completed candidate to policy, independent approval, a signed release record, and fail-closed admission.

Run the developer proofReview release evidence