ACRL. Authorization and Compute Refusal Layer.
ACRL operates at submit time.
It evaluates declared intent.
It enforces hard limits.
If conditions fail, execution does not start.
[ Declared Intent ] -> | ACRL GATE | -> [ Execution ]
|
[ Signed Refusal ]
- Synchronous.
- Fail closed.
- Pre allocation control.
- Signed refusal record.
The cost problem.
Modern compute systems allow jobs to start before cost is understood.
The bill appears after execution begins.
ACRL moves control to the last safe point.
- Bad jobs start easily.
- Oversized requests pass silently.
- Cost correction happens too late.
Integration boundary.
ACRL integrates at execution submission points.
It does not inspect runtime behavior.
It does not monitor models.
- Slurm submit hooks.
- Batch schedulers.
- Privileged service accounts.
- Any path where intent becomes spend.
Orbit protocol.
Orbit defines deterministic intent.
ACRL enforces release or refusal.
- Intent is signed.
- Rules are explicit.
- Outcomes are binary.
Production data.
The following numbers reflect submit time refusals only.
They represent upper bound prevented spend.
No extrapolation is applied.
- Two to four percent of submitted jobs refused during early deployment.
- One to two percent refusal rate after behavioral correction.
- Low six figure annual prevented spend on a single production cluster.
- Zero impact on training quality or throughput reported.
- No runtime inspection performed.
What this does not do.
- Does not monitor execution.
- Does not optimize workloads.
- Does not predict outcomes.
- Does not claim savings beyond refused jobs.
ACRL is a hard boundary.
It exists to say no before cost occurs.
It is intentionally narrow.