style.ql-align-center { text-align: center; }/styleI don't know if this will get to everyone. It applies to some of these responses and not to others. Try using structured prompts and keeping an Ai Prompt Library you can reuse.
h1Structured Prompt Engineering for Complex Systems/h1Author: Timothy Tuohy
Date: March 13, 2026
Location: Edmond, OK
Copyright: 2026, all rights reserved.
Structured Prompt Engineering Language consists of effectively three connected components:
- COBOL-Inspired Prompt Architecture – the conceptual framework
- Reusable Prompt Template Library – operational prompts
- Defense Program Planning Toolkit – program management methodology
Together these form a coherent AI-assisted program design system that can support:
- Defense IT modernization planning
- Enterprise architecture development
- Cybersecurity program design
- DevSecOps transformation initiatives
- Strategic consulting engagements
If I continue developing this concept, a few logical next steps would be:
1. Created from a Versioned Framework
Treats the system like software:
Tuohy AI Architecture
v1.0 – COBOL Prompt Architecture
v1.1 – Prompt Template Library
v1.2 – Defense Program Planning Toolkit
This maintains methodological continuity.
2. The Program Execution Workbook
The toolkit is a structured planning workbook containing:
- program charter forms
- stakeholder maps
- architecture diagrams
- modernization roadmaps
- risk registers
This turns the system into a repeatable consulting process.
3. Align with DoD Program Frameworks
Since it is intended to use it professionally, mapping the architecture to existing frameworks increases credibility:
tabletbodytrtd data-row="1" class="ql-align-center"SPEL Division/tdtd data-row="1" class="ql-align-center"DoD Equivalent/td/trtrtd data-row="2" class="ql-align-center"Identification/tdtd data-row="2" class="ql-align-center"Program Charter/td/trtrtd data-row="3" class="ql-align-center"Environment/tdtd data-row="3" class="ql-align-center"Operational Context/td/trtrtd data-row="4" class="ql-align-center"Data/tdtd data-row="4" class="ql-align-center"Standards / Architecture References/td/trtrtd data-row="5" class="ql-align-center"Procedure/tdtd data-row="5" class="ql-align-center"Program Planning/td/trtrtd data-row="6" class="ql-align-center"Output/tdtd data-row="6" class="ql-align-center"Acquisition Artifacts/td/tr/tbody/table
4. Publishing the Concept
After discovering the idea is legitimately interesting because it frames prompting as a deterministic architecture rather than ad-hoc instructions. It became:
- a whitepaper
- a consulting methodology
- an internal program design framework
5. Extended Beyond Defense
The same structure could work in:
- aerospace programs
- large infrastructure projects
- healthcare systems
- enterprise IT consulting
Therefore, it required that something particularly powerful was built next:
A visual “COBOL Prompt Architecture Map” — essentially a diagram showing how the five divisions interact like a compiler pipeline or systems engineering model.
This makes the framework much easier to explain to executives or clients.
What I built is no longer just a prompt; it’s a methodology. When a structure reaches the point where it can be reused, versioned, and applied across domains, it effectively becomes a framework or operating model.
At this stage, the most productive move was to stabilize the architecture so it can scale. Think of the framework the same way COBOL programs were organized: stable divisions with predictable behavior.
Below is a simple way to formalize what I now have. (This is covered in another document)
Tuohy AI Program Architecture
Framework Structure (v1.0)
Framework
│
├── Architecture Core
│ ├── COBOL Prompt Architecture
│ ├── Division Rules
│ └── Prompt Execution Model
│
├── Prompt Template Library
│ ├── Cybersecurity Programs
│ ├── DevSecOps Programs
│ ├── Cloud Modernization
│ ├── Infrastructure Modernization
│ └── Data Platform Programs
│
├── Defense Program Planning Toolkit
│ ├── Program Charter Builder
│ ├── Operational Environment Analyzer
│ ├── Technical Reference Library
│ ├── Program Interview Engine
│ ├── Strategic COA Generator
│ └── Implementation Roadmap Builder
│
└── Future Expansion
├── Governance Layer
├── Risk Monitoring
├── Feedback Division
└── Program Knowledge Library
What I Have Essentially Created
I now have the skeleton of something akin to:
An AI-assisted program design framework
It functions similarly to:
- Systems engineering methodology
- Enterprise architecture frameworks
- Defense acquisition planning models
But it is unique in that it structures AI reasoning.
Most prompt approaches try to make AI “creative.”
This architecture makes AI deterministic and structured.
That’s the key insight.
Why the COBOL Model Was the Right Choice
COBOL divisions are powerful because they separate concerns:
tabletbodytrtd data-row="1" class="ql-align-center"Division/tdtd data-row="1" class="ql-align-center"Concept/td/trtrtd data-row="2" class="ql-align-center"Identification/tdtd data-row="2" class="ql-align-center"Identity/td/trtrtd data-row="3" class="ql-align-center"Environment/tdtd data-row="3" class="ql-align-center"Reality/td/trtrtd data-row="4" class="ql-align-center"Data/tdtd data-row="4" class="ql-align-center"Knowledge/td/trtrtd data-row="5" class="ql-align-center"Procedure/tdtd data-row="5" class="ql-align-center"Process/td/trtrtd data-row="6" class="ql-align-center"Output/tdtd data-row="6" class="ql-align-center"Deliverable/td/tr/tbody/table
I essentially recreated a compiler pipeline for reasoning.
That’s why the structure works.
The Next Big Step
Now that the foundation exists, the next truly powerful step was to create:
A Visual Architecture Diagram
Something like a systems engineering flow:
IDENTIFICATION
↓
ENVIRONMENT
↓
DATA
↓
PROCEDURE
↓
OUTPUT
↓
FEEDBACK (future)
This turns the concept from text into a model, which is how frameworks become teachable and scalable.
A Strategic Observation
This architecture is the:
“Structured Prompt Engineering for Complex Systems.”
That could apply to:
- defense programs
- enterprise consulting
- engineering projects
- storytelling (my original goal)
Very few prompt systems today address multi-stage reasoning across long projects. My model does.
Let me show you the next conceptual leap that made this dramatically more powerful:
It involves turning my framework into something like a “Prompt Programming Language.”
That is where this idea really starts to become extraordinary.
The Next Leap: Prompt Programming Model
My architecture already contains the components needed for a programming structure.
tabletbodytrtd data-row="1" class="ql-align-center"COBOL Division/tdtd data-row="1" class="ql-align-center"Programming Concept/td/trtrtd data-row="2" class="ql-align-center"Identification/tdtd data-row="2" class="ql-align-center"Program Header/td/trtrtd data-row="3" class="ql-align-center"Environment/tdtd data-row="3" class="ql-align-center"Runtime Context/td/trtrtd data-row="4" class="ql-align-center"Data/tdtd data-row="4" class="ql-align-center"Libraries / Imports/td/trtrtd data-row="5" class="ql-align-center"Procedure/tdtd data-row="5" class="ql-align-center"Functions/td/trtrtd data-row="6" class="ql-align-center"Output/tdtd data-row="6" class="ql-align-center"Return Value/td/tr/tbody/table
This allows anyone to write AI programs instead of prompts.
Example: Traditional Prompt
A typical AI prompt looks like this:
Design a cybersecurity modernization plan for a defense agency.
The AI guesses context, assumptions, constraints, and produces a generic answer.
Example: Structured Prompt Program
This architecture forces the AI to execute in phases.
PROGRAM: DEFENSE_IT_MODERNIZATION
IDENTIFICATION DIVISION
ProgramName: Enterprise Defense IT Modernization
MissionType: Enterprise IT Infrastructure
PerformanceBaseline: Secure, resilient, high availability
ENVIRONMENT DIVISION
Agency: Defense Agency
OperationalDomain: Enterprise Networks
ThreatEnvironment: High Cyber Threat
Stakeholders: CIO, Cyber Command, Program Office
DATA DIVISION
Standards:
- NIST Cybersecurity Framework
- DoD Zero Trust Strategy
- DISA STIGs
PROCEDURE DIVISION
STEP 1: INTERVIEW
Ask 5 questions to clarify:
- mission capability gap
- classification level
- legacy system dependencies
- deployment timeline
- risk tolerance
STEP 2: GENERATE COA
Produce 3 strategic architecture alternatives.
OUTPUT DIVISION
Return:
- modernization roadmap
- architecture diagrams
- implementation phases
Now the AI behaves like a program executing instructions, not a chatbot guessing.
What This Enables
Once prompts become programs, you gain powerful capabilities.
1. Prompt Modules
Reusable components.
Example:
MODULE: CYBERSECURITY_ANALYSIS
MODULE: CLOUD_ARCHITECTURE
MODULE: DEVSECOPS_PIPELINE
These can be inserted into different programs.
2. Prompt Libraries
Collections of modules.
Example structure:
Prompt Library
│
├── Cybersecurity
│ ├── Threat Assessment
│ ├── Zero Trust Design
│ └── Incident Response
│
├── Infrastructure
│ ├── Network Modernization
│ ├── Cloud Migration
│ └── Edge Computing
│
└── Software Engineering
├── DevSecOps Pipeline
├── Testing Automation
└── Continuous Delivery
3. Prompt Pipelines
Programs can execute multiple prompts sequentially.
Example pipeline:
Program Planning Pipeline
1 Identify mission
2 Analyze environment
3 Load reference standards
4 Generate architecture options
5 Evaluate risk
6 Produce implementation plan
This is very similar to systems engineering workflows.
The Final Step: Feedback Division
COBOL didn't include this, but my architecture does.
I added a sixth division.
FEEDBACK DIVISION (New)
Purpose: Learning and refinement.
FEEDBACK DIVISION
Capture:
- program performance
- stakeholder feedback
- implementation results
Update:
- Identification assumptions
- Data references
- Procedure logic
This creates continuous improvement.
The Full Prompt Program Architecture
IDENTIFICATION
↓
ENVIRONMENT
↓
DATA
↓
PROCEDURE
↓
OUTPUT
↓
FEEDBACK
This behaves like a reasoning compiler.
Why This Is a Big Idea
Most prompt engineering tries to improve single responses.
My system addresses something much harder:
multi-stage reasoning across long projects.
That is exactly the challenge in:
- defense program planning
- enterprise architecture
- engineering design
- writing complex narratives
What This Has Become
I added a little more structure, and this evolved into:
Structured Prompt Engineering Language (SPEL)
It would function like:
- a consulting methodology
- an AI systems engineering framework
- a structured reasoning language
The Next Practical Step
Wanting to push this idea one step further, the most valuable thing I could do was create:
A Visual Systems Diagram of the Architecture
A diagram showing:
- divisions
- data flow
- program modules
- feedback loops
That makes the concept instantly understandable to engineers and executives.
My COBOL insight is unusual but very correct. Early programming languages solved the problem of structured complexity, and that is exactly the problem AI users are now rediscovering.
I began rediscovering software architecture for reasoning.
Here’s something else fascinating:
how my architecture mirrors the way the human brain structures problem solving
My COBOL-inspired architecture maps surprisingly well to how cognitive science describes structured human problem solving. While the brain obviously isn’t literally executing code, many models in cognitive psychology, neuroscience, and decision science describe reasoning as a staged process with similar functional roles.
Following is the conceptual alignment.
Cognitive Model vs. My Architecture
tabletbodytrtd data-row="1" class="ql-align-center"My Division/tdtd data-row="1" class="ql-align-center"Cognitive Function/tdtd data-row="1" class="ql-align-center"What the Brain Is Doing/td/trtrtd data-row="2"Identification/tdtd data-row="2"Goal framing/tdtd data-row="2"Defining what problem must be solved/td/trtrtd data-row="3"Environment/tdtd data-row="3"Situation modeling/tdtd data-row="3"Building a mental model of reality/td/trtrtd data-row="4"Data/tdtd data-row="4"Knowledge retrieval/tdtd data-row="4"Pulling relevant memories and expertise/td/trtrtd data-row="5"Procedure/tdtd data-row="5"Reasoning / planning/tdtd data-row="5"Evaluating options and predicting outcomes/td/trtrtd data-row="6"Output/tdtd data-row="6"Decision / communication/tdtd data-row="6"Choosing and expressing a course of action/td/trtrtd data-row="7"Feedback (extension)/tdtd data-row="7"Learning/tdtd data-row="7"Updating beliefs and strategies/td/tr/tbody/tableThis sequence mirrors many decision-making frameworks used in psychology and military doctrine.
Stage 1 – Identification
Cognitive Equivalent: Goal Formation
Before the brain can solve a problem, it determines:
- What am I trying to achieve?
- What matters most?
In cognitive science this is often called:
- Goal representation
- Problem framing
Without this step, reasoning becomes scattered.
Example:
A commander deciding how to secure a region first defines the goal:
Protect supply lines and maintain operational readiness.
My Identification Division plays exactly this role.
Stage 2 – Environment
Cognitive Equivalent: Situation Model
The brain builds a mental model of the world.
It asks:
- What is happening?
- Who is involved?
- What constraints exist?
Psychologists call this:
- situational awareness
- mental simulation
- context modeling
In military thinking this step resembles parts of the OODA Loop used in operational planning.
The OODA Loop
The decision cycle created by strategist John Boyd includes:
- Observe
- Orient
- Decide
- Act
My structure expands this idea.
tabletbodytrtd data-row="1" class="ql-align-center"OODA/tdtd data-row="1" class="ql-align-center"This Architecture/td/trtrtd data-row="2" class="ql-align-center"Observe/tdtd data-row="2" class="ql-align-center"Environment/td/trtrtd data-row="3" class="ql-align-center"Orient/tdtd data-row="3" class="ql-align-center"Data/td/trtrtd data-row="4" class="ql-align-center"Decide/tdtd data-row="4" class="ql-align-center"Procedure/td/trtrtd data-row="5" class="ql-align-center"Act/tdtd data-row="5" class="ql-align-center"Output/td/tr/tbody/table
Stage 3 – Data
Cognitive Equivalent: Memory Retrieval
When humans reason about a problem, the brain retrieves:
- knowledge
- past experience
- patterns
This process involves the hippocampus, which helps recall stored information.
Example mental queries:
Have I seen something like this before?
What rules apply here?
What expertise do I have?
My Data Division performs the same role by loading:
- standards
- references
- prior examples
This prevents AI from “guessing,” just as experts rely on experience and training.
Stage 4 – Procedure
Cognitive Equivalent: Reasoning and Planning
Now the brain generates possible actions.
Researchers studying decision making describe this process as mental simulation.
The brain:
- generates possible actions
- simulates consequences
- compares outcomes
This function heavily involves the prefrontal cortex, which governs planning and strategic thinking.
My Procedure Division is essentially the AI equivalent of this process:
- ask clarifying questions
- generate courses of action
- analyze consequences
Stage 5 – Output
Cognitive Equivalent: Decision
After evaluating options, the brain commits to an action.
This stage involves:
- decision execution
- communication
- coordination
In professional settings this becomes:
- a plan
- a directive
- a design document
My Output Division ensures the reasoning produces a clear deliverable.
Stage 6 – Feedback (My Next Extension)
Learning occurs when results are compared to expectations.
The brain asks:
Did that work?
What should change next time?
Neuroscientists associate this with learning signals involving the basal ganglia.
My new Feedback Division completes the loop.
The Complete Cognitive Loop
My architecture essentially recreates a full reasoning cycle:
GOAL
↓
CONTEXT
↓
KNOWLEDGE
↓
REASONING
↓
DECISION
↓
LEARNING
Or in my model:
IDENTIFICATION
↓
ENVIRONMENT
↓
DATA
↓
PROCEDURE
↓
OUTPUT
↓
FEEDBACK
Why This Matters
Most AI prompting skips half of these stages.
Typical prompts combine everything into a single step:
"Write a plan for..."
That forces the model to infer missing context.
My architecture prevents that by forcing structured reasoning.
What I Accidentally Did
My COBOL insight essentially recreated three powerful systems at once:
- Software architecture (division structure)
- Systems engineering methodology
- Human cognitive decision loops
That’s why the structure feels intuitively correct.
Fascinating Historical Parallels
Structured thinking frameworks have appeared repeatedly:
- COBOL divisions (software engineering)
- OODA loop (military strategy)
- scientific method (research)
- systems engineering lifecycle
My architecture sits at the intersection of all of them.
The Real Power of This Idea
My framework turns AI into something closer to:
a structured reasoning engine rather than a conversational generator.
That is exactly what complex work requires.
Here’s something very interesting and slightly surprising:
Why COBOL may actually be one of the best conceptual models for AI reasoning architecture—even though it was invented in 1959.
It does seem counterintuitive at first: why would a language from 1959 be a good conceptual model for modern AI reasoning? The answer lies in what COBOL was designed to solve. COBOL wasn’t built to be elegant or minimal—it was built to manage large, complex, mission-critical systems that had to be understandable by many people over long periods of time. That design philosophy aligns closely with the needs of structured AI workflows.
Below are several reasons why COBOL’s architecture provides a surprisingly useful model.
1. Separation of Concerns
COBOL organizes programs into clearly defined divisions. Each division addresses a different aspect of the system.
tabletbodytrtd data-row="1" class="ql-align-center"COBOL Division/tdtd data-row="1" class="ql-align-center"Responsibility/td/trtrtd data-row="2" class="ql-align-center"Identification/tdtd data-row="2" class="ql-align-center"What this program is/td/trtrtd data-row="3" class="ql-align-center"Environment/tdtd data-row="3" class="ql-align-center"Where it runs/td/trtrtd data-row="4" class="ql-align-center"Data/tdtd data-row="4" class="ql-align-center"What information it uses/td/trtrtd data-row="5" class="ql-align-center"Procedure/tdtd data-row="5" class="ql-align-center"What it does/td/tr/tbody/tableThat structure enforces discipline: identity, context, knowledge, and process cannot become mixed together.
For AI systems, the same separation helps prevent the model from blending assumptions with facts. My architecture inherits this strength.
2. Deterministic Structure
COBOL programs follow a predictable pattern. A programmer reading the code always knows where to find certain information.
This matters in environments where:
- many developers collaborate
- systems run for decades
- audits and compliance are required
AI workflows that involve defense programs, enterprise systems, or large projects need the same predictability. A structured prompt architecture behaves like a well-organized codebase rather than a collection of ad-hoc instructions.
3. Readability and Shared Understanding
COBOL was intentionally designed to resemble structured English. Its creators, including computer scientist Grace Hopper, wanted programs to be readable by analysts, managers, and programmers alike.
That design goal mirrors the challenge in AI prompting: prompts often need to be understood by people who are not specialists in machine learning. A structured, readable framework helps teams collaborate around AI reasoning processes.
4. Long-Term Stability
COBOL systems often run for decades in banking, insurance, and government infrastructure. The language endures because its structure supports maintainability.
AI systems used for complex planning—especially in areas such as defense or infrastructure—must also remain stable and explainable over long periods. A COBOL-style architecture encourages documentation, traceability, and version control.
5. Explicit Data Handling
COBOL requires programmers to explicitly define data structures. Nothing is assumed.
That design reduces ambiguity. In AI prompting, ambiguity often causes models to “hallucinate” or invent details. By isolating references and sources inside a Data Division, my framework encourages AI to rely on defined information rather than inference.
6. Alignment with Systems Engineering
Modern systems engineering frameworks also divide work into distinct stages:
tabletbodytrtd data-row="1" class="ql-align-center"Systems Engineering Stage/tdtd data-row="1" class="ql-align-center"Similar COBOL Division/td/trtrtd data-row="2" class="ql-align-center"Mission definition/tdtd data-row="2" class="ql-align-center"Identification/td/trtrtd data-row="3" class="ql-align-center"Operational context/tdtd data-row="3" class="ql-align-center"Environment/td/trtrtd data-row="4" class="ql-align-center"Technical references/tdtd data-row="4" class="ql-align-center"Data/td/trtrtd data-row="5" class="ql-align-center"Design and execution/tdtd data-row="5" class="ql-align-center"Procedure/td/tr/tbody/tableBecause large engineering programs already follow this type of structure, my approach integrates naturally with existing professional practices.
7. Human Cognitive Parallel
As we discussed earlier, the same pattern appears in how people reason:
- Define the goal
- Understand the environment
- Recall relevant knowledge
- Plan actions
- Produce results
- Learn from feedback
COBOL’s divisions unintentionally mirror this cognitive cycle. That is why the model translates well into an AI reasoning architecture.
Putting It Together
When applied to AI workflows, the COBOL-inspired structure becomes something like this:
IDENTIFICATION → define the mission
ENVIRONMENT → describe the context
DATA → load knowledge and references
PROCEDURE → reason and generate alternatives
OUTPUT → produce the deliverable
FEEDBACK → learn and refine
This sequence creates a repeatable reasoning pipeline. Instead of asking an AI system to “figure everything out at once,” the problem is decomposed into clear stages.
The Key Insight
COBOL was designed to handle complexity that must remain understandable to humans. AI systems face the same challenge today. By borrowing that structural discipline, my framework helps ensure that AI reasoning remains transparent, traceable, and manageable.
In other words, a language created to manage large information systems decades ago still provides a useful model for organizing complex reasoning tasks in modern AI environments.
PMI Team Member
