A technical review deck should help its audience decide whether a change is worth pursuing. Architecture, measurements and visual style need to answer the same question. Generating them independently and assembling attractive pages can conceal missing reasoning. This guide uses a fictional greenhouse monitoring platform and a review of how to retain readings during an outage. It covers system diagrams, a complete review narrative and final visual acceptance. Example rules are teaching assumptions, not claims of a deployed or tested system.
Start with the decision and an evidence manifest
The review compares temporary retention at the gateway with relying only on fresh sampling after connectivity returns. The audience needs to understand what happens offline, how recovery avoids duplicate events and whether the added complexity is justified. Gather current component descriptions, communication agreements, an approved sanitized runtime summary, constraints and open questions. Do not ask a model to invent reliability percentages or cost savings to complete the story.
Give each source an identifier and distinguish existing, proposed and unknown behavior. Sensors, gateways, the receiving service, reading storage and an alert interface need supporting information before appearing as current architecture. Add a queue, cache or cloud product only when the input confirms it. Show a proposed design separately with explicit assumptions so that a reviewer cannot mistake a diagram for a deployment record.
Plan the pages before producing them: decision, current boundaries, outage sequence, options, evidence and limitations, and the next approval needed. Each page has a main judgment and source references. A cover, agenda and polished architecture page do not by themselves provide an argument for the change. Check whether the planned pages actually answer the decision question.
Scenario one: distinguish structure from runtime behavior
Build a component and relationship table first. Record each component's responsibility and boundary. For each edge record direction, data and what is known about the protocol. A structure view can show sensors submitting readings through a gateway to the receiving service, with storage supporting query and alerting functions. Put runtime ordering in a separate view rather than using one arrow to mean connection, call sequence and committed data.
The outage view must answer where readings remain, when they could be lost, who retries after recovery and how the receiver recognizes a repeated event. If identifiers, ordering or capacity policy remain undecided, list those questions beside the diagram. An agent should not silently design these rules and present them as implemented behavior. Reviewing the failure paths often exposes more useful questions than adding more boxes.
Choose source formats for maintenance. Mermaid text makes relationship changes inspectable in version control; a diagram editor's native source supports manual arrangement. SVG, PNG and PDF are presentation outputs and do not universally preserve editable business objects. Use the same revision identifier for diagram source, rendered output and the slide that embeds it. Regenerate and inspect the dependent pages after a change.
The open-source Mermaid CLI is a relevant rendering option: its MIT-licensed workflow converts Mermaid definitions to SVG, PNG or PDF. It reuses existing conversion capability instead of requiring a custom renderer. Check the chosen version's environment, browser dependencies, fonts and options before adopting it. This article has not installed or executed the tool. Producing source text is not evidence that rendering succeeded, and internal topology should not be uploaded to a public editor without authorization.
Worked example: make the duplicate-reading problem visible
Suppose the gateway retains events A, B and C. After connectivity returns, the acknowledgment for A is lost. If the gateway sends A again, how should the receiver determine whether it is the same reading? “Automatic deduplication” is not a sufficient specification. Record candidate event identity, retention period, resend conditions and exception handling for the engineering review to decide.
Ask the agent to produce a sequence table covering measurement, local retention, sending, acknowledgment and cleanup before drawing a detailed sequence diagram. For each step ask what state remains after failure. Persistence before a power loss, capacity exhaustion and device clock changes belong in the issue list. Draw detailed behavior only once the relevant rules have been agreed; do not fill gaps with guesses.
A bounded request is: “Use only architecture-notes.md and approved-summary.csv. Draft the current structure, proposed offline flow and unresolved questions. Give nodes source identifiers and separate current behavior from proposals. Include lost acknowledgments, repeated sends and capacity exhaustion. Return editable diagram source and a rendering plan. Do not connect to devices, change production settings or claim experiments have run.” Accept relationships first, rendering second and readability on the actual slide third.
Scenario two: build a complete review narrative around evidence
Use a title that states the page's point, such as “Retries need an explicit acknowledgment contract,” rather than only “Technical architecture.” Compare options using benefit, cost, dependencies and unvalidated assumptions. Diagrams explain mechanisms; measurements support observations. A structure drawing cannot demonstrate lower latency, and a runtime summary cannot prove every exceptional condition has been covered.
When the input includes authorized sanitized local CSV, TSV or JSON runtime records, Exploratory Data Analysis fits the data-quality checkpoint. Use it for missing fields, duplicate candidates, time coverage and distributions. Specify the permitted local data root and output directory, and provide the relevant Python environment and dependencies. Its role is a bounded exploratory report, not workbook modification, slide production or proof that the proposed architecture improves reliability.
Every measurement page needs a sample window, counting unit, missing-data explanation, selection rule and metric definition. Distinguish log records, unique events and devices. Repeated logs may not represent repeated readings. Keep environments separate, and do not combine synthetic and production observations into an unexplained single metric. A number copied into a slide should be traceable to the approved input and its calculation notes.
For an entire deck, approve the page outline and then generate samples of the densest page and the architecture page. Check charts, long titles, source text and speaker notes before expanding the rest. When a template has insufficient capacity, split the content or move detail to an appendix; never silently truncate it. Keep the editable deck, diagram source, outline, data summary and page-to-input coverage list together. Identify which diagram objects are images and which can be edited directly in the presentation software.
Scenario three: define a visual system and inspect every page
Agree on heading levels, content areas, spacing, color meanings and legends. Distinguish current components, proposed components and uncertain relationships with labels, borders and line styles as well as color. Prioritize legible arrows and labels in technical diagrams. A fixed text-to-image ratio is not a universal design rule: a complex mechanism may deserve its own page with a short explanation elsewhere.
Canvas Design is an optional fit for an original static PNG or PDF visual reference when the team needs to establish hierarchy, space and color direction. Provide dimensions, intended use and approved assets, with an agent capable of creating and inspecting files. Review fonts and bundled resource licenses. It is not an architecture validator, a PPTX editor or an automatic deck-polishing service; apply it only to the static reference step and implement the resulting rules through the presentation workflow.
Open each page in the actual destination application. Check missing glyphs, font substitution, connectors crossing text, overlaps, blurred screenshots, cropping and links. Inspect at normal presentation size and then review a PDF export. Changing a master or font can make previously fitting labels overflow, so inspect the content again after styling. Record untested Office, WPS or Keynote versions as pending instead of claiming universal consistency.
An image-based backup can stabilize some presentation behavior but sacrifices object editing, text search and parts of accessibility. Keep it separate from the editable master. The acceptance record names the actual files, pages and application versions inspected, together with issues and corrections. Export success, content acceptance, visual acceptance and editability are distinct outcomes.
FAQ and maintenance
How long will this take? Input completeness, diagram complexity and the destination environment determine the work; there is no general three-minute guarantee. Can a backend engineer without design experience do it? Component tables and page-level plans lower the barrier, while a responsible reviewer still confirms system facts and decisions. Can one tool draw architecture and business processes? A tool may support both, but select a view according to whether the question concerns structure, sequence or state.
Are all listed skills security reviewed? Directory presence and download figures cannot establish that. Check repository, fixed version, license, dependencies and actual file or network permissions. Do not invent installation links for source-article names without a verified matching record. As the catalog grows, compare candidates on the same sanitized greenhouse fixture, associate them with the step they actually support and record replacement reasons and dates.
Why can a beautiful diagram fail review? Check whether it answers the lost-acknowledgment, duplicate-event and capacity questions. Why did the measurements improve after polishing? Check whether exceptions were removed or the denominator changed. Preserve the original summary separately from derived results. The deliverable is a traceable proposal and a list of checks still required, allowing the team to choose its next step without disguising an unrun design as a finished system.