Prompting as a specification: a framework for more controlled AI workflows

Requests to artificial intelligence should be treated as specifications: with context, a measurable objective, constraints and a defined output format. That approach is set out in a paper on instruction architecture for large language models, published in Acta Innovations on October 30. For businesses, the practical challenge is not finding one successful phrase, but producing work that can be checked and reused.

The paper brings together techniques for prompt design, multi-stage workflows and response evaluation. Its proposed structure centers on CORE: Context, Objective, Restrictions and Expected Output. These are four components of a task specification, not a special command that automatically makes every model more accurate.

The approach's practical value depends on whether it can reduce errors, review time and the cost of completing a task. Its effectiveness must be assessed in specific workflows: a convincing answer in a single conversation is not evidence of a reliable system.

From a short request to a task specification

A command such as “prepare a market analysis” leaves too many decisions to the model: which market, which period, which evidence and which audience. The resulting text may sound convincing while failing to meet the commissioning team's needs. If quality criteria are only established after the response arrives, consistent assessment becomes difficult.

The authors suggest defining the structure in advance: role, task, context, constraints, output format and evaluation criteria. A role sets a professional perspective and style; context establishes the starting conditions; constraints define the permitted boundaries. Evaluation criteria distinguish a correctly completed assignment from a merely well-written answer.

This distinction matters in recurring processes, including document handling, reporting, software development and newsroom work. Instead of composing a new request from scratch, an organization can maintain a template whose inputs change while its acceptance requirements remain consistent.

CORE: four components of a controlled assignment

The paper presents CORE as a minimum checklist. Its value lies in making the working conditions explicit. Asking a model to “be accurate” is not enough: the instruction should identify which evidence it may use and what to do when information is missing.

Applying this approach does not necessarily require switching models. It does require describing the underlying workflow. If a team has no agreed rules for calculations, source verification or acceptance, a prompt cannot replace those rules.

A practical example: reporting a statistical release

Consider a hypothetical newsroom assignment. This is FinFly's illustration, not an experiment or a measured result from the paper. A short request might say: “Write a news story about wage growth.” It specifies neither the source nor the period nor the basis for comparison.

A more useful instruction could read as follows:

Prepare a business news report using the attached official release and a table for a comparable earlier period. The audience is entrepreneurs and employees in Azerbaijan. First, extract the confirmed values, reporting periods and units. Compare indicators only where their definitions and coverage match. Do not confuse the average monthly wage over January-August with the wage for August alone. Separate nominal change from changes in purchasing power. If a suitable price index or previous value is unavailable, state explicitly that the corresponding conclusion cannot be drawn. Return a headline, an opening paragraph, a fact table and a short explanation identifying the limitations. Give the location of every figure in the attached document.

The difference is not simply a longer request. The instruction establishes testable conditions: comparable periods, traceable figures and a procedure for missing information. The editor receives a basis for verification rather than only a finished-looking narrative.

Even then, the answer remains a draft. Document references, arithmetic and interpretation must be checked against the original. Requiring a source does not guarantee that the model has identified it correctly.

Break complex work into stages that can be checked

Another theme of the paper is decomposition: replacing one large assignment with a sequence of connected operations. In an editorial workflow, these might be fact extraction, comparability checks, drafting and final verification. Each stage produces an artifact that can be inspected before work continues.

This is useful where an early error can propagate into the final conclusion. If a model misreads the units, improving the prose later will not repair the calculation. An intermediate fact table makes it possible to identify the problem before a complete article is produced.

Verifiable intermediate outputs should not be confused with access to a model's entire internal reasoning. Quality control requires input values, formulas, assumptions and evidence supporting a conclusion. A detailed explanation is not, by itself, proof that an answer is correct.

Roles and examples guide the response, not professional competence

The paper discusses role-based instructions and few-shot prompting, which includes a small set of example responses in the request. The former establishes a professional perspective; the latter demonstrates formatting and detail. But telling a system “you are a financial analyst” does not give it professional qualifications, access to current filings or authority to make decisions.

Examples have a similar limitation. If a sample contains faulty reasoning, unsupported conclusions or a weak structure, the model may reproduce those features. A production template needs verified, sufficiently varied examples, not simply the most impressive response from a previous conversation.

Official model-developer guidance likewise emphasizes clear instructions, quality examples and evaluation. Google's documentation specifically warns that too many examples can encourage overfitting to them. Anthropic's evaluation guidance starts with defining success criteria and how to measure them. These documents provide additional practical context; they are not independent validation of CORE itself.

Measuring business value without exaggerated promises

For a business, prompt length is less important than the effect on quality and process costs. We suggest testing a revised template on real assignments while keeping the inputs, model version and available tools consistent. Repeating some tasks helps expose variation rather than allowing a single successful response to determine the verdict.

• Factual accuracy: how many claims and figures are supported by the input materials.
• Task compliance: whether the output follows the required format, mandatory fields and restrictions.
• Handling missing information: whether the system flags gaps instead of inventing values.
• Human review effort: the time a specialist or editor spends checking and correcting the result.
• Cost and speed: the number of requests and total cost of completing the assignment.

The last measure is particularly important for multi-stage workflows. Extra checks may improve control, but they also add model calls, latency and expense. A longer process should not automatically be regarded as a more efficient one.

Working instructions should be stored with a version number, purpose, test cases and known limitations. Tests should be repeated after changing the model, data sources or task requirements. A template that performed well yesterday is not automatically suitable for a new assignment.

What the paper establishes and what still needs testing

The article is a methodological review and a synthesis of techniques. It does not describe a single controlled comparative trial of CORE that would justify promising a specific reduction in errors or costs for every organization. Its recommendations are a starting point for workflow design and local testing, not a universally validated standard.

A prompt also cannot replace current evidence, calculation tools, confidentiality safeguards or access controls. If an AI system can send emails, publish articles or modify records, operational restrictions must be enforced in software. A written instruction against an unwanted action is not a sufficient control on its own.

The practical starting point for a company is to define the task, permitted evidence and acceptance criteria. CORE helps collect those requirements in one place. Deployment decisions should then depend on tests of the actual workflow, including its errors, costs and need for human involvement.

Original authors and sources

Authors of the original paper: Kirill Patyrykin and Aleksey Dudkin. Instruction Architecture in Generative AI: A Framework for Prompt Engineering and Reasoning Control in Large Language Models. Acta Innovations, Vol. 64, No. 1s, pp. 1324-1335. Published October 30, 2026. Journal publication, DOI: 10.62441/actainnovations.vi.2839, full-text PDF.

Kirill Patyrykin's blog post introducing the paper. The original paper is published under Creative Commons Attribution 4.0. This article is an independently written English-language summary and adaptation by FinFly, with additional explanation; it is not a verbatim reproduction. The practical newsroom example and editorial verification recommendations were prepared by FinFly.

Additional primary sources: Google AI: Prompt design strategies; Anthropic: Define success criteria and build evaluations. Cover: a thematic AI-generated illustration from FinFly's collection.