# sarathi production software engineering process diagram prompt

Use case: infographic-diagram
Asset type: detailed software-delivery process poster for engineers and stakeholders

Primary request: Create a polished, native AI-generated landscape process diagram titled
"sarathi — PRODUCTION SOFTWARE ENGINEERING WITH AI AGENTS". Explain sarathi's timeless core
rather than recent feature fixes. The image must present one enduring model: accepted intent becomes the
smallest safe working increment; decisions and evidence remain reviewable; work is
decomposed when it is too complex to reason about safely as one unit; feedback changes what happens
next. The result must unmistakably be an adaptive loop, not a waterfall and not a visual
changelog.

Audience: software engineers working with AI coding agents, technical leads, product owners,
reviewers, and security or reliability stakeholders.

Style/medium: premium editorial systems infographic; crisp vector-like shapes rendered as
a high-quality raster image; restrained technical illustration; clean sans-serif
typography; precise arrows; compact line icons; generous whitespace; strong hierarchy. It
should feel like an experienced engineering organization's architecture poster, not a
generic corporate flowchart, dashboard, web page, Mermaid diagram, UML export, or release
notes graphic.

Composition/framing: wide landscape poster composed for documentation and presentation
use; native generator dimensions may differ from 16:9. Use one visually dominant circular
or rounded-rectangular delivery loop in the center, a conditional decomposition branch
below planning, and two strong cross-stage quality rails immediately beneath the loop.
Continuity, risk, and authoring rules remain quiet supporting material. Keep all connectors
clean and avoid crossing arrows.

1. TITLE AND ENDURING STATEMENT
   - Large title, verbatim: "sarathi — PRODUCTION SOFTWARE ENGINEERING WITH AI AGENTS"
   - Subtitle, verbatim:
     "Accepted intent becomes safe working software — evidence and feedback shape what comes next."
   - Small badge: "Enduring model — not waterfall"

2. CENTRAL DELIVERY LOOP — VISUALLY DOMINANT
   Arrange four large connected panels from left to right, then curve a bold feedback arrow
   from the final panel back toward any earlier panel. The panels are:

   - "SPEC — DEFINE THE REQUIREMENTS"
     "Problem, stakeholders, scope"
     "Needs → features"
     "Use cases: main, alternate, failure flows"
     "Functional + supplementary requirements"
     "Black-box acceptance tests + journeys"
     "Traceability: needs → observable evidence"
     Exit label: "Testable requirements understood and accepted"

   - "DESIGN — SHAPE THE SOLUTION"
     "Architecture, responsibilities, boundaries, interfaces, data, decisions, quality attributes"
     Exit label: "Technical model understood"

   - "PLAN — STRUCTURE THE DELIVERY"
     "Impact map"
     "Breakdown: child outcomes + dependencies"
     "Implementation: PR graph + sequence"
     "Integration, safety, proof"
     Exit label: "Delivery structure understood"

   - "CODE + TESTS — WORKING BEHAVIOR"
     "RED — observe the behavioral test fail"
     "GREEN — smallest production change"
     "REFACTOR — focused + affected tests stay green"
     "Exact results, cleanup"
     Exit label: "Tested working behavior"

   Label the bold return path, verbatim:
   "Evidence → feedback → adapt the remaining work"

   Add three small destinations on that return path:
   "Confirm"
   "Revise"
   "Replan"

3. CONDITIONAL DECOMPOSITION — A FIRST-CLASS STRENGTH
   Beneath the Plan panel, show a clear decision diamond titled:
   "CAN THE WORK BE UNDERSTOOD AS ONE COHERENT UNIT?"

   Add a compact explanation beside it, verbatim:
   "Decomposition reduces mental load. Split when the work cannot be understood as one coherent unit."

   Two paths leave it:
   - Main path: "Yes — keep the work together"
   - Branch path: "No — decompose along a natural boundary"

   The branch fans into four compact, human-readable boundary cards:
   "Capability or outcome"
   "Responsibility or data"
   "Interface or dependency"
   "Risk or migration"

   The child increments visibly reconnect at a shared feedback or integration point before
   returning to the main loop. Add this sentence, verbatim:
   "Stop when each part is understandable, testable, and safe to integrate."

4. TEST EVIDENCE AND REVIEW — STRONG ACROSS THE WHOLE LOOP
   These are first-class horizontal rails connected to all four central stage panels, not
   a small footer or detached legend.

   First rail title: "TEST EVIDENCE THROUGH DELIVERY"
   Show four aligned steps:
   "Spec — observable acceptance"
   "Design — test architecture + boundary proof"
   "Plan — tests assigned to delivery"
   "Code — Red → Green → Refactor + exact results"

   Second rail title: "QUALITY GATE AT EVERY STAGE"
   Show four steps:
   "Create — write or revise"
   "Verify — repeatable checks"
   "Review — independent judgment"
   "Assess — checks + review"

   Caption, verbatim:
   "Every stage is checked and independently reviewed before it is accepted for the next learning step."

   Add a smaller clarification:
   "Automatic checks report facts. Review judges meaning, test adequacy, simplicity, and safety."

5. CONTINUITY — RESUMABLE WITHOUT CHAT HISTORY
   Show a quiet vertical thread titled "CONTINUITY" connecting three items:
   "Accepted decisions"
   "Working evidence"
   "Current position + one next action"

   Caption, verbatim:
   "A new engineer or agent can resume from source records and observed results."

6. RISK CONTROLS — DEPTH FOLLOWS CONSEQUENCE
   Show a compact rail titled "ASSURANCE FOLLOWS RISK" with four levels:
   "Lean — small and reversible"
   "Standard — ordinary default"
   "High assurance — stronger proof for material risk"
   "Exploratory — timeboxed, non-production"

   Caption, verbatim: "High assurance adds evidence, not up-front ceremony."

7. SUPPORTING AUTHORING RULES — VISUALLY SECONDARY
   Use a narrow pale footer band titled "SUPPORTING RULES". Include only four short items:
   "Explain the product and technical change before metadata"
   "State engineering reality and exact completion scope"
   "Reuse proven behavior and make ownership explicit"
   "Keep traceability out of production code"

   These items must be visibly subordinate to the delivery loop and decomposition branch.
   Do not use "product-first" as the title, do not list planning classification categories,
   do not show WIP fields, and do not put identifier hygiene in a prominent slogan.

Color palette: deep navy #102A43 for titles; blue #1769AA for intent and design;
teal #0E7490 for the adaptive loop; green #15803D for working behavior and accepted boundaries;
amber #D97706 for decisions, risk, and human gates; muted coral #C65D57 for revise/replan;
warm off-white #F7F5EF background; light gray-blue for supporting rails. Use accessible
contrast and consistent meaning.

Visual grammar: rounded stage panels, a bold continuous return arrow, one clear decision
diamond, child increments that visibly rejoin, a continuous test-evidence thread,
independent-review eye icons attached to every stage, deterministic check squares,
Red-Green-Refactor cycle arrows, evidence document icon, continuity thread, and restrained
risk shield. The core loop, test/review rails, and conditional decomposition must dominate
the visual hierarchy.

Text constraints: Render every quoted title, label, and caption exactly as written. Use no
Sarathi IDs, no invented acronyms, no project-specific examples, no version numbers, no
gibberish placeholder text, no tiny unreadable footnotes, no logos, no trademarks, and no
watermark. Maintain accurate spelling of "sarathi", "Verify", "Assess", "decompose",
"assurance", and "evidence".

Output intent: a detailed standalone raster infographic suitable for documentation,
presentations, and zoomed review. Prioritize conceptual relationships and legibility over
decoration. The viewer's first impression must be sarathi's production software engineering
workflow for AI agents, not a collection of recent corrective policies.
