by LockedIn Labs

Product

Inside ARC1.

The decision workspace, the connected views, a worked decision, the console as it runs, what is true today and the next forced decision. Everything on this page runs on a fictional health plan’s synthetic data.

Inside the workspace

Try the decision workspace.

Price a change against its alternatives, have a second person approve it, and compare the configuration your gateways report back. Review financial evidence on its own source and period.

A connected view

Go from the enterprise to the evidence.

Follow spend into teams and workflows. Inspect model choices, sensitive-data controls and the decisions behind the numbers.

ARC1 views, shown with synthetic data from a fictional health plan.

One coding workflow · synthetic example

Decide whether a cheaper model should proceed.

Compare supplied observations for the same 100 synthetic requests in a bounded coding task. The workflow owner’s acceptance check covers the correct result, required format and stated constraints. These three possible results use ARC1’s built-in comparison engine.

Same-task baseline95 of 100 tasks accepted$0.010526 per accepted result · 180 ms at the 95th percentile

Limits set before collecting the pairsAt most 2 fewer accepted tasks per 100At least 10% lower unit cost · errors at most 2% · latency at most 200 ms

Limits missed

Cheaper requests lose too much accepted work.

82%candidate task acceptance
13 percentage points below baseline

Minimum 93%

Cost per accepted result
$0.007317 30.5% lower
Request errors
5% limit missed
95th-percentile latency
260 ms limit missed

This candidate misses acceptance, error and latency limits.

Limits met

Accepted work costs less within these limits.

94%candidate task acceptance
1 percentage point below baseline

Minimum 93%

Cost per accepted result
$0.006383 39.4% lower
Request errors
1% within limit
95th-percentile latency
160 ms within limit

Review the cohort and task-acceptance labels before a separately approved change.

Incomplete evidence

Missing observations leave the decision open.

Unknowncandidate task acceptance
1 successful request has no task-acceptance label
Task acceptance cannot be compared
Cost per accepted result
Unknown 1 missing cost reading
Request errors
1% within limit
95th-percentile latency
Unknown 1 missing latency reading

Complete the missing evidence in a new comparison before deciding.

Keep the comparison with its reviewed decision. Inspect model eligibility approval, target configuration and follow-up observations as separate evidence; export the exact comparison for the handoff.

Try the comparison in the workspace
Example basis and limits

Built-in synthetic paired observations v1, for 1–2 January 2026. All acceptance labels, costs, latency and errors are invented fixture inputs; no provider or collector is called. Each scenario has 100 paired requests and the same baseline, cohort, rubric and configurations. Cost per accepted result counts every request in the comparison.

Descriptive comparison results do not authorize a route change or establish production savings. Model permission, observed target configuration and financial review remain separate.

The console, as it runs

Follow the evidence.

Six screens from the ARC1 console on a fictional health plan’s synthetic data: compared options, spend, configuration readback, results, receipts and the administrator’s Flow view.

Choose a screen Swipe to explore
01 / 06

01 / Decisions

A cheaper option still has to meet the limits.

Three retained comparisons each use 200 paired synthetic requests. Two meet their registered limits. The compact option misses quality, errors and latency, so its lower price is not enough. Decisions preserves review history; pending approvals and Needs you identify work awaiting action.

Synthetic health plan · synthetic data

ARC1 decision evaluation: three retained comparisons of 200 paired synthetic requests each. Two are within registered limits; one is outside quality, error and latency limits. No production outcome is established.

02 / Spend

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.

Synthetic health plan · synthetic data

The Spend view in the ARC1 console: provider-reported spend for 30 days beside gateway and agent-estimate readings, seven sources, and spend broken down by owning team.

03 / Enforcement

Approved policy, compared with what each target reports.

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.

Synthetic health plan · synthetic data

The Enforcement view in the ARC1 console: for each gateway and coding-agent hook, the approved policy beside the configuration it reports back, and whether the two match.

04 / Results

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.

Synthetic health plan · synthetic data

The Results trace in the ARC1 console: one workflow followed from its tokens and spend, to who uses it, to its outcomes and to the business case whose baseline was locked at approval.
Cropped from the full screen

05 / Evidence

Evidence your auditor can verify.

Every proposal, approval and policy change is an Ed25519-signed receipt, chained to the one before it and verifiable offline. A mapping to ISO/IEC 42001 or the NIST AI RMF is evidence for your auditor, never a conformity finding.

Synthetic health plan · synthetic data

The evidence map in the ARC1 console: ISO/IEC 42001 clauses and NIST AI RMF functions, with the policy versions, approvals, readbacks and signed receipts that map to each, and the gaps where nothing does.
Cropped from the full screen

06 / Administrator

See how the estate is configured.

The administrator’s Flow view places callers, configured gateways and model destinations together, with ARC1’s evidence and approved configuration paths beside them. Pair this view with Enforcement to inspect each target’s reported configuration. The diagram describes architecture; it does not trace individual requests.

Synthetic health plan · synthetic data

ARC1 administrator Flow view: callers, configured gateways and model APIs, with evidence entering ARC1 and approved configuration leaving for supported targets. This is a schematic of the synthetic estate, not a trace of individual requests.

Stated as it stands

What is true today.

What runs, what has been tested and what is planned, in the same words the roadmap uses.

The roadmap Trust and data boundary Security

Built, and run
Everything shown here runs on our hosted reference deployment, on a fictional health plan’s synthetic data. No customer has closed a month in ARC1 yet.
One gateway, in the lab
Kong Gateway, open-source edition 3.9.3, has been exercised against a running node in our lab for policy apply, readback and drift recovery; that run did not establish successful model inference. Every other connector is tested against the vendor’s documented interface.
Metadata only
Requests never pass through ARC1. The usage reporting contract excludes prompts, responses, source code and local paths.
Separate proposal and approval
An administrator proposes a policy and a second person approves it. A different person with finance authority closes the month. The deployment signs the receipt, preserving who acted.
Signed receipts
Every proposal, approval and policy change is kept as an Ed25519-signed receipt, chained to the one before it and verifiable offline.
In your environment
One deployment for one organization, in your environment, signed in through your identity provider.
One record
Each decision retains its compared options, separate approvals, configuration observations and available follow-up. Download its decision packet; financial review keeps its own source and period, and missing evidence links remain explicit.
Planned
Pricing the vendor’s default as its own option, and recording outcome counts with the decision.

The next forced decision

Selected Microsoft Foundry models retire on 19 November.

For the listed base model versions, Microsoft Foundry moves o1, o3 and o3-pro deployments to gpt-5.6-sol, and o3-mini and o4-mini to gpt-5.6-terra, by default, on Standard, Global Standard and Data Zone Standard deployments. Provisioned deployments are not upgraded: unless they are migrated, they stop answering when the model retires. The gpt-5, gpt-5-mini and gpt-5-nano (2025-08-07) versions follow on 9 February 2027, with no replacement named yet.

A retirement review prices the default on your highest-volume workflow’s token mix against two alternatives, registers quality and service limits before anyone sees results, and leaves the decision on the record for your controller and auditor.

Plan a retirement reviewMicrosoft’s schedule
Retirement dates in Microsoft Foundry, selected base model versions
ModelRetiresDefault replacement
o1, o3, o3-pro19 Nov 2026gpt-5.6-sol
o3-mini, o4-mini19 Nov 2026gpt-5.6-terra
gpt-4o (2024-05-13)9 Dec 2026gpt-5.6-sol
gpt-5, gpt-5-mini, gpt-5-nano9 Feb 2027None named yet

Listed base model versions: o1 (2024-12-17), o3 (2025-04-16), o3-pro (2025-06-10), o3-mini (2025-01-31), o4-mini (2025-04-16), gpt-4o (2024-05-13), and gpt-5, gpt-5-mini and gpt-5-nano (all 2025-08-07).

Source: Microsoft Foundry model retirement schedule and lifecycle policy (schedule dated 21 September 2026, read 6 October 2026). Automatic upgrades roll out by region on Standard, Global Standard and Data Zone Standard deployments unless automatic upgrades are disabled for that deployment; provisioned deployments are migrated by hand.

A wider horizon.

See the record on your next model change.

A 30-minute walkthrough on our hosted reference deployment, with synthetic data. If a retirement or another model change is coming, we use it as the example; a design partnership then runs it with agreed inputs and milestones. Partners and investors use the same form.

Request a walkthrough

Product screens: the ARC1 console with a fictional health plan’s synthetic data (demonstration), every one captured 8 October 2026 in the dark appearance from a local build of the same release; the small screens above are regions of those same captures. The Results and Evidence screens are cropped to the trace and the evidence map; the decision evaluation shows three retained synthetic comparisons, and the administrator Flow view is a schematic with its reported-usage strip cropped out. Each full screen is a press away. The interactive workspace, the connected views and the worked decision are illustrations on synthetic fixtures; nothing on this page reads a live environment.

Full screen

Synthetic health plan · synthetic data