Run your next model change through ARC1.

Start with a specific change

Choose a workflow where you are considering a different model or configuration, or where a vendor is retiring the model it runs on. We begin with a synthetic walkthrough, then scope the cost, quality and service evidence your team needs to decide. Your configured gateways or native clients continue running requests.

Who participates

Platform lead

Names the relevant sources, access and change process, and owns the configuration and deployment handoff.

Workflow owner

Defines what an acceptable result means, names the quality-label owner and agrees the service limits.

Security reviewer

Reviews the selected data flows, identity and role assignments before access is granted.

Finance approver

Joins when the scope includes a monetary benefit claim, to agree its baseline, period, population and ledger evidence.

Inputs agreed before work starts

One workflow

The proposed change, its owner, current model or configuration, and the outcome or task being evaluated.

Source evidence

The supported usage and cost sources you select, their reporting periods and coverage, and security-approved read access. Gaps and different cost bases stay visible.

Comparison basis

A versioned cohort, acceptance rubric and baseline/candidate configurations; paired metadata with quality labels, cost, errors and latency. Formats and collection responsibilities are agreed in scope.

Acceptance limits

The required paired sample count and limits for quality drop, errors, latency and cost per accepted result, chosen before collection.

Environment and access

The selected deployment environment, identity provider and role assignments, with the install and removal path recorded. Security and Trust describe the data boundary.

Financial scope

If a monetary claim is included, a finance-approved baseline and the corresponding ledger records. A finance close is scoped only when its accounting period and evidence are ready.

Milestones and deliverables

1. Fix the decision and its basis

   A scoped question, named owners and a source coverage statement. Record the reviewed period, baseline, candidate and rate basis, with missing inputs identified.

2. Register the comparison

   The cohort, rubric, configuration fingerprints, observation window and acceptance limits are registered before collection. Your authorized collector supplies the paired metadata after the window closes.

3. Review the result and change evidence

   Evaluate the supplied evidence as within limits, outside limits or incomplete. Keep model eligibility approval, observed target configuration and any follow-up comparison separate. Applying a route follows your own change process.

4. Hand over the review record

   Export the exact registered comparison and its retained evidence. Review the keep/change/collect-more-evidence decision with the owners, record outstanding work and agree who takes the next action.

Return when your team proposes another model or configuration, or when a separately registered follow-up is ready. Review the new evidence against its agreed basis while retaining the earlier decision.

Exit conditions agreed in scope

• The platform lead and workflow owner can explain the proposed change, its source and cost basis, and the quality and service limits.
• The comparison result is inspectable against the agreed limits. A cheaper option that misses a limit is recorded as such; missing observations lead to an evidence collection decision.
• Approval, configuration and follow-up records are either identified exactly or recorded as outstanding, with a named owner. A model permission does not establish that a route changed.
• The team receives a reusable comparison export and agrees the next action: retain the baseline, pursue a separately approved change, or collect more evidence.

The evidence we start from

The hosted reference deployment supports the walkthrough with synthetic product records. The preview at the top of this page uses invented paired observations for one coding task, evaluated by ARC1’s comparison engine.

Kong OSS 3.9.3 has been exercised in a local lab for policy apply, readback and drift recovery. That run did not establish successful model inference. Azure API Management and coding-agent hooks are tested against vendor interfaces; acceptance on your selected environment and workflow is an agreed partnership milestone.

Trust and data boundary and the roadmap describe the implementation and proof scope.

Commercial scope

A fixed fee is quoted once scope is agreed. We record the selected workflow, access, responsibilities, milestones and exit conditions in the proposal. Platform pricing is described on the Pricing page.