ARC1 by LockedIn Labs. Control for the autonomous enterprise.

Your gateways enforce. Your evaluation tools test. Your ledger holds the money. ARC1 joins them, one decision at a time, inside your own tenant.

It starts from the AI spend you already have, read as metadata from the systems that hold it.

Spend, by the teams that own it.

Provider bills, gateway readings and agents’ own reports stay separate sources, mapped to departments, teams and workflows. What no source explains stays in view as a remainder.

Down to the workflow a decision changes.

A model change is decided on one workflow: the work it does, the model it runs on and what it costs. In ARC1 a decision starts there, with a candidate reviewed against the current model and its limits.

Today ARC1 handles model-change decisions. What has run and what is built: chapter 9.

Standard, Global Standard and Data Zone deployments move to Microsoft’s named replacement unless you opted out. Provisioned deployments don’t move; they must be migrated first. The dates can’t be extended.

For regulated workloads, Microsoft’s own migration guide names the review as the bottleneck. Its advice is to “evaluate available models using your application and data, comparing quality, latency, and cost.” The same guide says teams rarely record what they changed, or why.

Microsoft Learn, Foundry model retirement schedule, Appendix B (page dated 21 Sep 2026, read 7 Oct 2026). Non-preview Azure OpenAI and Anthropic text and reasoning models retiring 14 Oct 2026 to 9 Feb 2027 inclusive; 18 table rows, Haiku 4.5 hosting variants counted once, give 17; count by LockedIn Labs. Whether a workload moves depends on its deployment type and upgrade setting.

Microsoft Learn: model migration guide (updated 26 Aug 2026); models lifecycle policy (updated 24 Jul 2026). Microsoft’s schedule ↗

Each decision becomes one record: what triggered it, what was compared, who approved it, where it landed and what it cost.

The record view downloads it as a decision packet.

• Trigger
• Options, priced on the workflow’s own token mix
• Limits, registered before results
• Approval by a second person
• Published to your gateways, read back
• Follow-up
• The month’s spend against the forecast

The evidence keeps its limits.

On this decision, three comparisons of 200 paired requests each were registered with their limits. Two stayed within them; one missed on quality, errors and latency, and the record says so in words.

Synthetic health plan · synthetic data. Pricing the vendor’s default as its own option is planned, and so is recording outcome counts with the decision.

One option meets the limits. The same 200 paired tasks run against each option, judged by limits registered before anyone sees a result.

Quality

no more than 2 points below the baseline

Errors

no more than 1%

Latency

no more than 1,000 ms at the 95th percentile

Cost

at least 10% lower per accepted result

Unknown prices stay unknown. Select an option to see why it passes or misses.

Worked example: claims-correspondence summarization, 200 paired imaginary tasks per option against a 95% baseline. Imaginary rates, not vendor prices.

An administrator proposes a policy and a second person approves it. A different person with finance authority closes the month.

The approval is a separate, signed step. A change that tries to skip it is refused.

Lab run, 6 Oct 2026: self-approval and execution before approval were both refused. Receipts are signed by the deployment’s key, not by each person.

Your gateways enforce. ARC1 stays out of the request path.

Example rules: labeled plan member IDs and MRNs blocked in prompts; secrets blocked in coding-agent prompts; a daily token quota per person at API Management. Where a gateway cannot carry a rule, the decision says so.

Configuration out, evidence in.

One approved policy is compiled for supported gateways and coding-agent hooks, and each target’s reported configuration is compared with the signed version. A match is configuration evidence; enforcement needs its own request records.

Lab run, 6 Oct 2026: one Kong OSS 3.9.3 node, two routes, no inference, not a customer gateway. API Management and coding-agent settings are built, not yet run live.

ARC1 reads your ledger. It never posts to it.

In ARC1 the forecast is approved before its month begins, and the closed month’s ledger lines are assigned to it.

Synthetic health plan · synthetic data. Worked-example arithmetic: not a saving, not a finance attestation.

Results, held to the ledger.

A business case names its owner and locks its baseline at approval. Forecast, provisional value and finance-approved allocation stay separate, and a different person with finance authority closes the month.

Every product screen in this tour comes from our hosted reference deployment, on a fictional health plan’s synthetic data. No customer has closed a month in ARC1 yet.

As of 7 October 2026. Record, follow-up and forecast paths tested in disposable databases; the worked example is a fictional illustration and writes no records. Lab: one Kong OSS 3.9.3 node, 6 Oct 2026.

The roadmap →Trust and data boundary →

ARC1 sits above your request path and reads what you already run. Your pipeline still ships every change.

Connectors are tested against each vendor’s documented interface; Kong is the one exercised against a running gateway, in our lab. Marks belong to their owners.

Your tools already produce every number.

Usage, cost, identity and approvals are read where they already live, and an approved export goes to the tools your teams already watch.

Trademarks belong to their owners. API Management and the ServiceNow connector are built, not yet run live.

Metadata only

Requests never pass through ARC1. The usage reporting contract excludes prompts, responses, source code and local paths.

In your environment

One deployment for one organization, in your environment, signed in through your identity provider.

How it installs

Container image, Helm chart, PostgreSQL; Azure templates for Container Apps. No connection to LockedIn Labs required.

Signed receipts

Every proposal, approval and policy change is kept as an Ed25519-signed receipt, chained to the one before it and verifiable offline.

Two people sign

Every change is proposed by one person and approved by another.

Publishing to a gateway needs a write identity you grant, limited to what ARC1 owns, and a second approval on every change.

Security →Trust and data boundary →

We need a place to run it, an Entra app registration, reader roles on one gateway and the billing export, and two named approvers. The check against your ledger follows when the forecast month closes.

How a design partnership works →