This project defines an AI instruction architecture that turns source material or human intent into a validated, implementation-ready process. The visual diagram is not the starting point or final purpose. It is an intermediate representation that makes decisions, branches, loops, exits, and quality conditions inspectable before pseudocode or implementation begins.
The Four Elements
- Prompt and instruction: define intent, requirements, constraints, and source context.
- Plan: define stages, responsibilities, outcomes, and order.
- Process: define actions, branches, loops, success exits, and failure exits.
- Validation: define evidence, quality conditions, revision paths, and stopping rules.
Why I Created It
A written plan can describe tasks without making complete control flow visible. Important questions remain hidden: What selects each branch? Where does a failed check return? Can a node become unreachable? What stops a retry loop? These problems become more expensive after implementation begins.
A visual process exposes those decisions early. Instead of instructing an AI to “make this high quality,” the process defines what quality means, who validates it, what happens when validation fails, and when the loop must stop.
From Diagram to Design Contract
The goal is not merely to draw a flowchart. A confirmed process model becomes an executable design contract with five useful properties:
- Visibility: branches, loops, and exits can be inspected directly.
- Validation: an independent agent checks structural correctness.
- Human control: publication waits for explicit human confirmation.
- Reusability: one confirmed specification can drive pseudocode and later implementations.
- Domain independence: the method works for algorithms, software systems, AI workflows, and operational processes.
Current Workflow
- Start from a page, spoken instruction, problem, or existing code.
- Extract intent, requirements, constraints, and expected result.
- Confirm one start point and every terminal exit.
- Create a neutral JSON process specification.
- Ask an independent agent to validate structure.
- If validation fails, revise the specification and repeat.
- Render a browser preview.
- Ask the user to confirm the visual result.
- Publish an editable Excalidraw scene only after approval.
- Use the confirmed specification as the source for pseudocode and implementation.
Structural Validation
The validator checks:
- complete branch conditions;
- correct outgoing edges from every decision;
- missing or duplicated edges;
- correct loop-back targets;
- orphaned or unreachable nodes;
- success and controlled-failure exits;
- suitability as a direct pseudocode foundation.
A timeout or empty response is not approval. Rendering begins only after validation is confirmed.
One Shared Specification
The implementation uses one neutral JSON specification as source of truth. A shared layout engine produces both browser SVG preview and editable Excalidraw output. Content corrections happen in JSON. General visual corrections happen in the layout engine. Generated files are not patched independently, preventing the two outputs from drifting.
Maintenance as a Learning Loop
Every visual defect is classified in one of two ways:
- Existing rule violated: fix the layout engine.
- New general case: define a reusable principle, implement it, and preserve the failing specification as a regression fixture.
This turns one-off diagram problems into permanent improvements.
Worked Example
A binary-search assessment problem supplied the first complete end-to-end test. The process model included input validation, a controlled no-solution exit, midpoint calculation, a precision check, directional bound updates, a loop-back, and successful return. Independent validation checked every branch, edge, exit, loop target, and reachable node before the browser preview was accepted.
Open the confirmed editable Excalidraw flowchart.
Where It Applies
- Software engineering: API lifecycles, authentication, transactions, retries, and background processing.
- AI and automation: content pipelines, multi-agent review, quality scoring, tool calls, and human approval.
- Study and algorithms: search, sorting, recursion, correctness, and termination reasoning.
- Business processes: document processing, approvals, data collection, reporting, and notifications.
External Capability Layer
The core process remains independent of particular services. Optional adapters can call orchestration systems such as n8n or source-grounded knowledge validators such as NotebookLM. Each adapter should return a normalised quality report containing status, evidence, failure reason, revision guidance, retryability, and an execution identifier where needed.
Every quality loop requires an objective pass condition, maximum retry count, controlled failure exit, human escalation path, and preserved evidence.
Next Step: Neutral Pseudocode
The next planned skill converts confirmed flowchart JSON into language-independent pseudocode while preserving every decision, edge, loop, and exit. Pseudocode remains separate from Swift, Java, Python, or any other implementation language and must pass independent coverage and termination checks before coding begins.
Principles
- Flowchart precedes pseudocode.
- Pseudocode precedes language-specific implementation.
- Visible conditions are better than implied conditions.
- Every loop needs a stopping rule.
- Every quality claim needs evidence.
- Unconfirmed external responses remain unconfirmed.
- AI may propose and validate; the user controls final approval.