An architecture for trustworthy generation and validation

8.1

Four layers and a stable intermediate representation

The proposed architecture separates sources, semantics, presentation, and validation. The source layer stores origin, dates, access scope, and versions. The semantic layer contains confirmed concepts, relationships, rules, and variables. The presentation layer controls layout, notation, language, and export format. The validation layer checks source correspondence, structural constraints, calculations, and readability. One system or several tools may implement these layers. The essential requirement is logical separation so that an error can be repaired at the appropriate level.

A changed hotel policy is a source update. Adding human confirmation is a semantic revision. Translating labels is a presentation revision. Discovering that an authorization branch cannot rejoin the process is a validation finding. If all changes occur directly in a final image, consistency becomes difficult. With an intermediate representation, one conceptual correction can propagate into slides, manuals, assignments, and English figures while preserving its history.

Uncertainty should also be represented. A relationship may be source-supported, instructor-confirmed, model-proposed, or awaiting verification. A number may be observed, estimated, or synthetic. These states determine whether publication is allowed, whether a note is required, and whether human review is triggered. Trust management then becomes part of generation rather than a final reviewer having to remember everything.

8.2

Four distinct forms of validation

Four kinds of validation address different questions. Syntax checks whether code parses, identifiers are unique, and output files are complete. Structure checks for disconnected nodes, unreachable states, missing branch conditions, and uncontrolled loops. Semantics checks whether a relationship matches its source, an action belongs to a role, and terminology remains aligned across languages. Empirical and consequence-oriented validation asks whether assumptions fit operating conditions and whether a small trial achieves its objective. Passing one level does not automatically pass the next.

The same distinction applies to charts. Successful execution establishes that code ran. A readable layout establishes that elements can be seen. Correct data mapping supports numerical interpretation. A real operating trial is needed to assess action effects. AI can assist several checks, but self-review may repeat the original misconception. Important facts, calculations, and permissions should use independent rules, primary sources, or human review where possible. Repeated approval by the same model is not independent evidence.

A short record can accompany each important graphic: sources checked, relationships confirmed, calculations executed, and limitations stated. The record should permit an untested state. A synthetic revenue curve may pass computational validation while its empirical applicability remains untested. Stating this explicitly is more informative than assigning the entire figure a single green approval symbol.

8.3

Linking evidence to graphical elements

Traceability should reach important nodes and edges rather than stop at a bibliography. A policy decision can link to its clause, a bar to the filtered records that produced it, and an evidence graphic to the reported estimate. Decorative elements do not all need citations, but facts, numbers, and rules that affect judgment should be locatable. AI-generated explanation should be recorded separately from source statements so that plausible inference does not become a disguised quotation.

A simple system combines source and element identifiers. A clause in source S03 supports node N12; transformation T02 produces series B in figure F06. Chinese and English labels share N12 rather than maintain separate factual copies. Traceability need not expose sensitive data. A reader can receive a controlled description and access conditions. In education, de-identified or simulated records can support the exercise without requiring real guest information.

Time is part of evidence. An answer may accurately quote an old policy and still be wrong for the current situation. Effective dates and versions matter alongside upload dates. Search material needs retrieval information, computations need parameter and execution versions, and human judgments need a responsible person and reason. These records explain why a diagram that was correct last week may require revision now.

8.4

Permissions and failure paths

Failure paths belong in both classroom and business systems. Missing evidence, tool errors, permission conflicts, uncertainty, and changed objectives are ordinary operating conditions. A workflow should specify when to stop, ask, retry, or escalate. Retries need limits so that automation does not continue consuming resources without new information. External messages, refunds, price changes, and deletion need authorization proportionate to their consequences.

NIST's generative-AI risk framework provides a general reference for identifying, measuring, and managing risks.[30] Here it informs practical design requirements: visible permission boundaries, traceable consequential actions, exits from exceptional states, and identifiable responsibility. These are educational and engineering recommendations. A particular diagram format does not itself establish regulatory or organizational compliance; deployment needs local requirements to be checked.