Design Partners
Shape a scoped private deployment pilot with us
InvarLock OSS is public and usable now. This page is for model risk, validation, governance, and ML platform teams that want to apply its signed-evidence transaction, evaluator boundary, and recipient handoff inside one private release-review workflow before broader packaging is defined.
Fit check
Best fit right now
- You already review model artifacts before release and need independently replayable evidence around those decisions.
- You have a named owner for model approval, validation, or governance.
- Private deployment constraints materially affect where and how the review workflow must run.
- You are comfortable shaping the pilot before final packaging is locked down.
Pilot
What a pilot looks like
This is a scoped engagement around one real release-review workflow, not a platform-wide rollout or a finished SKU handoff.
Pilot shape
- One real review workflow, not a platform-wide rollout.
- Direct work on deployment shape, evidence handoff, approval flow, and operator support.
- A paid, scoped engagement with explicit success criteria.
- A clear decision at the end: keep using OSS only, continue the pilot, or move into a broader commercial deployment.
Confirm fit
We start with your current review process, named approval owner, deployment constraints, and whether a design-partner conversation is the right path.
Scope one workflow
We map one real release-review workflow, including deployment shape, evidence handoff, approval flow, and operator support.
Define the decision
We set explicit success criteria and a clear end state: stay on OSS only, continue the pilot, or move toward a broader commercial deployment.
Current state
What exists today
- The public OSS engine, closed request contract, canonical signed evidence bundle, independent verification receipt, and authenticated report.
- Built-in Hugging Face text execution plus coordinated optional GGUF, vision-text, TensorRT-LLM, and diagnostic distributions.
- Evaluator-neutral qualification contracts, a companion CLI and Python API, reviewed example adapters, and strict per-record versus observation-only authority.
- A canonical in-toto/DSSE acceptance envelope, recipient policy contract, exact artifact binding, and OPA/Rego and CUE interoperability examples.
Refinement
What design partners help refine
- How external or proprietary evaluator output is retained, normalized, and replayed through the evaluator-neutral boundary.
- How per-record imports, artifact delivery, receipt verification, envelope signing, trust registries, and current recipient policy operate in practice.
- How authenticated policy projections fit existing OPA/Rego, CUE, offline, assurance, and deployment workflows.
- What scoped implementation and operator support are required around one private release-review workflow.
Compatibility
Compatibility and stability
The design-partner path stays anchored to the public OSS transaction. The goal is to operate its request, runtime, evidence, trust, receipt, and reporting contracts under real private-deployment constraints—not to introduce a second decision model. The scope does not imply a hosted evaluator, hosted policy engine, or automatic organizational approval.
- The OSS engine remains public and usable throughout the engagement.
- Private workflow work is built around the public request, evaluator qualification, evidence, technical receipt, acceptance envelope, and report contracts rather than replacing them.
- v0.13 evidence and receipts remain permanently verifiable and ingestible under their original semantics; present-day acceptance remains subject to current recipient policy.
- Contract compatibility, key and trust-registry ownership, optional-package boundaries, and upgrade expectations are documented before rollout.
Fit
Best fit
This path is for teams that already have a real review problem and want to shape the private deployment workflow around it, rather than waiting for a finished package list.
- Teams already reviewing quantization, merges, pruning, fine-tuning, conversion, compilation, or other model changes before release.
- Organizations with a named owner for model approval, validation, or governance.
- Teams with private deployment constraints that materially affect deployment shape.
- Teams that want evidence for model changes, not just benchmark dashboards.
Not a fit
If one of these is true, the public OSS path or a later commercial conversation is probably the better route.
- You only want the public OSS getting-started path with no partner discussion.
- You need a fully packaged commercial offer immediately.
- You are evaluating vendors only through finalized pricing and SKU comparisons.
Next step
Next step
If this sounds like the right fit, start with a direct conversation about your release-review workflow. If not, the OSS engine, docs, and evidence examples are already available now.