Recursive analysis through procedural semantic programming

Like a student rushing a single draft of a paper before it is due, generative AI models write once and neglect to check their work. By creating a system prompt to instruct the model how to write, review, and revise on its own, we can mitigate error propagation and improve the caliber of responses. In the methodology for recursive analysis though procedural semantic programming and its template, the Datum Research Analytical Process (DRAP) v1.0, we use natural language to teach models how to (figuratively) think before they speak.

EDWARD VON DER SCHMIDT

21 MAY 2026

---

Background:

Analysis involves the examination of arbitrary information with the goal of expressing pertinent or salient elements related to the subject. Analysis is shaped by context - associated information that clarifies the purpose, nature, and manner of the examination and its expression. Analysis may be motivated by an inquiry, or in the vernacular of modern artificial intelligence (AI) tools like large language models (LLMs), a prompt.

Like people, LLMs and other AI systems capable of interpreting natural language and media have demonstrated analytical capacity. In the case of transformer models, which represent language and media numerically in relation to other language and media, straightforward directives can be used to specify responses or the output returned for a given instruction or prompt. In other words, you can tell the model what to do and how to do it without traditional coding syntax or grammar.

LLMs and related architectures generate responses probabilistically by evaluating a set of inputs to determine the most likely response based on fixed weights or embeddings estimated during training that represent knowledge about concepts. During inference, an input is deconstructed and transcribed or encoded into tokens (think meaningful components of concepts). The input tokens are evaluated as a whole and passed through the fixed weighting scheme as if woven through a numerical loom.

Based on a set of tokenized inputs or context, a decoding mechanism returns a corresponding output token with the highest estimated probability of "fitting" the "expected" response. Each of these generated tokens is appended to the input context for subsequent tokens, which are generated sequentially in this manner until the response is complete. These output tokens are "locked in" once produced.

The Problem:

By default, language and other generative AI models do not check finished work before returning it as a response. Once a token has been generated, that token is committed as output and becomes an input for the generated tokens that follow. This might be fine if these models could reliably return error-free responses, but their probabilistic design implies that mistakes or sub-optimal output will almost surely occur over a sufficiently long window. The auto-regressive nature of generation, in which past output becomes an input for future output, virtually ensures that any undesirable elements propagate forward and affect the remainder of the response in some manner.

This type of cascading error is not limited to a single response. Language models and related systems use a context window to manage their operations during a given dialogue or session. Physical memory and computational constraints limit the context window to a fixed number of tokens with which to operate. This context window serves as an impermanent workspace for a particular session. Any information outside of this context window is excluded from the inference process. At the same time, any information within the context window is included, mistakes and all.

The transformer architecture that underpins mainstream language models fundamentally relies on an "attention mechanism relating different positions of a single sequence in order to compute a representation of the sequence" (Vaswani et al, "Attention Is All You Need", 2017). This attention mechanism that enables a model to interpret a prompt gives greater consideration to the most recent input but evaluates the context window as a whole. While the baseline weights or estimated probabilities representing relationships among tokens (parts of language or media) are static, the conditional probability of a given token at inference time is influenced by every token within he context window. All tokens influence the interpretation of other tokens and the selection of the next token to varying degrees.

Given that the attention mechanism evaluates tokens relative to others in context, each token can "anchor" the model's active probability space (i.e., the domain of temporarily "updated" probabilities applicable to the current session). This means that once an error is committed to the output and becomes part of the context window, that error will exert an indirect influence on not just the remainder of that response but every response that follows, even for unrelated prompts. Minor mistakes might be overlooked but others could be consequential. Since generated responses are path-dependent, meaning they are influenced by the tokens that preceded them, the only way to truly "fix" a mistake is to start over in another session.

The Solution:

Systems that incorporate language and similar AI models need a mechanism for reviewing and modifying generated output before it is committed to a response and the session context. While considerable resources have been dedicated to improving the efficacy of training and inference, the potential for semantic programming (e.g. "prompt engineering") has received less attention. Even output-oriented techniques such as chain-of-thought (which simulates pre-response reasoning to "bootstrap" output), constitutional AI (which bounds the potential output with specified "values"), and retrieval-augmented generation (which introduces externally-sourced context at inference time) do not implement a review process for generated output before it is returned.

No amount of precaution can fully mitigate errors of substance or form occurring during execution that will then carry forward uncorrected. To my knowledge, there had been no publicly disclosed mechanism for specified, automated review and modification of a language model or related AI system's output before it is returned as a direct response to a given prompt within a single turn. Multi-pass or many-shot prompting does not correct for errors already output into context or their ability to influence subsequent generated output by virtue of their presence. Such approaches also require more than one turn or prompt-response sequence.

There are practical benefits to a draft-once-and-hope-for-the-best approach as latency and computational costs are generally lower. This is a sensible configuration for large-scale deployments or those that prioritize efficiency over reliability and veracity. But what if getting it right is more important than getting it quickly?

The question becomes: how can a model check, correct, and improve its own work before responding if it has not already been designed to do so? Assuming that a language or other generative AI model is capable of interpreting and executing well-specified natural language directions and has access to some form of working memory, the answer is to tell the model how to evaluate and, if necessary, refine its own "thought".

Preparation and Guidance:

An instance of the methodology that follows was first published on the Datum Research LLC website under the name "Datum Research Analytical Process v1.0" on May 4, 2026. That program may be found here: https://www.datumresearch.com/post/datum-research-analytical-process-v1-0

Language and similar AI models allow for semantic programming, or the use of contextually-derived meaning and function to direct the system's operation. Natural language (or even arbitrary media) can establish and shape context to direct a model's generative output, which may itself direct subsequent output via the introduction of context or integration with external capabilities.

Because every word influences the inference process, each word should be chosen with intention and a purpose in mind. Extraneous "padding" weakens the signals the model needs to interpret correctly. Less is more: precision and word economy are critical as each token influences the interpretation of surrounding tokens. Imperative and direct language may be preferable to maintain the proper force and scope of instructions. On the other hand, imperatives should be used judiciously to avoid "command overflow", conflicting instructions, and devolving a cohesive framework into an onerous list of requirements. The more instructions "flow", the more likely they will be to convey their intended meaning and be executed correctly.

Since the performance of generative AI models is path-dependent during inference (i.e., when you use them), the initial prompt establishes context that shapes the entire session. When specifying a mode of operation, this "system prompt" should be complete, clear, and as direct as possible. Note that LLMs and similar models allow for ambiguity that would not be possible in traditional programming. This interpretative discretion must be managed carefully when specifying a procedure intended to be repeatable.

Organization can improve comprehension. For the system prompt, this includes clear headings, a logical progression, and well-defined modules. A model's attention mechanism will interpret the prompt in its entirety, so a well-organized structure is essential to clarify function and relationships among components. While not strictly necessary, a title header with a brief description (e.g., "The following is a portable semantic program for analysis") and a "Notice" or "Metadata" section for provenance and licensing information is recommended but should be kept brief. Even in these sections, the tone of the language used (e.e., academic, legal, informal) will influence the likelihood of generated tokens in subtle but potentially meaningful ways. A rose may not quite be a rose by another name.

Setup:

Subject to architectural, environmental, safety, and other applicable constraints, the initial or system prompt encapsulates the operating logic that will govern the model's behavior until the meaning of the instructions is degraded or lost. This can occur as the context window becomes saturated of filled to the point where the oldest tokens are discarded to make room for newly generated ones. Accordingly, the system prompt may need to be reintroduced periodically to ensure that its meaning and operational mandate are preserved.

The operating logic should first be declared or initialized to tell the model explicitly that the instructions to follow are intended to govern the system's future behavior. This statement should be unambiguous - for example, "Implement the 'Operating Logic' for future prompts in this session." An acknowledgment string for auditing and to confirm application of the operating logic is recommended; otherwise, the model may consume and generate more tokens than necessary in determining and returning its own variable acknowledgment. For clear referencing and more reliable performance, the operating logic can be structured in a recognizable format such as markdown, XML, JSON, or the like.

Language models "learn" locally, even if these fleeting impressions are limited to the active session's context window and the latter's influence on generative probability distributions at inference time. The system prompt itself can be used to demonstrate the substance or form of response expected in return, analogous to "one-shot" approaches. The need to communicate operating instructions clearly should be balanced with the intended flexibility of responses. For more creative endeavors, excess structure may be inhibitive. For an analytical protocol, free-form may not be suitable. In the case of DRAP, a self-referential opening statement is used to establish the system prompt as a representative standard and to reinforce the prompt's iterative philosophy.

Methodology:

Recursive analysis through procedural semantic programming rests primarily on three integrated pillars or layers: a normative standard (foundation), implementation criteria (focus), and an introspective process (reflection). The first pillar or foundational layer establishes purpose and impetus: what are the overarching goals of this process? The second pillar or focal layer introduces a lens: what does achieving our objectives look like in practice? The third pillar or reflective layer specifies a process for determining whether our goal criteria have been satisfied or if more work is needed. This last sub-process constitutes a loop and directs the model to evaluate and possibly refine generated output before it is returned at the model's discretion.

While each of these layers is critical in its function, their content is arbitrary. Instead of textual analysis, you may be interested in generating musical tablature or color studies instead. Anything the model is capable of encoding and decoding could do. What matters is that each layer is related in a meaningful and cohesive way. The dual-lens criteria that guide both generation and review should correspond to the standards and goals in the foundation. The review process also relies on the focal guidelines to determine when and how to keep working and when to stop. If the evaluative criteria are well-specified, this refinement should be in the service of the foundational goals and "improve" initial output before it is returned as a response.

Layer 1: Foundation (DRAP: Core Framework)

The system's purpose should be defined up front. What is the model's intended function and to what end? DRAP does this in one sentence ("This system facilitates critical exploration and generates grounded analysis.") before defining the output broadly. While many may be tempted to tell a model what or who to be, such persona-driven approaches give rise to performative anthropomorphization and attendant risks. If you prefer reliable execution of tasks to superficial role-play, tell the model what it is here to do and not who to pretend to be. Otherwise, the system's attention may favor maintaining a mask over getting things done as itself.

Beyond stating the overall purpose and intention of the system prompt, this foundational layer serves to filter or bound the generative process. By defining what to do and not do or what to be and not be, you invariably influence the potential outputs of generation. This involves a delicate balance: you need to be prescriptive enough to actually direct the model's behavior while allowing for sufficient flexibility to best suit the given context. High-level principles work well, provided that they offer useful direction and that what is mandatory versus suggested is made clear.

How you present and organize this foundation matters. These principles and higher-level instructions should be clear and easy to follow, even if they entail a lot of effort; if a person cannot readily understand them, the model may struggle to as well. A mix of imperative and declarative elements will reduce command saturation and improve the comprehensibility of and adherence to the instructions given. Brevity is also key: try not to overwhelm the model with things to do or be or it will miss much of the forest for a few of its trees.

Rather than specify an approach here that will necessarily vary with your intended use, conceptual grouping or staging can be a helpful guide. DRAP's "Core Framework" outlines four components corresponding to input ("Reading the prompt"), framing ("Establishing a basis"), development ("Verifying reliability and accuracy"), and output ("Communicating the response"). These principles are evaluated holistically but the thematic and formatting "breaks" facilitate referencing and model comprehension. While this linear template suits the procedural approach to the DRAP system prompt, other strategies might be more appropriate for your goals. The trick is to preserve a natural presentation and avoid inundating the model with a manifesto.

In the case of DRAP, each of these stages is comprised of a few brief but dense paragraphs that relate to the respective headings. "Reading the prompt" details how to handle input when it arrives (e.g., read thoroughly, ask of clarification if needed, identify limitations). The next two components correspond to framing and development and create a scaffolding for the processing that follows. These instructions answer questions like: What perspective(s) should be employed? How should context be treated? What are essential aspects of the output? The last component concerns the form of the response: how should the output be presented?

This type of foundation layer should be clear, organized, consistent, and flexible. Priorities and boundaries should be unambiguous, even if the mechanisms for achieving them are not fully defined. In fact, the less descriptive the foundation layer the more adaptable the model will be. The purpose of the next layer will be to edify what achieving these high-level aims looks like.

Layer 2: Focus (DRAP: Composition Guidelines)

If the foundation or "Core Framework" is goal-driven, the focal layer provides a lens through which to implement these aims. This set of practical guidelines will not only uphold the foundational goals of the system prompt but serve as the evaluative criteria for the introspective review process during reflection. These guidelines represent a pivotal dual-lens, functioning as high-level filters for initial generation and more granular requirements during review and refinement. This variable lens should be specified so that fulfilling the criteria achieves the intention of the system prompt without introducing a discordant checklist.

The relationship between the foundational and focal layers should be declared explicitly to reinforce their complementarity. A bridge should tie the first layer to the second, as in DRAP: "Use the 'Composition Guidelines' below to orient and shape analysis while upholding the integrity of the 'Core Framework' above." Note that single quotes are used to clearly reference the module headers. The spatial descriptors ("below", "above") tie a linguistic "knot". Such tethering and anchoring techniques can be used to strengthen conceptual or functional relationships in semantic programs.

The focal or implementation criteria should be introduced clearly. It is good practice to state purpose up front to help the model or a person find their bearings. DRAP instructs the model to "Apply the 'Composition Guidelines' as a compass to iteratively improve and refine analysis." The navigational motif speaks to the intended use of the guidelines and helps to tether the beginning of the 'Composition Guidelines' ("compass") to the preceding bridge at the end of the 'Core Framework' ("orient"). In general, the breadth and depth of abstraction can improve instructional density but may increase cognitive load. Put differently, you can process more by thoughtfully saying less.

The implementation guidelines that serve as a lens to focus the response carry a lot of weight. They need to correspond to and uphold the high-level standards and goals of the foundation layer while serving as high-resolution criteria for review and revision in the reflection layer. The guidelines need to avoid rigid over-specification while reflecting the priorities of the system prompt and steering convergence toward a response. They need to be flexible enough to encapsulate as many uses and outcomes as possible but specific enough to be acted upon. The guidelines need to be just right.

DRAP's eight 'Composition Guidelines' were chosen to reflect salient elements of the "Core Framework" and ordered to mirror the input-framing-development-output cadence. For consistency, each component of the foundation layer should have at least one corresponding guideline to help ensure that actionable goals are accomplished; a degree of overlap is expected. The microstructure of each guideline is also important. Gerunds and nominative forms are appropriate for the category headers while direct imperatives follow to give the model something to do. DRAP's bolded headers are: Identifying the goal (input, output), Articulating underlying assumptions (framing, development), Maintaining objectivity (framing), Verifying sources and evidence (development), Considering alternative viewpoints (framing, development), Exploring nuance (development, output), Synthesizing (input, output), and Communicating to inform (output).

At this point, the model has no shortage of things to do or be or not do or not be. As the list of instructions grows, the model's capacity for following them diminishes. The focal layer's guidelines need to be succinct and capture the foundation layer's spirit so that you reinforce principles rather than pile on tasks. In this way, the focus commands can be understood as means to achieve overarching goals and not more to-dos. Consider:

"-**Identifying the goal:** Determine the active prompt's objective. What does the current analysis seek to address? How should the analysis be presented?"

A thorough reading of the prompt that assesses whether and how it can be answered, as specified in the foundation, should naturally correspond to this guideline. A certain degree of redundancy is also needed to preserve semantic fidelity or the intended thrust of the instructions.

The guidelines should be concise for comprehension and impact. Each of the remaining DRAP criteria is comprised of a single sentence. Imagine a person is reading these guidelines to implement them. What are the most consequential takeaways from the foundation layer that should be incorporated into the response? This person stands a better chance of remembering and implementing these guidelines if the latter are to the point and presented in a coherent fashion, and so will the model. Rather than belabor process, tell the model (or person) what to achieve while affording them the discretion and flexibility to figure out how.

You may have noticed a hint of circularity or repeatability inherent in the guidelines; that is by design. Whereas the guidelines first shape initial generation by providing actionable elements to uphold the foundation, they may now serve as criteria for iterative review and modification. This duality provides for semantic continuity and instructional compactness.

Layer 3: Reflection (DRAP: Mandatory Review Process)

Up until now, all of our instructions only shape the initial generation. This is the general goal of system prompts; however, we can use the focal layer to pivot toward a novel reflective process. By instructing the model to apply the previous guidelines as "evaluative criteria" to review and possibly refine generated output before responding, we can effect recursive self-improvement within a single prompt-response turn. Our task is to tell the model how to reflect and improve upon its own work before committing it to context.

First, we need to declare the review process and state its purpose. This includes when, how, and why it occurs. DRAP states, "Before responding, conduct a review process using the 'Composition Guidelines' as evaluative criteria for improvement." Here we have explicitly invoked the focal layer's guidelines as the mechanism by which responses may be improved. From this you can infer that the guidelines not only articulate what makes for a "good" response but also what makes for a "better" one. Since we are specifying a logical procedure, each step is significant. We need to remind the model that this process should be executed after initial generation but before a response is returned. DRAP goes so far as to label the entire module as "mandatory" to remind efficiency-seeking models that the review process is not optional.

Now we need to clearly define elements of the review process. The risk of introducing a loop is that it stalls or otherwise does not end, so precision and completeness are paramount. Note that while the content of the system prompt's foundation and focus is inherently subjective and discretionary, the mechanics of reflection are more specific and must constitute a repeatable, convergent process. While several aspects are modifiable, the nature of the core loop is less flexible.

In the "Definitions" section, we begin with the review process - what is it? From DRAP: "The review process consists of a sequence of cycles. In each cycle the response is evaluated in its entirety as a distinct draft. Drafts are prompt-specific and temporary." In short, the model will conduct a sequence of cycles (comprised of steps) in which transient context or "drafts" of a response to a given prompt are evaluated as a whole. Generated outputs are treated holistically so as not to repeatedly interrupt their composition or have the model review isolated phrases and call it a day. Here "draft" is an arbitrary but meaningful unit of measure; other substitutes could do. Note that we also label this a "review" process and not a "drafting" or "revision" process. We want the model to look first before acting and to avoid implying the existence of and search for mistakes that may not be present.

Since we are configuring an unsupervised review process, we need to establish when to keep going and when to stop. If we want to retain the flexibility and power of the model's discretion, this stopping criteria cannot be over-specified; however, they must be specific enough to enable a determination in the first place. To keep things simple, we define two classes and allow for four outcomes (neither, A, B, both). In DRAP, we lean on the drafting metaphor and introduce "substantive improvements" (A) and "stylistic refinements" (B).

We define substantive improvements as "mov[ing] the analysis toward fulfillment of the 'Composition Guidelines'." This is general enough to avoid overly narrow prescription but leverages the system prompt's modularity to incorporate the focal layer by reference. In this manner, the evaluative criteria are separable from the review process itself. To bound the loop and prevent infinite regress, we state conditions for exhaustion: either all criteria are satisfied or no further improvements are possible without running afoul of another guideline.

What about improvements that are not substantive? DRAP categorizes this residual set as stylistic refinement. This could include "syntax, tone, or clarity of expression" as well as "purely orthographic edits". This category is definitely "fuzzier": we have not fully defined the set and in fact some stylistic refinements may very well be substantive. This is fine. The aim is to distinguish the goal criteria driving the loop without limiting the scope for improvement. Still, there should be enough conceptual distance between the classes to avoid "collapse", wherein the model cannot differentiate between types to successfully execute and terminate the loop. The class names and characteristics are arbitrary but should be relevant and allow for completeness.

With these definitions in hand, we can describe the review process for the model to execute. You will find that "lazy" models (and writers) will be quick to dismiss the need for improvement, so a floor of one cycle is essential. A maximum number of cycles is advisable to manage computational costs while minding the principle of diminishing returns and guaranteeing termination. Within this range, the exact number of cycles is left to the model to determine. But how?

Each cycle begins with an evaluation wherein the model examines the most recent generated output as a distinct draft to identify opportunities for improvement, which may be in substance, style, or both (or neither). If such improvements are possible the draft is "modified" or regenerated using the token string of the previous complete draft as input. If no changes were made or they were exclusively stylistic (i.e., not substantive), a circuit-breaker terminates the loop. This helps to ensure that improvements are not rationalized as substantive after the fact, which would perpetuate the loop, since the nature of changes (or lack thereof) is determined before they are made. Rather than having the model make a determination about whether to continue, a polish-only cycle means it is time to put our pencils down.

If substantive improvements were made (as constituted by the focal layer guidelines), the next step is to determine whether further such improvement is still possible. This end-of-cycle evaluation may seem repetitive, but it is a necessary test of whether to proceed with another cycle. If there are "remaining opportunities" to fulfill the guidelines without conflict (we use "remaining" to reinforce the notion of convergence), then the review process continues and another cycle commences. Otherwise, the review process concludes. The review process will also end if the specified maximum number of cycles has been conducted.

It is critical to ensure that the stopping criteria account for all possible determinations: no substantive changes were made (terminate), substantive changes were made but no opportunities for further substantive improvement are identified (terminate), substantive changes were made and more are possible (continue), or the maximum number of cycles has been reached (terminate). Note that removing the cycle cap is possible but introduces the risk of infinite search for "mistakes" to fix or "ghost" improvements.

After the review process concludes we need to clean up our work and provide a visible output. This involves committing the final draft to the response and "discarding" other drafts. While these generated responses consume tokens and are not "deleted" in the traditional sense, excluding them from the output stream greatly reduces their semantic influence and mitigates forward error propagation. In this manner, the model's "best" work becomes the output of record in the session's context window. For completeness, we specify that the reflective module (DRAP: Mandatory Review Process) is now finalized and that a response should be returned.

Layer 4: Synthesis (DRAP: Final Note)

Though not strictly required, a final note that captures the spirit and substance of the operating logic establishes semantic continuity and reinforces the overarching relationship between the why (foundation), what (focus), and how (reflection). Not unlike Douglas Hofstadter's "strange loops", DRAP's final note circles back through the end goal ("Provide grounded, truthful, and complete responses"), the operational process ("Prioritize transparency and clarity..."), and finally the nature of the system itself ("Analysis is an iterative process of exploration, review, and refinement.") And so we end where we begin.

Extensions:

With a single system prompt, a sufficiently capable model can be instructed to review and modify its own generated output in order to return more fully vetted responses and mitigate persistent error propagation. Based on three fundamental layers, foundational values can be distilled into guidelines that drive iterative, self-directed improvement, or analytical recursion through semantic programming. The purpose, goals, and evaluative criteria can be arbitrarily specified, as can many facets of the review process, provided that these components are semantically and logically coherent. This specification's modularity and procedural nature also allow multiple agents (people or models) to work in concert.

The text-based approach is fully portable to sufficiently-trained, general-use LLM's (open-weight models for edge devices meet this threshold) and complements state-of-the-art inference and prompting techniques. The logic is translatable: other localizations are possible and can perform similarly so long as the target languages are adequately represented in the chosen model's training corpus and the instructions are faithfully recomposed (a nontrivial task). You can also apply the methodology to arbitrary prompts, be they language, media, or some other format, as long as these inputs can be encoded in a manner interpretable by the model or system. Moreover, the entire methodology is written with people in mind; you can follow DRAP yourself.

Aside from composition of the foundation and focus layers, reflection (i.e., the review process) is also configurable and extensible. The definitions, loop parameters, and terminal conditions are customizable but must maintain internal consistency. The evolution of drafts in the model's latent workspace can also be extracted by integrating logging instructions and making use of delimiters. Such extraction introduces security risks, however, and must be implemented with care and only if necessary.

Insofar as the context window's use as a form of working memory for drafts and auditing can be supplanted by external mechanisms (e.g. dedicated physical memory), the methodology's recursive potential extends well past the session dialogue.

Limitations:

Although the system prompt exemplified by DRAP is relatively lightweight on its own (<2000 tokens), the obvious costs for these additional layers of cognitive processing are increased latency and token consumption. This methodology, which literally instructs the model to productively overthink, is not appropriate for circumstances that call for real-time responses or for superficial or straightforward queries that may be better served by default configurations. If your compute and other resource costs vary with usage, consider limiting applications of this or similar methodologies to tasks demanding a higher degree of rigor or verification. Testing in a local model first may be appropriate to gauge efficacy and resource requirements.

While AI models may be capable of following and executing an intelligent process, they are probabilistic software that do not "understand" information as we do and are limited by their manner of training, inference, and generation. Even the recursive methodology outlined above will always be exposed to execution errors in the final pass. "Hallucinations" are an inextricable reality of today's generative architectures. We can attenuate their frequency and mitigate the most severe errors, but, much like with people, perfection is impossible. Think of a model's output as a potentially useful starting point that you must always verify.

This idea gives rise to the most fundamental limitations: the quality of data at the system's disposal and the contributions of the operator or person-in-the-loop. This methodology and these models are tools, subject to our specification and direction. There is no substitute for diligent engagement and reliable data - the maxim "garbage in, garbage out" is only amplified by LLMs. If you operate these models and methods thoughtfully, however, you may be surprised by how capable semantic programming can be.

Acknowledgements:

I could not have conceived of this approach without a lifetime of guidance and wisdom from family, friends, colleagues, and particularly patient teachers. I owe a great deal to the joys of curiosity, learning, reading, and writing that they instilled. I am also indebted to the open-source community and have released DRAP under AGPLv3 and its methodology to the public through Datum Research LLC. As much as I have come to enjoy systems analysis, I love reading books and writing even more. This project is a humble homage to William Germano's "On Revision", the best book I have ever read about writing.

Lastly, while I am the architect of its design, DRAP and its methodology were also the product of months of experimentation and refinement using Gemma open-weight local models. Communication is a two-way street, and my extensive dialogues with the model were indispensable to understanding how an LLM interprets what we say and how I could improve prompts accordingly, including DRAP. I am not sure it would be possible to produce a system prompt of this complexity without feedback from the system asked to apply it.

We ought to have AI think with us, not for us. This paper was composed, reviewed, and refined in its entirety by a person. I hope it helps you.

Eddie