Specification Engineering: Transforming Intent

• Specification Engineering is a meta-level discipline that transforms ambiguous design intent into complete, unambiguous, and verifiable artifacts.
• It leverages diverse formalisms—such as SEMAT Essence, Seamless Requirements, and ontologies—to ensure traceability, consistency, and validation from concept to execution.
• Recent advances integrate SE with AI-native workflows, emphasizing agent coordination, iterative refinement, and the bridging of formal verification with human oversight.

Specification Engineering is the disciplined activity of creating, refining, representing, and validating specifications so that design intent becomes explicit, structured, traceable, and reviewable before or alongside implementation. Taken together, the literature treats the object of specification as more than a requirements document: it may be a method description, a contract-annotated routine, a process rule, a sociotechnical protocol, a safety requirement model, an ontology-derived standard, or an agent-facing mission brief. This suggests that Specification Engineering is best understood as a meta-level discipline concerned with transforming implicit intent into artifacts that are complete, unambiguous, consistent, and correct, and with preserving that intent across review, implementation, and verification (Hamblin et al., 28 May 2026, Meyer, 24 Feb 2025, Bank et al., 20 Mar 2026, Gjerver et al., 2 Oct 2025).

1. Specification as an engineering object

A central distinction in recent work is between implementation-level reasoning and specification-level reasoning. Implementation-level reasoning assumes that a precise specification already exists and asks whether code can be generated correctly from it. Specification-level reasoning instead asks whether the specification itself is deficient and whether it can be improved before code exists. SpecBench defines this capability as producing specifications that are complete, unambiguous, consistent, and correct, and operationalizes deficiencies as omissions, ambiguities, inconsistencies, and incorrect assumptions extracted from historical RFC reviews in Kubernetes, React, Rust, TVM, and vLLM (Hamblin et al., 28 May 2026).

This reframing is echoed in work on AI-native software engineering, which states that the engineer’s primary act becomes expressing what is wanted precisely enough that a stochastic system can act on it, and that the central challenge is the translation, refinement, and verification of intent. The same work explicitly organizes AI-native software engineering around intent, collaboration, and verification, and states that the locus of difficulty moves from syntax to specification and judgment (Alenezi, 11 Jun 2026). A related agentic perspective distinguishes SE for Humans and SE for Agents, arguing that specifications must now be machine-readable enough for agents to execute, human-auditable enough for review, and durable enough to support callbacks, evidence, and handoffs (Hassan et al., 7 Sep 2025).

An important implication is that a specification is no longer only an upstream artifact. In the cited literature it is also a runtime contract, a coordination mechanism, and a verification target. This suggests that Specification Engineering increasingly spans problem framing, requirement refinement, process definition, and acceptance evidence rather than only static requirement capture.

2. Formalisms and representational styles

One influential representation is the SEMAT Essence specification. Essence is described as a language for modeling software engineering practices and methods together with a kernel containing elements said to be present in every software development project. Its kernel is organized into the areas of concern Customer, Solution, and Endeavor, and contains seven alphas: Opportunity, Stakeholders, Requirements, Software System, Work, Team, and Way of Working. These alphas are trackable entities with states and state checklists; the paper illustrates this with the state “Ready: the system (as a whole) has been accepted for deployment in a live environment.” Essence is explicitly not a one-size-fits-all method but a modular framework, and its language combines natural and formal language “akin to e.g. XML,” with “three levels of conformance,” where level 3 descriptions are automatically trackable and actionable (Kemell et al., 2018).

A different representational strategy appears in Seamless Requirements. Here, each functional requirement is expressed as a small routine in the programming language itself, equipped with a contract and preceded by a natural-language comment. The paper calls the formal layer a specification driver: a non-operational routine written only in terms of its formal arguments and intended as a proof obligation for a verifier such as AutoProof. In this style, requirements are kept in the codebase, remain readable to developers and customers, and can be verified against contracts without translation into tests when formal verification is available (Naumchev et al., 2017).

Formalization can also target software engineering itself. “Software Engineering as a Domain to Formalize” proposes an object-oriented ontology in Eiffel and BON around classes such as PROJECT, MILESTONE, PRODUCT, PRODUCT_INCREMENT, CODE_MODULE, ISSUE, TEAM, and MEMBER, with properties expressed through types, inheritance, invariants, preconditions, and postconditions. The paper distinguishes axioms of the theory from process rules and gives a waterfall-style example, design_phase.start_time ≥ requirements_phase.end_time, as a rule to be checked against project data rather than a universal invariant (Meyer, 24 Feb 2025).

In open sociotechnical systems, Interaction-Oriented Software Engineering replaces the machine-centered specification with a protocol-centered one. Its core formalism is the commitment notation $C(x,y,r,u)$, where debtor $x$ commits to creditor $y$ that if antecedent $r$ holds then $x$ will bring about consequent $u$. Here specification means assigning explicit social meaning to interactions among autonomous principals, not defining the internals of a central machine (Chopra et al., 2012).

3. Traceability, conformance, and verification

Traceability is a recurring structural requirement. In model-driven safety requirements management for complex systems, the process backbone is EIA-632, and the information model is built in SysML with stereotypes such as <<acquirerReqt>>, <<otherStakeholderReqt>>, <<systemTechnicalReqt>>, <<specifiedReqt>>, <<testCase>>, and <<risk>>. Requirements trace to solution representations; solution elements satisfy requirements; requirements are verified by test cases; and a <<treat>> relation links risk to safety requirements. The paper’s core chain is effectively Risk → Safety requirement → Design solution → Test case, with logical and physical solution representations kept distinct to support impact analysis and verification planning (Guillerm et al., 2012).

Design-OS generalizes this concern to engineering system design through a five-stage workflow: concept definition, literature survey, conceptual design, requirements definition, and design definition. Specifications are treated as the shared contract between human designers and AI agents, and the workflow is explicitly designed to preserve traceability from mission to requirements to parameters to code or simulation to verification. The paper makes this concrete with links such as REQ-001 ↔ settling time ≤ 1.0 s ↔ state-feedback gain K ↔ simulation step response, and with cross-domain chains connecting software, electrical, and mechanical design choices (Bank et al., 20 Mar 2026).

Formal refinement from architecture to implementation is another traceability mechanism. In PSF-based software re-engineering, an abstract architecture is specified in process algebra and transformed toward a ToolBus-based implementation by vertical implementation/refinement and horizontal implementation/constraining. Vertical refinement maps abstract actions to concrete action sequences and is justified through rooted weak bisimulation; horizontal constraining limits a process by composing it with another process and encapsulating their communication. The result is an explicit path from architecture action to ToolBus action to adapter and tool behavior (0712.3115).

A further verification pattern appears in work that maps control-theoretic guarantees to software-engineering properties. Stability for adaptive cruise control is expressed as an LTL-style property, $Stability \equiv \Diamond(\square SS)$, and then checked against generated and optimized code using DIVINE 4. Specification patterns serve as the common language between control theory and software engineering, making preservation of semantics across model, code, and verification artifact itself a specification-engineering problem (Caldas et al., 2021).

4. Method engineering, standards, and domain pluralism

Specification Engineering also appears as method engineering. Essence is explicitly method-agnostic and is presented as an escape from “method prisons”: organizations should not be locked into one monolithic method, but should be able to mix, modify, tailor, and combine practices across contexts. In this view, the kernel provides a common vocabulary for modeling Scrum, Waterfall, Lean, or hybrid approaches without replacing them with a universal process (Kemell et al., 2018).

The problem of relating concrete practices to a common specification vocabulary is addressed formally in the Concept Algebra approach to mapping software engineering practices to Essence. The paper models both Essence concepts and practice concepts as structured concepts with objects, attributes, and relations, compares them through shared attributes and similarity measures, and supplements this with Linguistic Typological Analysis. Its case study on Scrum’s Product Backlog and Essence’s Requirements concludes that the concepts are related but not equal, reporting 33.3% similarity rather than equivalence. This is significant because it shows that apparent terminological correspondence may conceal nontrivial semantic mismatch (Uysal, 2018).

A different kind of domain extension appears in industrial standards digitization. “Machine-interpretable Engineering Design Standards for Valve Specification” transforms document-centric standards into modular, reusable ontologies in OWL 2 and RDF, aligned with ISO DIS 23726-3 Industrial Data Ontology (IDO). IDO is described as having 49 classes, 92 object properties, and 2 data properties; the reusable valve-core ontology contains 197 classes, 30 object properties, and 17 individuals. Functional location tags, Valve Data Sheets, and manufacturer product types are instantiated as semantic entities, and automated reasoning is then used to determine whether a specific VDS complies with relevant standards and whether a candidate product satisfies the VDS (Gjerver et al., 2 Oct 2025).

Taken together, these works suggest that Specification Engineering is not tied to one notation or one engineering domain. It can be object-oriented, contract-based, protocol-based, process-algebraic, SysML-based, ontology-based, or hybrid. What remains stable is the effort to encode semantics precisely enough that conformance, comparison, and change impact become technically manageable.

5. AI-native and agentic reformulations

Recent work explicitly elevates specifications to the primary interface between humans and automated agents. SpecBench is the clearest benchmark formulation of this shift. For each task, an agent receives the initial RFC proposal, the project codebase, and all prior RFC discussions available up to the proposal date, and must identify deficiencies later raised by expert maintainers. Because the evaluation is open-world, unmatched predictions are treated as unjudged rather than automatically false, and output is bounded by the prediction budget

$N = \lceil 1.25 \times |G| \rceil .$

Core deficiencies are weighted more heavily than extended ones, and the best-performing evaluated agent reaches 44.4% accuracy, which the paper presents as evidence that specification-level reasoning remains substantially unsolved (Hamblin et al., 28 May 2026).

SE Arena addresses a different problem: how to evaluate foundation models in iterative, context-rich software-engineering workflows, including requirement refinement. The platform uses pairwise human preference comparison, supports multi-round conversation, and injects repository context through RepoChat, which can incorporate repository descriptions, issues, commits, pull requests, and related artifacts. Its leaderboard aggregates measures such as Elo score, average win rate, Bradley-Terry coefficients, eigenvector centrality, PageRank, and Newman modularity, reflecting the claim that a single score is insufficient for context-rich specification and design tasks (Zhao, 3 Feb 2025).

Protocol-driven agent coordination makes the specification role still more explicit. SEMAP models each agent with a behavioral contract

$C = (name,\ \mathcal{I}_C,\ \mathcal{O}_C),$

models messages as

$M = (sender,\ receiver,\ \mathcal{C}_M),$

and governs execution through a finite-state lifecycle

$x$0

The paper treats under-specification, coordination misalignment, and inappropriate verification as specification failures and reports substantial failure reductions under this protocol discipline, including up to 69.6% total failure reduction for function-level development, 56.7% for deployment-level development, and 47.4% on Python vulnerability-detection tasks (Mao et al., 14 Oct 2025).

Agentic Software Engineering generalizes this into a durable artifact ecosystem. Its Structured Agentic Software Engineering vision introduces BriefingScript, LoopScript, MentorScript, Consultation Request Pack (CRP), Merge-Readiness Pack (MRP), and Version Controlled Resolution (VCR), distributed across the Agent Command Environment (ACE) for humans and the Agent Execution Environment (AEE) for agents. In this model, specifications are no longer transient prompts; they are version-controlled, testable, auditable artifacts that govern action, escalation, and merge readiness (Hassan et al., 7 Sep 2025). This is aligned with the broader AI-native claim that specification, evaluation, orchestration, and metacognition become higher-order competencies while code production alone becomes insufficient (Alenezi, 11 Jun 2026).

6. Adoption, pedagogy, and unresolved problems

The literature is explicit that good specification formalisms do not guarantee easy adoption. In the case of Essence, the main barriers are manual modeling effort, a learning curve, the need for reflection and planning, and a lack of supporting tools and low practitioner awareness. A board game, “The Essence of Software Development – The Board Game,” was proposed as a first-touch learning device for first-year students and evaluated with 61 participants from the University of Jyväskylä over two evenings. Results were positive for user experience and teamwork, but weaker for deep educational impact: most participants could not explain Essence directly after playing, and in the multiple-choice exam 45 complete responses were analyzed, 34 of 45 would have passed with more than 50% of the maximum score, and the median score was 16 out of 29. The authors therefore characterize the game as an introductory tool rather than a full path to practical Essence competence (Kemell et al., 2018).

Educational implications are broader in the AI-native literature. The nine-dimension competency model explicitly includes C1 Specification / intent engineering, and emphasizes that this is not merely prompt writing but translating problem frames into precise specifications that constrain model behavior. The same work argues that software engineering curricula can no longer rely on code generation as the primary proxy for competence, and proposes a four-phase roadmap progressing from durable fundamentals and AI literacy to design, testing, verification, human–AI teams, agent orchestration, and finally authentic repository-scale agentic projects with public defense and process evidence (Alenezi, 11 Jun 2026).

Open issues remain at several levels. SpecBench highlights noisy human disagreement and the open-world nature of deficiency discovery; Design-OS notes overhead, the need for disciplined stage ordering, and the benchmark status of its inverted-pendulum case; ontology-based smart standards require governance, maintenance, and large-scale digitization effort; and the formal theory of software engineering remains explicitly a sketch rather than a completed theory (Hamblin et al., 28 May 2026, Bank et al., 20 Mar 2026, Gjerver et al., 2 Oct 2025, Meyer, 24 Feb 2025). This suggests that Specification Engineering is simultaneously a mature concern—because its core problems of ambiguity, traceability, and conformance are longstanding—and an unfinished one, because new domains and agentic workflows continually shift where specifications must live, how formal they must be, and who or what must be able to interpret them.