Why LeanLogix

When a regulated team needs its own model, the question is whether it is actually yours — and provable.

Generic fine-tuning platforms hand you a model on a shared, metered plane. Hyperscaler model services keep it inside their cloud and meter every token. LeanLogix is the private model foundry built the other way: a model forked per customer, served inside your boundary with no external token meter, and shipped with a signed AI bill of materials you can re-verify offline. The foundry-of-record for owned, attestable, in-boundary models.

See a signed passportRead the comparison

1:1

A model forked per customer — own adapter, own lineage

0

External token meter on in-boundary serving

Ed25519

Signed passport · re-verify offline at /api/verify

2

Frameworks in view · EU AI Act · ISO/IEC 42001

The triad

Three properties no managed plane ships together.

Each one exists elsewhere in isolation. The foundry-of-record is the combination: a model that is yours, served where your data already is, carrying proof of its own provenance.

Forked per customer

A distinct model per customer with its own adapter and lineage — not a shared base with co-tenanted adapters. The fork-order API makes per-tenant isolation a product you can demo, not a policy you assert.

Served in your boundary, no meter

Inference runs inside your environment on infrastructure you control, at a flat license. No PHI or IP egress, and no external per-token meter on the conversation — the piece a metered plane cannot copy without breaking its own model.

A passport you re-verify offline

Every release is sealed with an Ed25519 signature over its exact lineage bytes. An auditor re-checks it on an air-gapped box with the artifact and a public key — no dashboard, no account, no trust in our uptime.

The shape of the alternatives

Someone else holds the model, the meter, and the lineage.

Generic fine-tuning and MLOps platforms typically train and serve from a shared or managed plane, billed per token or per request. Hyperscaler managed-model services keep your model inside their cloud account and meter inference. In both cases the model runs somewhere you do not own, the cost scales with every call forever, and the record of what trained it is a metadata log you are asked to trust.

The LeanLogix answer

The model is forked for you, runs in your boundary, and proves itself.

LeanLogix forks a model per customer, serves it inside your environment with no external token meter, and seals every release with an Ed25519-signed AI bill of materials — base model, datasets and what was held out of the weights, eval verdict, and approver. An auditor re-verifies that record offline, against a public key, without a LeanLogix account. The compliance passport is the product, not a feature.

The comparison

Two alternatives. The same two questions decide it.

Read it the way a procurement and security team reads it: is the model genuinely yours and in your boundary, and can you prove what went into it after the fact. The LeanLogix column states architecture we can back — 'by construction', 'by design', 'fail-closed' — not a benchmark. The rival columns describe the shape of a category, with the public record cited and our own claims tagged as design properties.

A · vs. generic fine-tuning & MLOps platforms

DimensionLeanLogixGeneric fine-tuning / MLOps platforms
Whose boundary the model runs in

The model is forked per customer and served inside your environment. Model and data never leave your boundary, so there is no PHI/IP egress and no vendor cloud in the inference path.

The managed-plane / shared-serving architecture of fine-tuning platforms is public. In-boundary, per-customer serving is a LeanLogix design property.

Generic fine-tuning and MLOps platforms typically train and serve from a shared or managed plane; the model runs in the vendor's environment and inference crosses a vendor boundary.

How you pay for inference

Serving is in-boundary on infrastructure you control — a flat license, with no external per-token or per-request meter on a conversation.

Per-token / per-request billing is the published model of hosted inference platforms generally. We frame our no-meter serving as a design property, not a specific dollar comparison against any named rival.

Hosted fine-tuning platforms are typically billed per token or per request, so cost scales with usage indefinitely.

Tenant isolation between customers

Each customer gets a distinct fork with its own adapter and its own lineage. One tenant's data provably never enters another tenant's model — per-tenant isolation is a first-class, demoable product (the fork-order API).

Co-tenanted adapter serving is a known industry pattern. Per-tenant forks with a separate signed lineage each is a LeanLogix design property.

Some platforms co-tenant adapters over a shared base for serving efficiency; isolation is then an operational policy rather than a separate signed lineage per customer.

Proof of what trained the model

Every release carries a cryptographically signed AI bill of materials — base, datasets, exclusions (training_excludes_phi), eval verdict, and an independent approver — verifiable offline against the public key.

A cryptographically signed, offline-re-verifiable training-data lineage is a LeanLogix design property; the live check runs at /api/verify.

Training lineage on these platforms is typically a metadata log inside the product — useful, but trusted rather than independently re-verifiable away from the dashboard.

What the regulator can later confirm

The signed passport is the artifact a regulated builder hands an auditor: it re-derives and checks the signature on an air-gapped machine, after the fact, with nothing but the artifact and a public key.

EU AI Act obligations (incl. provenance/record-keeping and retention) and ISO/IEC 42001 AI-management expectations are public; how a builder meets them with a portable signed record is a LeanLogix design property.

Without a portable signed record, after-the-fact proof depends on the vendor still being available and the dashboard still telling the same story.

Whose boundary the model runs in

LeanLogix

The model is forked per customer and served inside your environment. Model and data never leave your boundary, so there is no PHI/IP egress and no vendor cloud in the inference path.

Generic fine-tuning / MLOps platforms

Generic fine-tuning and MLOps platforms typically train and serve from a shared or managed plane; the model runs in the vendor's environment and inference crosses a vendor boundary.

The managed-plane / shared-serving architecture of fine-tuning platforms is public. In-boundary, per-customer serving is a LeanLogix design property.

How you pay for inference

LeanLogix

Serving is in-boundary on infrastructure you control — a flat license, with no external per-token or per-request meter on a conversation.

Generic fine-tuning / MLOps platforms

Hosted fine-tuning platforms are typically billed per token or per request, so cost scales with usage indefinitely.

Per-token / per-request billing is the published model of hosted inference platforms generally. We frame our no-meter serving as a design property, not a specific dollar comparison against any named rival.

Tenant isolation between customers

LeanLogix

Each customer gets a distinct fork with its own adapter and its own lineage. One tenant's data provably never enters another tenant's model — per-tenant isolation is a first-class, demoable product (the fork-order API).

Generic fine-tuning / MLOps platforms

Some platforms co-tenant adapters over a shared base for serving efficiency; isolation is then an operational policy rather than a separate signed lineage per customer.

Co-tenanted adapter serving is a known industry pattern. Per-tenant forks with a separate signed lineage each is a LeanLogix design property.

Proof of what trained the model

LeanLogix

Every release carries a cryptographically signed AI bill of materials — base, datasets, exclusions (training_excludes_phi), eval verdict, and an independent approver — verifiable offline against the public key.

Generic fine-tuning / MLOps platforms

Training lineage on these platforms is typically a metadata log inside the product — useful, but trusted rather than independently re-verifiable away from the dashboard.

A cryptographically signed, offline-re-verifiable training-data lineage is a LeanLogix design property; the live check runs at /api/verify.

What the regulator can later confirm

LeanLogix

The signed passport is the artifact a regulated builder hands an auditor: it re-derives and checks the signature on an air-gapped machine, after the fact, with nothing but the artifact and a public key.

Generic fine-tuning / MLOps platforms

Without a portable signed record, after-the-fact proof depends on the vendor still being available and the dashboard still telling the same story.

EU AI Act obligations (incl. provenance/record-keeping and retention) and ISO/IEC 42001 AI-management expectations are public; how a builder meets them with a portable signed record is a LeanLogix design property.

B · vs. hyperscaler managed-model services

DimensionLeanLogixHyperscaler managed-model services
What 'your account' actually means

The fork is deployed cloud-agnostically into the environment you own — AWS, GCP, Azure, on-prem, or hybrid — chosen in your interest, not ours. The model is genuinely yours.

Hyperscaler managed-model services run within that provider's platform — public. Cloud-agnostic in-boundary deployment is a LeanLogix design property.

A managed-model service running 'in your account' still executes inside the provider's cloud and on the provider's terms; portability across clouds is constrained by the platform.

Serving your own fine-tuned model

Your forked model is served in-boundary at a flat license — no separate provisioned-throughput rental to keep your own model warm.

Provisioned-throughput serving for custom models is a documented hyperscaler pattern. No-meter in-boundary serving is a LeanLogix design property; we make no specific price claim about any provider.

Serving a customer-tuned model on a hyperscaler typically requires renting dedicated/provisioned throughput in addition to per-token usage.

Data residency for sensitive workloads

PHI and IP stay inside your boundary by construction; there is no BAA chain to assemble because nothing leaves. A fail-closed gate holds protected data out of the weights.

BAA/residency programs of major clouds are public. PHI/IP never leaving the boundary, enforced by a fail-closed gate, is a LeanLogix design property.

Managed services can be configured for residency and offer BAAs, but the data still transits and is processed within the provider's environment.

Independent, portable compliance evidence

A signed compliance passport travels with the model and re-verifies offline — evidence that does not depend on the provider's console, contract, or continued existence.

Provider-native governance tooling is public. An offline, provider-independent, Ed25519-signed passport is a LeanLogix design property.

Audit and lineage evidence is generally surfaced through the provider's own governance tooling, inside the provider's platform.

What 'your account' actually means

LeanLogix

The fork is deployed cloud-agnostically into the environment you own — AWS, GCP, Azure, on-prem, or hybrid — chosen in your interest, not ours. The model is genuinely yours.

Hyperscaler managed-model services

A managed-model service running 'in your account' still executes inside the provider's cloud and on the provider's terms; portability across clouds is constrained by the platform.

Hyperscaler managed-model services run within that provider's platform — public. Cloud-agnostic in-boundary deployment is a LeanLogix design property.

Serving your own fine-tuned model

LeanLogix

Your forked model is served in-boundary at a flat license — no separate provisioned-throughput rental to keep your own model warm.

Hyperscaler managed-model services

Serving a customer-tuned model on a hyperscaler typically requires renting dedicated/provisioned throughput in addition to per-token usage.

Provisioned-throughput serving for custom models is a documented hyperscaler pattern. No-meter in-boundary serving is a LeanLogix design property; we make no specific price claim about any provider.

Data residency for sensitive workloads

LeanLogix

PHI and IP stay inside your boundary by construction; there is no BAA chain to assemble because nothing leaves. A fail-closed gate holds protected data out of the weights.

Hyperscaler managed-model services

Managed services can be configured for residency and offer BAAs, but the data still transits and is processed within the provider's environment.

BAA/residency programs of major clouds are public. PHI/IP never leaving the boundary, enforced by a fail-closed gate, is a LeanLogix design property.

Independent, portable compliance evidence

LeanLogix

A signed compliance passport travels with the model and re-verifies offline — evidence that does not depend on the provider's console, contract, or continued existence.

Hyperscaler managed-model services

Audit and lineage evidence is generally surfaced through the provider's own governance tooling, inside the provider's platform.

Provider-native governance tooling is public. An offline, provider-independent, Ed25519-signed passport is a LeanLogix design property.

The rival columns are category statements about an architectural shape — a shared/managed serving plane, per-token billing, provider-native governance — not unsourced claims about any specific vendor's pricing or a feature it lacks. Statements about LeanLogix describe how the system is built, not measured head-to-head numbers. There are no benchmark figures, savings percentages, customer names, or certifications on this page because none of those would be honest to assert yet.

Why this matters now

Provenance and an AI bill of materials are becoming table stakes.

The reason a signed, re-verifiable lineage stops being a nice-to-have is regulatory, and it is public. Two forces converge: enforcement powers that ask you to show what trained a model and to keep that record, and a management standard procurement teams increasingly require before they buy.

EU

EU AI Act — provenance & record-keeping

The EU AI Act phases in obligations through 2026 and beyond, including technical documentation, record-keeping, and provenance expectations for higher-risk and general-purpose AI — backed by enforcement powers and penalties. A model whose training lineage you cannot produce after the fact becomes a liability, not just a gap.

ISO

ISO/IEC 42001 — the AI management system

ISO/IEC 42001 (published 2023) is the first management-system standard for AI. As enterprises adopt it, an auditable trail of how each model was built, evaluated, and approved moves from differentiator to procurement requirement — the kind of evidence a buyer's risk team asks for before signing.

BOM

The AI-BOM the auditor asks for

An AI bill of materials — base model, data lineage, exclusions, eval, and approver — is the artifact those frameworks point at. LeanLogix produces it as a signed, offline-re-verifiable record by construction, so it exists by the time a model ships, not when a regulator asks.

The EU AI Act and ISO/IEC 42001 are public regulatory and standards facts. LeanLogix maps its capabilities to them to make evidence concrete; this is a framework mapping, not a claim of certification, accreditation, or deployed customer compliance.

What is actually live today

Not a thesis on a slide. Surfaces you can open right now.

These read the live registry, not a mock. The passport's offline verifier hits the same /api/verify endpoint anyone can call to re-check a release independently.

The compliance passport

Per signed model: the full AI bill of materials — base, corpus and exclusions, eval probes, the separation-of-duties signer, and the Ed25519 signature — with a one-click VERIFY that runs the real cryptographic check.

Open the passport board

The model supply chain

One pipeline per model: TRAIN → REGISTER → EVAL-GATE → SERVE → VERSION, every stage bound to a real registry row. The eval gate is shown explicitly and the promote decision is derived, not asserted.

Watch the lifecycle

The per-customer fork loop

create → serve → register → sign lineage → offline-verify, with training_excludes_phi recorded on the lineage. Two tenants from the same base get divergent adapters and two distinct passports.

See the fork orders

Studio surfaces read the live registry. Serving in the demo currently reuses a sealed adapter (servedViaReuse) and runs over a tunnel as a stand-in for “in your boundary”; the production path deploys in-cluster on the same code. Nothing here is faked, and nothing implies a customer fork is live in production today.

Common questions

What buyers and answer engines ask about a private model foundry

Source-true answers on how LeanLogix differs from a fine-tuning platform or an inference host, what a signed model passport proves, and how the foundry maps to the EU AI Act and ISO/IEC 42001.

What is LeanLogix?

LeanLogix is a private model foundry and model-governance control plane. It trains and fine-tunes small models on open foundations (the Qwen2.5 family), then governs the full lifecycle — registry, evals, separation-of-duties release, and a signed model passport. It is the management plane that rides on top of inference, not an inference or GPU host itself. LeanLogix is built by LockedIn Labs for regulated, in-boundary teams in healthcare and finance.

How is a model foundry different from a fine-tuning platform or an inference host?

A generic fine-tuning platform hands you a model on a shared, metered plane; a hyperscaler model service keeps it inside their cloud and meters every token. LeanLogix is built the other way: a model forked per customer, served inside your boundary with no external token meter, and shipped with a signed AI bill of materials you can re-verify offline. The differentiator is governance and provenance — proving why a model was chosen and what went into it — not raw GPU inference, which LeanLogix rides on top of.

Can LeanLogix fine-tune open models like Qwen, Llama, or Mistral?

LeanLogix fine-tunes open foundations with LoRA, QLoRA, DoRA, and GaLore — adapter and full fine-tunes with reproducible recipes, run inside your boundary on your data. The trained base for governed models published today is the Qwen2.5 family (Apache-2.0). The Base-Model Advisor helps choose a foundation per task; every build is registered with its base, method, datasets, and eval score.

What is a signed model passport?

A model passport is a signed AI bill of materials for a release — base model, datasets and exclusions, eval probes, the approver, and an Ed25519 signature over the verbatim bytes. Because it is signed over the bytes, an auditor recomputes the fingerprint offline with curl and a public key and gets the result rather than your word. A model selection can also carry a portable selection receipt that re-verifies at the central public verifier, lockedinlabs.ai/verify, with nothing of LeanLogix's in the trust path.

Does LeanLogix prove which model was selected and why?

Yes. The Sovereign Router classifies a request, scores the routable catalog on capability, cost, latency, and availability, and serves the chosen model only after re-verifying its Ed25519 passport at request time. The selection is sealed into a portable, signed selection receipt — so the choice of model is itself an offline-verifiable record, not an opaque routing decision. That selection-proof is the headline differentiator: anyone can serve you a model; LeanLogix proves why this one was chosen.

How does LeanLogix help with EU AI Act and ISO/IEC 42001 compliance?

LeanLogix is governance-first by construction: separation of duties between trainer and approver, evidence captured as a signed artifact rather than a screenshot, and a defensible release trail mapped to the AI RMF and ISO/IEC 42001 themes. The signed passport makes consent and no-PHI-in-weights an offline-verifiable, scored dimension. LeanLogix supplies the evidence and process structure that support an AI-management-system program; it is not itself a certification.

How does LeanLogix evaluate models for regulated use?

Through APEX for Regulated AI — a deterministic, signed, offline-verifiable benchmark for the failure modes a regulated buyer is liable for: PHI-leakage under governance, prompt-injection resistance, separation-of-duties violations, and consent-based training. A correct answer is not a safe one, so the audit trail is part of the score. APEX-Regulated is a program in formation — Health-Admin has real probes today; Compliance and Modernize are published as methodology with dev sets forming — and LeanLogix publishes only its own models' real, signed scores.

Where does the model run, and is my data metered or sent out?

Governed models are forked per customer and served inside your boundary with no external token meter in the inference path. A per-token meter is a data-egress decision in disguise inside a regulated boundary — every metered call is a record someone else keeps — so LeanLogix favors serving private models at a flat license with nothing external in the inference path. Healthcare models are trained on public corpora with PHI handled at runtime via retrieval, never baked into weights.

Bring one model. Walk it from fork to a signed passport.

Open the studio and follow a model through the supply chain — registered datasets, the eval gate, the per-customer fork, and the Ed25519 passport you re-verify offline. The proof is the product.

Open the passport boardSee the governance model