Defining AI-Native Systems: Autonomy as Revision Authority
The paper defines AI-native systems by revision authority: autonomous implementation rewriting with escalation, verification, and fallback; no empirical metrics are reported.
Key Findings
Methodology
The paper models a system as decision points d=(X,I,J), where X is the option space, I available information, and J an evaluation criterion. Decisions are stratified by binding time into L0 purpose, L1 design, L2 implementation, L3 policy, and L4 runtime. The central distinction is occupancy—who executes a decision—versus revision authority—who can change it. Allocation α and verification ρ are added as orthogonal axes.
Key Results
- The proposed ladder has three grades: S3 Self-Tuning modifies θ∈Θp; S2 Self-Rewriting generates p′∈PD behind fixed interfaces; S1 Self-Architecting changes the design. The paper reports no datasets, percentages, baselines, or ablations because it is a conceptual definition rather than an empirical evaluation.
- Classical ML4Sys generally reaches at most S3. Learned indexes, caches, allocators, and schedulers may occupy runtime decisions but cannot revise their own implementations. The paper identifies nanosecond-scale overhead, distribution shift, p99 tail risk, maintenance burden, and scarce cross-domain expertise as the main barriers.
- An AI-native system requires an escalation detector ε, verification procedure ρ, verified non-AI fallback, and authority over decider allocation α. Purpose and correctness remain human-owned. No deployment success rate, safety score, or workload benchmark is provided for these mechanisms.
Significance
The paper turns “AI-native” from a marketing label into a system property. The decisive question is not how capable the underlying model is, but how much authority the system delegates to AI to revise its own decisions. This clarifies why a neural model on a hot path is not automatically autonomous and connects AI, operating-systems, and database research. For industry, it reframes continuous code generation as a governance problem requiring auditability, verification, rollback, and explicit human responsibility.
Technical Contribution
The main contribution is a decision hierarchy plus two orthogonal axes. L1 produces an implementation space PD; L2 selects p and exposes a policy family Θp; L3 selects θ and defines πθ:S×I→A; L4 executes an action. This yields an autonomy ceiling and the S3/S2/S1 ladder. The α allocation axis specifies who controls deciders, while ρ separates producing a candidate from admitting it into deployment.
Novelty
The novelty is definitional rather than algorithmic: no new generator or optimizer is introduced. Unlike work that grades intelligence requirements or model capability, this framework grades an AI’s authority over the system’s own decision structure. It sharply separates runtime occupancy from revision authority and makes self-tuning, self-rewriting, and self-architecting auditable system grades rather than promotional descriptions.
Limitations
- The paper contains no experiments, datasets, numerical baselines, or real deployment case studies, so the effectiveness of ε, ρ, and fallback mechanisms remains untested under complex workloads.
- The L2/L3 boundary depends on representation convention R: the same threshold can be configuration data or compiled code, making classification partly design-dependent.
- S1 Self-Architecting is only sketched conceptually; interface compatibility, formal verification, fault attribution, and long-term drift control remain open.
Future Work
Future work should develop auditable certificates, formal conditions for escalation and verification, and evaluations on real databases, schedulers, and operating systems. Important directions include tail-latency and invariant checking, adversarial testing, automatic rollback, workload-drift detection, and methods for safely approaching S1 without transferring purpose or correctness ownership away from humans.
AI Executive Summary
AI can now generate, test, and deploy systems code, yet “AI-native” is used inconsistently across databases, clouds, and developer tools. Prior ML4Sys successes include learned indexes, cache eviction, memory allocation, and NUMA placement. But resident models incur inference and feature-collection overhead, suffer under distribution shift, provide weak tail guarantees, and demand costly maintenance. The paper therefore asks not merely where AI makes decisions, but what it is authorized to change.
Tan proposes revision authority as the defining axis. A system contains L0 purpose, L1 design, L2 implementation, L3 policy, and L4 runtime decisions. L1 creates PD, L2 exposes Θp, and L3 defines πθ. S3 Self-Tuning changes policy parameters; S2 Self-Rewriting changes implementations behind fixed interfaces; S1 Self-Architecting changes the architecture. Occupancy is not authority: a neural model may execute a runtime decision while humans retain all revision rights.
A genuine AI-native system must include escalation detector ε, verification axis ρ, a verified non-AI fallback, and control over decider allocation α, while humans retain purpose and correctness. The paper offers no dataset, benchmark, or performance improvement; its contribution is a precise conceptual framework and research agenda. The next challenge is demonstrating that these safeguards can support continuous code revision without sacrificing reliability.
Deep Analysis
Background
ML4Sys has reached production through learned indexes, learning-based memory allocation, flash-cache admission, CDN eviction, VM NUMA placement, and lifetime-prediction scheduling. Yet these remain hand-built point solutions. Models on the hot path face nanosecond budgets, nonstationary workloads, tail-latency risk, maintenance overhead, and a shortage of combined ML and systems expertise. Coding agents change the mode of use: they operate in a slow control plane, generate code, and leave compiled artifacts to a fast data plane.
Core Problem
- ��AI-native” lacks a testable definition. Does AI merely execute runtime decisions, or can it modify the code that generates them? Parameter tuning cannot recover when the workload leaves policy family Θp. Conversely, unrestricted rewriting may violate interfaces, invariants, SLAs, or safety constraints. The problem therefore combines adaptation level, decider allocation, verification, rollback, and the boundary of human responsibility.
Innovation
- �� Formalize a decision point as d=(X,I,J), separating executor from reviser.
- �� Define L0–L4: purpose, design, implementation, policy, runtime.
- �� Introduce S3 Self-Tuning, S2 Self-Rewriting, and S1 Self-Architecting.
- �� Add allocation axis α and verification axis ρ, separating candidate generation from deployment admission.
- �� Use escalation detector ε to recognize policy-family saturation and trigger implementation regeneration.
Methodology
- �� Input: workload space W and decision points d=(X,I,J), where J can measure throughput, latency, or tail constraints.
- �� Stratification: L1 selects design D and produces PD; L2 selects program p and exposes Θp; L3 selects θ and defines πθ:S×I→A; L4 executes one action.
- �� Adaptation: replace xk with x′k while holding all higher levels fixed; tuning is L3, code rewriting is L2, and architectural change is L1.
- �� Autonomy: identify the highest level at which an AI process can adapt autonomously; this is the autonomy ceiling.
- �� AI-native status: at least S2, with ε, ρ, fallback, and α control, while humans retain L0 purpose and correctness.
Experiments
No experiments are conducted. The paper cites learned indexes, production memory allocation, datacenter flash-cache admission, CDN learned eviction, VM NUMA placement, and lifetime-prediction scheduling as contextual examples rather than evaluated systems. It provides no dataset names, hardware configuration, hyperparameters, metrics, numerical baselines, or ablation studies.
Results
The principal result is structural: revision authority is cumulatively downward. Authority at L2 entails handling the L3 choices below it, while an L4 decision is consumed at execution and cannot itself adapt. Runtime ML is model-resident: it may occupy L4 without revision authority and generally reaches no higher than S3. No performance gain, statistical significance, or cross-workload advantage is claimed.
Applications
Databases could let agents rewrite eviction, indexing, or scheduling implementations from query traces; schedulers could generate new policies behind fixed APIs; clouds could detect policy saturation, verify candidates, and retain prior versions. Deployment requires explicit interfaces, SLAs, invariants, trace replay, tail-latency tests, staged rollout, and reliable rollback.
Limitations & Outlook
The framework depends on representation convention R, so the parameter/code boundary is not intrinsic. It does not specify thresholds for ε, coverage guarantees for ρ over open-ended code, proofs of p99 compliance, or quantitative rollback risk. S1 is especially difficult because architectural changes redefine interfaces and verification targets. Future work needs formal certificates, real benchmarks, drift detection, adversarial testing, and long-horizon deployments.
Plain Language Accessible to non-experts
Imagine a restaurant. Traditional machine learning is like hiring a very fast chef at the serving counter: the chef can decide which dish to prepare next, but must react instantly, which may slow service. The owner still chooses the menu, kitchen layout, and hygiene rules. Self-tuning means adjusting the seasoning or cooking time. Self-rewriting means discovering that the recipe is inadequate and writing a new one, while keeping the kitchen’s interfaces and safety rules. Self-architecting means redesigning the kitchen itself.
The paper says an AI-native restaurant is not simply one with a clever chef. The AI must be allowed to change recipes or procedures inside boundaries set by the owner. It must first detect that the old recipe no longer works, have an inspector test the new one, and keep a checked old recipe as an emergency fallback. The owner still decides what the restaurant is for and what “correct” means. The key question is not who serves the dish, but who can change the method of making it.
ELI14 Explained like you're 14
Imagine running a game server. A normal AI is like a fast non-player character: it can decide where to put a monster next, but it cannot rewrite the game rules. A slightly stronger system can change the difficulty, such as raising monster health from 100 to 120. That is self-tuning.
The paper’s “self-rewriting” idea is more powerful: the AI notices that the spawning program is clumsy and writes a new one so the server can handle more players. But it cannot instantly publish the code. The new version must pass tests, avoid breaking the game, and keep the previous version as an undo button.
Above that is “self-architecting,” where the AI redesigns how server modules connect. That is risky, so humans must still decide the game’s purpose, fairness rules, and definition of success. The AI gets a fenced playground, not unlimited control.
Here is the surprising part: an AI working inside the system does not automatically own the rules. Real autonomy means having permission to change the program behind the button, not merely pressing the button very quickly. The paper gives us a ladder and safety checklist, not a benchmark score.
Glossary
Revision authority
The permission to change a system’s decisions, code, or architecture. The paper treats this authority—not model capability—as the core of autonomy.
It distinguishes changing the mechanism from merely executing a runtime decision.
Occupancy
Who or what actually executes a decision, such as compiled code, a lookup table, or a neural forward pass. Occupancy alone does not imply permission to revise.
It prevents runtime ML from being mislabeled autonomous by default.
Self-Tuning, S3
AI changes θ within a fixed implementation and policy family. It cannot change the family Θp itself.
This represents conventional automated tuning and runtime ML.
Self-Rewriting, S2
AI generates a new implementation p′∈PD while preserving the design and interfaces. The grade requires escalation detection, verification, and fallback.
The paper treats this as the central threshold for AI-nativeness.
Escalation detector ε
A procedure that detects when L3 adaptation is no longer adequate and triggers L2 regeneration. It evaluates whether a decision mechanism can still express the workload.
It turns failed tuning into an explicit code-revision signal.
Verification axis ρ
The cross-version mechanism that decides whether a candidate is valid, deployable, and rollback-safe. It is separate from generating the candidate implementation.
Examples include tests, invariant checks, trace replay, and adversarial probes.
Open Questions Unanswered questions from this research
- 1 How can ρ verify open-ended generated code strongly enough to guarantee p99 latency, invariants, and safety? Existing tests cover finite traces and cannot exhaust the workload space.
- 2 How should ε distinguish temporary workload anomalies from genuine policy-family saturation? False escalation wastes resources, while missed escalation permits prolonged degradation.
- 3 How can S2 or S1 be deployed in real operating systems and databases with reproducible evidence of long-term benefit, rollback safety, and preserved human responsibility?
Applications
Immediate Applications
Self-adapting database implementations
Database teams could let coding agents propose new index, eviction, or scheduling implementations from query traces. Candidates would remain behind fixed APIs and be tested through replay, invariants, and tail-latency checks before staged deployment with the previous version retained.
Cloud scheduling regeneration
Cloud platforms could monitor whether scheduling policies saturate during spikes, tenant churn, or new workloads. ε would trigger generation; ρ would run benchmarks, constraint checks, and adversarial tests before replacing the active scheduler.
Long-term Vision
Auditable self-evolving infrastructure
The long-term vision is infrastructure that continuously improves its implementations while humans fix purpose, correctness, and safety boundaries. Major obstacles include formal verification, interpretable architectural change, drift monitoring, and accountable change records.
Abstract
AI has begun to write systems code: agents now synthesize, verify, and deploy system components. Despite this shift, "AI-native" remains a marketing term with no precise technical definition. This paper gives it one. We define AI-nativeness along a single axis---authority over the system's own decisions rather than by the capability of the underlying AI models. Building on a decision-level model of a system, we distinguish occupancy (who executes a decision) from revision authority (who may change it), organize revision authority into a ladder---self-tuning, self-rewriting, self-architecting and define a system as AI-native when an AI autonomously rewrites the system's own implementations. The definition further requires an escalation detector, a verification procedure, and a verified fallback, while leaving purpose and correctness human-owned.