SENAR

Supervised Engineering & Normative AI Regulation

Version: 1.4 | Date: 04.09.2026 Authors: Андрей Юмашев (Andrey Yumashev), Вадим Соглаев (Vadim Soglaev) License: CC BY-SA 4.0 | Website: senar.tech

NOTE: The following summary is informative. Normative requirements are defined in Sections 4–13.

Start Here: Minimum Viable SENAR (MVS)

You are practicing SENAR when these six things are true:

1. Every AI implementation has a Task with a goal and acceptance criteria — before work begins.
2. AI output is verified by a Supervisor against acceptance criteria — never rubber-stamped.
3. Tasks cannot start without goal, acceptance criteria, and requirement link (Context Gate).
4. Tasks cannot close unless CI passes, tests pass, and types are clean (Implementation Gate).
5. Throughput and Lead Time are measured — you know how many tasks per session and how long they take.
6. Dead Ends are documented — when an approach fails, you write down why, so no one repeats it.

That’s it. Do these six things and you are practicing the core of SENAR. For a structured entry point, see SENAR Core (8 rules, 2 gates, 2 metrics). Everything else in this standard builds on this foundation.

What Is SENAR

SENAR is a methodology for software development where AI agents are the primary producers of engineering artifacts and humans serve as Supervisors — directing, verifying, and governing AI output.

SENAR addresses a fundamental shift in software engineering: when AI produces the code, the human’s value moves from production (writing code) to judgment (designing context, verifying correctness, making architectural decisions).

Existing methodologies (Scrum, SAFe, Kanban) were designed for teams of humans coordinating with each other. SENAR is designed for Supervisor+AI Pairs producing verified, traceable software.

SENAR Values

1. Context over Code — AI output quality is determined by input context quality
2. Verification over Speed — correctness is the constraint, not velocity
3. Knowledge over Experience — what is not documented does not exist for AI
4. Enforcement over Agreement — quality standards enforced through automated gates, not meetings
5. Judgment over Keystrokes — human attention on decisions and verification, not on typing

SENAR Core

SENAR Core provides 8 foundational rules for any team. This Standard extends Core with organizational processes, metrics, and governance. Teams adopting SENAR for the first time SHOULD start with SENAR Core. Teams implementing SENAR Core are not required to conform to this Standard but are encouraged to adopt Foundation configuration when ready.

Document Set

Normative Language

Per RFC 2119: SHALL = required, SHOULD = recommended, MAY = optional.

Normative requirements appear in Sections 4–13 of this Standard. Sections 1–3 are definitional. Where a definition states SHALL, it fixes how a term is to be read and does not create an obligation standing on its own; the obligation it constrains is executed in Sections 4–13, and each has a place there — Task Scope (3.5.1) among the Task’s required attributes (6.2) and the criteria of QG-0 (8.1); the extent of the term engineering artifact (3.5.2) through 8.6(a), which requires a declared effect to be testable against any proposed action; automation of gates (3.9) through 8.6(f). A conformance claim covering only Sections 1–3 is not valid (13.4), and no requirement depends on their being assessed. Section 4 is normative and definitional at once — it states responsibilities that SHALL be covered — and is counted as normative here and among the definitional sections in 13.4 for that reason. The Guide and Reference are informative.

Tooling

SENAR is tool-agnostic in choice but tool-dependent in practice. Automated quality gates, metric collection, and knowledge management require tooling support. See SENAR Reference (Tooling Requirements) for detailed capability requirements.

AI Capability Dependence

Some SENAR provisions are capability-dependent: they reference AI behavioral patterns (hallucination types, context window limits, instruction following characteristics) that change with model generations. Organizations SHOULD review capability-dependent provisions when the AI model they use changes substantially (see Section 10.13). The SENAR Guide marks such provisions explicitly.

Empirical Basis and Limitations

SENAR’s quantitative guidance (metric baselines, session duration guidelines, cost estimates) is derived from a single reference implementation: 552 tasks, $989 in AI costs, 38 sessions across 6 microservices. This constitutes a case study, not a controlled experiment. Organizations should treat these numbers as illustrative starting points, not universal targets — which is why Section 9 requires establishing your own baselines before setting targets.

Specific limitations: N=1 organization, self-reported metrics, pre/post design without control group, single AI model family. Independent replication across different organizations, domains, and AI models is needed to validate generalizability.

Coverage Limitations

The section above bounds the data behind this standard. This one bounds the survey behind its positioning. Section 1.5 states where SENAR sits relative to adjacent work; a statement of that kind is worth exactly as much as the list of what was not examined.

Examined by reading the primary source: the published normative texts of the works cited in Section 2.2 that are freely available.

Examined by structure and public analysis only: every paid publication cited in Section 2.2 — ISO 9001:2015, ISO/IEC 25010:2023, ISO/IEC 12207:2017, IEEE 29148:2018, CMMI for Development 2.0, ISO/IEC 42001:2023 and IEEE 1012-2024. Their structure, clause numbering, control titles, and public commentary were read; the text of their individual clauses was not, and this standard makes no claim about what that text says. Where this standard or its Reference names a clause of one of these works, the naming rests on published numbering and titles, which is enough to point at a clause and not enough to assert what it requires — an organization verifying conformance against any of them reads the source.

Not examined at all: ETSI, OASIS, the Trusted Computing Group, CEN-CENELEC, and the Japanese and Chinese standardization ecosystems. The survey was conducted in English against English-language sources; work published only in other languages is outside it.

The survey behind Section 1.5 was conducted on 2026-08-11 and re-checked on 2026-08-17. It establishes what was found, not what exists. A field moving at the rate this one moves invalidates such a survey quickly, and the interval between those two dates is the measure of it: six days apart, the re-check did not return the same picture as the survey. A reader who needs the positioning to hold at a later date re-runs the survey rather than relying on this one. This assessment is subject to revision, and organizations relying on the positioning in Section 1.5 should treat its date as part of the claim.

Intellectual Heritage

SENAR builds on established software engineering foundations: requirements engineering (IEEE 29148), quality cost models (Boehm, 1981), process maturity (CMMI/SEI), flow metrics (DORA, Accelerate), lean manufacturing quality practices (First Pass Yield, Right First Time), and human-AI teaming research. SENAR’s contribution is the specific application and codification of these principles for AI-native development — where AI agents are the primary code producers and human engineers serve as Supervisors. The methodology does not claim to invent quality engineering; it claims to adapt it for a production model that did not exist when prior frameworks were created.

Versioning

Changes to normative requirements in the Standard are published as numbered versions (1.0, 1.1, 2.0). Guide and Reference materials may be updated between Standard versions. The changelog is maintained at senar.tech.