Architecture Review Control Tower

Source Before Agent

Building a defensible Enterprise Architecture Assistant

The agent is the interface. Governed context is the authority.

An Enterprise Architecture Assistant should not begin as a chatbot with access to every document it can find. It should begin as a governed decision-support system that knows which sources are authoritative, which sources are provisional, which sources are discovery-only, and which decisions remain human-owned.

The model can retrieve. Only governed context can authorize.
Provenance

Where this comes from

Source Before Agent is a SharePlane teaching artifact written from Tony Malott’s public-safe enterprise architecture practice and supported by public governance sources. It generalizes a hands-on pattern: before an AI assistant can help with architecture review, the organization must decide which sources it is allowed to trust.

The public sources provide governance signals, caveats, and risk framing. The assistant architecture is SharePlane interpretation, not a mandate from any cited source.

This artifact does not disclose employer materials, client materials, internal documents, real submissions, controlled screenshots, local paths, or operational traces.

Hands-on architecture practice Public governance sources SharePlane interpretation
Article opening

Before the model, decide what counts as authority

Enterprise architecture review is not slow only because reviewers are busy. It is slow because the decision context is scattered. Standards live in one place, exceptions in another, platform guidance in another, prior decisions in another, and the newest explanation often arrives as a deck, chat thread, or email. A model can search across that mess, but search does not turn mess into authority.

That distinction matters. An assistant that retrieves a relevant document may still be wrong for the decision if the source is draft, stale, unofficial, superseded, unowned, or contradicted by a stronger authority. The problem is not simply hallucination. The problem is allowing an assistant to reason from material whose decision status has never been established.

Source Before Agent starts with a simple constraint: the first deliverable is not a chatbot. The first deliverable is a source authority model.

A good assistant can summarize, classify, compare, draft, and route. None of that matters if the assistant is reasoning from uncontrolled source material. Architecture review is not just a knowledge-retrieval problem. It is a decision-governance problem.

Problem

Decision context is scattered across standards, exceptions, platform guidance, prior decisions, decks, chat threads, and email.

Mistake

Letting broad retrieval turn uncontrolled material into apparent decision authority.

Correct move

Build the source authority model before building the assistant interface.

Bottleneck

The deeper bottleneck is unmanaged decision context.

Command summary

Executive TLDR

Large enterprises receive more AI and technology solution requests than architecture teams can review at the speed the business wants. That pressure makes an assistant attractive. The mistake is assuming the assistant should begin with broad document access.

The correct move is to build the source authority model first.

The assistant should normalize intake, detect missing information, classify risk, select approved source packs, compare the request against governed authority, flag conflicts and exceptions, and draft an evidence-backed review brief.

It should not approve architecture decisions. It should not infer policy from loose documents. It should not treat search results as authority. It should not promote drafts, decks, email, chat, or informal updates into decision-grade guidance without owner validation.

Search can find related material. Governance decides what can be trusted.

Practical explanation

Why search alone fails architecture review

Search is useful for discovery. It is dangerous as authority. In a real review flow, the assistant is not only trying to answer a question. It is helping prepare a decision that may involve security, privacy, regulatory, platform, procurement, data, integration, or operational consequences.

That means every retrieved source needs a status. Who owns it? Is it current? Was it approved? Has it been superseded? Does it describe policy, reference architecture, implementation advice, or just someone’s latest explanation? Without those answers, a citation can create false confidence instead of defensible evidence.

The point is not to make the assistant timid. The point is to make it useful without letting it launder informal material into decision authority.

When an assistant has broad access but no authority model, it can sound more confident than the evidence allows. It may cite an old implementation deck as if it were current policy. It may treat a platform FAQ as an architecture standard. It may quote a chat thread as though it were an approved exception. It may collapse competing sources into one smooth answer and hide the conflict from the reviewer.

That is worse than a slow review. A slow review can still be corrected. A confident weak decision can spread.

Teaching use case

Teaching use case: too many requests, too little governed context

Consider a public-safe teaching case: a large regulated enterprise receives a growing number of AI and technology solution submissions. Some are AI assistants. Some are SaaS tools. Some are automation proposals. Some involve data integration. Some come from vendors. Some may affect regulated, sensitive, or operationally important environments.

The architecture team wants to move faster. The business wants answers. Reviewers need help turning messy submissions into complete, comparable review packets.

An assistant can help, but only if it is grounded in governed context. The assistant must know which policies constrain the answer, which architecture standards define approved direction, which prior decisions create precedent, which implementation notes are merely helpful, and which informal materials are discovery-only.

Without that control layer, the assistant is not accelerating architecture review. It is accelerating uncertainty.

Inbound request stream
AI assistantSaaSAutomationData integrationVendor toolRegulated impact
Unsafe vs defensible path

Access is not authority

The unsafe shortcut is tempting:

Broad search. Mixed documents. Confident answer. Weak decision.

The defensible path is slower to design but stronger to operate:

Source register. Authority tiers. Evidence brief. Human gate. Decision record.

The difference is not cosmetic. The first path treats the enterprise knowledge landscape as a flat pile of documents. The second path treats it as a governed decision environment.

A flat pile of documents is fine for exploration. It is not enough for accountable review. A defensible assistant needs to know whether it is looking at a hard constraint, approved direction, historical precedent, implementation guidance, or discovery-only material.

The more powerful the assistant becomes, the more important that distinction becomes. Weak source control plus strong generation is not intelligence. It is industrialized overconfidence.

Unsafe shortcut

Broad searchMixed documentsConfident answerWeak decision

Defensible path

Source registerAuthority tiersEvidence briefHuman gateDecision record
Authority stack

The source authority model

The source authority model defines what the assistant is allowed to trust and how strongly it may use each source.

This model is not a document inventory. It is a decision-control layer. It tells the assistant which material can support a decision, which material can only support a caveated recommendation, which material can only be used as background, and which material must be blocked until a human resolves the conflict.

The model should use tiers.

Tier 0: Mandatory governance authority

These sources define hard constraints. They may include AI policy, security policy, privacy and data-classification policy, quality or regulatory policy, legal requirements, records policy, procurement rules, and other mandatory governance sources. If a Tier 0 source applies, lower-tier material cannot override it.

Tier 1: Enterprise architecture authority

These sources define approved direction. They may include EA principles, reference architectures, approved platform standards, approved AI patterns, cloud standards, integration standards, identity and access standards, data standards, observability standards, and the technology catalog.

Tier 2: Prior decisions and exceptions

These sources preserve precedent. They include architecture review decisions, approved exceptions, lifecycle decisions, risk acceptances, pattern approvals, and roadmap decisions. They help the assistant identify consistency, drift, and exception boundaries.

Tier 3: Implementation guidance

These sources help teams implement approved direction. They may include engineering playbooks, platform guides, FAQs, training material, vendor implementation references, and practical notes. They can inform the review, but they do not override policy or architecture authority.

Tier 4: Discovery only

These sources may point to useful information, but they do not independently support an architecture decision. This includes email, chat, meeting notes, informal updates, draft decks, unowned pages, and “latest guidance” attachments with no official home.

Useful evidence, but not independent decision authority.

Tier 0

Tier 0: Mandatory governance authority

Hard constraints and mandatory governance authority.

Tier 1

Tier 1: Enterprise architecture authority

Approved platform standards, reference architectures, patterns, and catalogs.

Tier 2

Tier 2: Prior decisions and exceptions

Precedent, decision consistency, and exception boundaries.

Tier 3

Tier 3: Implementation guidance

Supporting implementation context that does not override authority.

Tier 4

Tier 4: Discovery only

Useful evidence, but not independent decision authority.

Quarantine bay

The platform documentation failure mode

The hardest cases are not always caused by bad documentation. Sometimes the problem is almost the opposite: too much documentation, but no clear authority.

A platform team may have a polished deck, a useful FAQ, a few internal posts, several chat threads, a roadmap slide, and a training page. Everyone may “know” the direction. The assistant may retrieve all of it. But if none of those materials are owned, approved, versioned, or marked as authoritative, the assistant still cannot treat them as decision-grade.

This is a common failure mode in large organizations. The platform is real. The guidance is real. The people are knowledgeable. But the decision authority is not explicit.

The answer is not to ignore those materials. The answer is to quarantine them until they are validated.

If platform teams lack canonical documentation, EA needs a compensating source-control layer until formal docs exist. That layer can identify the likely owner, mark the material as provisional, capture caveats, and prevent informal material from silently becoming architecture policy.

Control plane rail

Context-as-code is the control plane

The source authority model should not live as a tribal rule in someone’s head. It needs to become an operating layer: a source register, source packs, intake schema, review workflow, decision rules, claim ledger, decision records, and evaluations. That is the context-as-code control plane.

This does not mean every document becomes equally trusted. It means every source gets a role. Some sources constrain decisions. Some inform implementation. Some support discovery only. Some are blocked until an owner resolves a conflict. The assistant can then prepare a review brief with visible evidence boundaries instead of pretending every retrieved document has the same weight.

The context layer is managed like a product, not treated like background noise.

The source register says what exists. Source packs say what applies to a class of request. The intake schema says what information must be present before review can proceed. Decision rules say how conflicts are handled. The claim ledger records what the assistant is allowed to say and what evidence supports it. Decision records preserve the human outcome. Evaluations test whether the assistant is still preparing useful, accurate, caveated review briefs.

This is the work that makes the assistant defensible.

Source register

Versioned source inventory and source authority tiers.

Source packs

Eligible decision-support sources for review domains.

Intake schema

Required fields, completeness checks, and risk-domain classification.

Review workflow

Controlled path from submission through human decision.

Decision rules

Rules for what the assistant may cite, compare, or recommend.

Claim ledger

Traceable posture for public-source facts, interpretation, and caveats.

Decision records

Captured rationale and approved decision knowledge.

Evaluations

Tests that monitor drift and review-brief usefulness.

Runway clearance sequence

What the assistant actually does

The assistant’s job is to normalize the submission, identify missing information, classify the request, select the right source packs, compare the request against approved authority, flag conflicts or exceptions, and draft an evidence-backed review brief.

That is valuable work. It reduces review preparation burden and makes the human review more consistent. But it is not approval. Architecture, security, privacy, quality, regulatory, legal, procurement, and platform decisions remain accountable human decisions.

A defensible assistant makes the human decision easier to inspect. It does not make the human disappear.

A good review brief should show what was submitted, what is missing, which review domains apply, which source packs were used, what the strongest applicable sources say, where the request aligns, where it conflicts, what exceptions may be needed, which caveats matter, and what the human reviewer must decide.

The assistant prepares. Humans decide.

Submission arrives
Normalize intake
Check completeness
Classify request
Select source packs
Compare against authority
Flag risk and exceptions
Draft evidence brief
Human decision
Decision record
Decision boundary

What the assistant must not do

The assistant must not approve architecture decisions. It must not approve security, privacy, quality, legal, procurement, regulatory, or platform decisions. It must not promote informal material into authority. It must not silently resolve source conflicts. It must not treat the most recent source as the strongest source. It must not infer policy from implementation guidance. It must not hide caveats to sound more confident.

It also must not mutate the source layer directly. If a source needs to be promoted, corrected, retired, or reclassified, that should go through source ownership and governance. The assistant can recommend that a source needs review. It should not rewrite the authority model on its own.

The safest assistant is not the one that refuses everything. The safest assistant is the one that knows the boundary between preparation and decision.

Include / Exclude gate

MVP boundary

The first useful version should be narrow.

It should support AI and AI-adjacent solution submissions. It should use a standard intake schema, a completeness checker, a risk-domain classifier, a source authority register, initial source packs, an evidence-backed review brief, a human architecture gate, decision record capture, and a pilot evaluation set.

It should not attempt autonomous approval. It should not crawl the enterprise as decision authority. It should not ingest unrestricted documents. It should not classify regulatory impact by itself. It should not automate security, privacy, quality, legal, procurement, or platform approvals. It should not silently promote sources. It should not mutate the source layer directly.

The MVP should prove that governed context improves review preparation before anyone expands the assistant’s authority.

MVP includes

  • AI and AI-adjacent solution submissions
  • Standard intake schema
  • Completeness checker
  • Risk-domain classifier
  • Source authority register
  • Initial source packs
  • Evidence-backed review brief
  • Human architecture gate
  • Decision record capture
  • Pilot evaluation set

MVP excludes

  • Autonomous approval
  • Broad crawling as decision authority
  • Unrestricted document ingestion
  • Regulatory classification by agent alone
  • Security/privacy/quality/legal/procurement approval automation
  • Silent source promotion
  • Direct source mutation by assistant
Signal rail

How success should be measured

The assistant is successful only if it improves review preparation without weakening accountability.

Measure whether submissions are more complete before human review. Measure whether review preparation takes less time. Measure whether citations are present and relevant. Measure whether caveats are visible. Measure whether source conflicts are detected. Measure whether exceptions are routed correctly. Measure whether prior decisions are reused consistently. Measure whether reviewers trust the brief enough to use it, challenge it, and improve it.

Do not measure success only by answer speed. A fast answer from weak authority is not progress. It is just failure with better latency.

Completeness

Submissions are more complete before human review.

Preparation time

Review preparation takes less time.

Citations

Citations are present and relevant.

Caveats

Caveats remain visible.

Conflicts

Source conflicts are detected.

Exceptions

Exceptions are routed correctly.

Reviewer trust

Reviewers can use, challenge, and improve the brief.

Guardrail board

Risks and controls

The biggest risk is overtrust. A polished assistant can make weak evidence look strong. That risk is controlled by source eligibility rules, citation requirements, visible caveats, and a hard human gate.

Another risk is stale guidance. That is controlled by source ownership, freshness metadata, review dates, and retirement rules.

Another risk is hidden approval automation. That is controlled by explicit decision boundaries and workflow language that keeps the assistant in the preparation role.

Another risk is unresolved source conflict. That is controlled by stop/report behavior and owner resolution.

Another risk is source sprawl. That is controlled by source packs, not one giant pile of documents.

The control pattern is simple: the assistant may accelerate preparation, but it cannot bypass authority.

Risk: overtrust

Control: source eligibility rules, citation requirements, visible caveats, and a hard human gate.

Risk: stale guidance

Control: source ownership, freshness metadata, review dates, and retirement rules.

Risk: hidden approval automation

Control: explicit decision boundaries and preparation-role workflow language.

Risk: unresolved source conflict

Control: stop/report behavior and owner resolution.

Risk: source sprawl

Control: source packs instead of one giant pile of documents.

Evidence spine

Evidence spine: public sources, claim posture, and caveats

The public sources support the governance frame. The assistant architecture remains SharePlane interpretation.

The sources below are not a claim that any regulator, standards body, or public agency requires this exact assistant architecture. They support the risk-management frame: AI risk is contextual, governance obligations are becoming more operational, regulated uses require credibility and lifecycle thinking, and cybersecurity remains part of enterprise review. Source Before Agent is the SharePlane interpretation of what those signals imply for architecture assistant design.

The evidence spine should keep claim posture visible. A public source can support a general governance fact. It can signal current regulatory direction. It can provide a regulated-context side rail. It can support cybersecurity governance. But the architecture pattern itself remains interpretation.

Public-source-supported fact: AI risk management requires attention to design, development, use, evaluation, and context.

Governance signal: AI governance expectations are becoming more operational, especially around transparency, accountability, safety, and security.

Regulated-context side rail: AI used in life-sciences-style contexts may require lifecycle thinking, documentation, credibility, safety, and effectiveness considerations.

Cybersecurity side rail: Enterprise technology review still needs cybersecurity risk governance.

SharePlane interpretation: An architecture assistant should be built on source authority before automation.

Explicit non-claim: No listed source requires this exact assistant architecture.

Public-source-supported fact

Official public sources support specific governance, risk, lifecycle, or cybersecurity framing.

Governance signal

Current public materials show direction of travel without becoming local operating rules.

Regulated-context side rail

FDA draft guidance informs risk thinking only where context makes it relevant.

Cybersecurity side rail

NIST CSF supports the enterprise-risk frame without becoming AI-specific authority.

SharePlane interpretation

The source-before-agent architecture is an applied teaching pattern, not a public-source mandate.

Explicit non-claim

No listed source requires this exact assistant architecture.

Source
NIST AI Risk Management Framework current page
Role
Baseline AI risk-management frame.
Supports
AI risk management vocabulary and current NIST posture.
Caveat
Use as governance frame, not as a mandate for this exact assistant architecture.
Source
International AI Safety Report 2026
Role
Current risk synthesis for general-purpose AI.
Supports
The claim that AI capabilities, risks, and mitigations are evolving.
Caveat
Not an enterprise architecture standard.
No listed source requires this exact assistant architecture. Source Before Agent is SharePlane interpretation applied to public governance signals.
Visual prompt suite

Visual prompt suite

The visual prompt suite is not an assistant-operation prompt library. It is a controlled visual reproduction kit for creating teaching graphics that match the artifact.

Prompt groups must be collapsed by default. Each group must include two variants: mainline white and dark expressive. Each prompt body must preserve purpose, core thesis, conflict, mechanism, visual metaphor, required visible text, style, density, footer, prohibited elements, and accessibility alt-text concept.

Prompt group

Prompt 1: Source Before Agent

A: mainline white. B: dark expressive.

A: mainline white

Teaching graphic.

Create a premium 16:9 white-background enterprise teaching graphic titled `Source Before Agent`.

Purpose: Show why an Enterprise Architecture Assistant must be built on governed source authority before it is allowed to accelerate review work.

Core thesis: The agent is the interface. Governed context is the authority.

Conflict: A model can retrieve related documents, but related does not mean authoritative, current, approved, or decision-grade.

Mechanism: Show inbound solution requests entering an architecture review control tower. Requests pass through a source authority control plane before an EA assistant prepares an evidence brief. A human architecture gate owns the decision, and a decision record exits on the right.

Visual metaphor: Architecture review control tower with governed context at the center. The source authority model is the radar, rules, clearance map, and runway protocol. The assistant is the operator console. The human gate is the clearance authority.

Required visible text: `Source Before Agent`; `Inbound requests`; `Source authority control plane`; `EA assistant console`; `Human architecture gate`; `Decision record`; `The model can retrieve. Only governed context can authorize.`

Style: Premium editorial enterprise architecture diagram. Warm white background, graphite typography, deep navy structural panels, slate secondary surfaces, restrained red authority accents, crisp lines, strong spacing, serious governance tone.

Density: Medium-high but clean. Every element must explain the control system.

Footer: `Teaching use case: defensible architecture review assistant`.

Prohibited: Do not show robots, glowing brains, magic sparkles, random neural webs, generic SaaS dashboards, vendor UI, fake chat bubbles, prompt metadata labels, or decorative AI wallpaper.

Accessibility alt-text concept: Layered control-tower diagram showing inbound architecture requests passing through governed source authority before an assistant prepares evidence for a human decision.

B: dark expressive

Technical graphic.

Create a premium 16:9 dark graphite technical graphic titled `Source Before Agent`.

Purpose: Show source authority as the control system behind a defensible EA assistant.

Core thesis: The assistant is the interface. Governed context is the authority.

Conflict: Search can retrieve documents, but retrieval does not prove that a source is authoritative.

Mechanism: Show controlled signal paths flowing from a source register and authority tiers into an EA assistant console, then upward to a human decision gate and outward to a decision record.

Visual metaphor: Night-mode architecture control tower. Dark cockpit surface, source rails, radar-like authority sweep, quarantined discovery-only material, and a bright human gate above the assistant console.

Required visible text: `Source Before Agent`; `Source register`; `Authority tiers`; `Evidence brief`; `Human gate`; `Decision record`; `Search is not authority.`

Style: Dark graphite operating-console style. Deep navy and charcoal surfaces, red authority lines, muted gray discovery rails, high-contrast white labels, disciplined spacing, premium evidence-control aesthetic.

Density: Medium-high. It should feel like a serious control system, not a decorative dashboard.

Footer: `Only governed context can authorize.`

Prohibited: Do not show robot judges, neon sludge, code rain, cyberpunk decoration, magic AI oracles, unbounded network graphs, or prompt metadata labels.

Accessibility alt-text concept: Dark control-console diagram showing source authority rails feeding an EA assistant console and human decision gate.
Prompt group

Prompt 2: Related Is Not Authoritative

A: mainline white. B: dark expressive.

A: mainline white

Source-state matrix.

Create a premium 16:9 white-background teaching graphic titled `Related Is Not Authoritative`.

Purpose: Teach that source state determines whether an assistant may use material for decision support.

Core thesis: A source can be useful without being decision-grade.

Conflict: Architecture assistants can find related decks, emails, chats, and draft pages, but those sources may not be owned, current, approved, or controlled.

Mechanism: Show a source-state clearance matrix mapping source states to permitted assistant use.

Visual metaphor: Authority clearance board. Five horizontal bands move from trusted decision support at the top to blocked material at the bottom. Each band has a source state, assistant use, and visible status.

Required visible text: `Related Is Not Authoritative`; `Controlled, owned, current, approved -> Decision support`; `Owned and current, not controlled -> Conditional support`; `Owner or version unclear -> Reference only`; `Email, chat, deck, informal note -> Discovery only`; `Conflicting, stale, superseded -> Blocked`; `Useful does not mean decision-grade.`

Style: Premium governance worksheet style. Warm white background, graphite text, crisp rows, subtle authority gradient, restrained red for blocked state, muted slate for discovery, strong spacing.

Density: Medium. The matrix must be readable at presentation scale.

Footer: `Source state determines assistant use.`

Prohibited: Do not use generic compliance clipart, robots, magic document clouds, neural networks, tiny unreadable table text, or prompt metadata labels.

Accessibility alt-text concept: Decision matrix showing five source states and the assistant use allowed for each state, from decision support to blocked.

B: dark expressive

Quarantine console.

Create a premium 16:9 dark technical graphic titled `Retrieval is not authority`.

Purpose: Show how unclear or uncontrolled sources must be quarantined before they influence architecture decisions.

Core thesis: Retrieval is not authority.

Conflict: The assistant may find relevant material, but uncontrolled or stale material can weaken architecture decisions.

Mechanism: Show a dark control panel with five source-state channels. Trusted channels are bright and stable. Discovery-only material is muted and quarantined. Blocked sources are red and disconnected.

Visual metaphor: Source quarantine console. Decision-grade sources flow into the assistant. Discovery-only sources sit in a side quarantine bay. Blocked sources are isolated.

Required visible text: `Retrieval is not authority`; `Decision support`; `Conditional`; `Reference only`; `Discovery only`; `Blocked`; `Quarantine unclear sources.`

Style: Dark graphite console, navy-black panels, controlled red blockers, muted gray quarantined sources, crisp white typography, evidence-control mood.

Density: Medium. Make source-state separation visually obvious.

Footer: `Unclear authority must not drive decisions.`

Prohibited: Do not show generic cyber dashboards, decorative locks, random glowing files, AI robot figures, or prompt metadata labels.

Accessibility alt-text concept: Dark source-state console showing trusted, conditional, reference, discovery-only, and blocked source channels.
Prompt group

Prompt 3: From Submission to Evidence Brief

A: mainline white. B: dark expressive.

A: mainline white

Runway sequence.

Create a premium 16:9 white-background enterprise process graphic titled `From Submission to Evidence Brief`.

Purpose: Show how an EA assistant accelerates review preparation without taking over decision authority.

Core thesis: The assistant prepares the review. Humans own the decision.

Conflict: High-volume AI and technology submissions overwhelm reviewers, but autonomous approval is unsafe.

Mechanism: Show a controlled workflow from submitted request to evidence-backed review brief, human decision, and decision record update.

Visual metaphor: Runway clearance sequence. Each request moves through gates: normalize, completeness, classify, source packs, compare authority, flag risk, draft brief, human decision, decision record.

Required visible text: `From Submission to Evidence Brief`; `Normalize intake`; `Check completeness`; `Classify request`; `Select source packs`; `Compare against authority`; `Flag risk`; `Draft review brief`; `Human decision`; `Decision record`; `The assistant prepares. Humans decide.`

Style: Premium enterprise process map. Warm white background, graphite labels, slate process blocks, navy authority lane, restrained red risk flags, clean arrows, high clarity.

Density: Medium-high. Show the full workflow without crowding.

Footer: `Decision support, not autonomous approval.`

Prohibited: Do not show rubber stamps, autonomous approval, robot judges, magic automation, busy dashboard wallpaper, or prompt metadata labels.

Accessibility alt-text concept: Process map showing a solution request moving through assistant-supported review preparation before human decision and decision-record capture.

B: dark expressive

Evidence flow.

Create a premium 16:9 dark operating-console graphic titled `Evidence-backed review flow`.

Purpose: Show review acceleration as controlled evidence flow.

Core thesis: Faster review requires controlled evidence flow, not unrestricted document search.

Conflict: A confident assistant output is dangerous if it skips source authority, risk flags, and human review.

Mechanism: Show a dark evidence conveyor with gates for intake, completeness, classification, source authority, risk, review brief, human gate, and decision record.

Visual metaphor: Night runway / control tower clearance path with red risk beacons and navy authority gates.

Required visible text: `Evidence-backed review flow`; `Intake`; `Completeness`; `Classification`; `Source packs`; `Authority check`; `Risk flags`; `Review brief`; `Human gate`; `Decision record`.

Style: Dark graphite and deep navy, thin red gate lines, bright white labels, controlled aviation/control-tower feel, premium technical polish.

Density: Medium-high. The flow must remain readable.

Footer: `The assistant prepares. Humans decide.`

Prohibited: Do not show robot approvals, sci-fi holograms, random neon, code rain, generic UI mockups, or prompt metadata labels.

Accessibility alt-text concept: Dark workflow diagram showing assistant preparation steps ending at a human decision gate and decision record.
Prompt group

Prompt 4: Evidence Spine

A: mainline white. B: dark expressive.

A: mainline white

Source dossier rail.

Create a premium 16:9 white-background teaching graphic titled `Evidence spine`.

Purpose: Show how public sources, claim posture, and caveats stay connected.

Core thesis: Public sources support the governance frame. The assistant architecture is SharePlane interpretation.

Conflict: Readers may mistake source citations for proof that the exact architecture is mandated by external standards.

Mechanism: Show a central evidence spine with source cards connected to claim posture labels: public fact, governance signal, side rail, SharePlane interpretation, explicit non-claim.

Visual metaphor: Evidence spine / source dossier rail. Sources attach to claims through labeled connectors. Caveats sit beside each source, not hidden at the bottom.

Required visible text: `Evidence spine`; `Public-source-supported fact`; `Governance signal`; `Regulated-context side rail`; `Cybersecurity side rail`; `SharePlane interpretation`; `Explicit non-claim`; `Sources support the frame. They do not mandate the architecture.`

Style: Premium editorial source dossier. Warm white background, graphite text, navy evidence spine, slate source cards, red caveat markers, spacious layout.

Density: Medium. Prioritize clarity over exhaustive detail.

Footer: `Claim posture stays visible.`

Prohibited: Do not show citation confetti, academic paper piles, legal scales, generic compliance icons, tiny unreadable source tables, or prompt metadata labels.

Accessibility alt-text concept: Source dossier diagram showing public sources connected to claim posture labels, with caveats visible beside each source.

B: dark expressive

Evidence control board.

Create a premium 16:9 dark source-governance graphic titled `Evidence spine`.

Purpose: Show evidence as a governed control board, not a loose bibliography.

Core thesis: Evidence is only useful when claim posture and caveats stay attached.

Conflict: Source lists can create false confidence if they do not show what each source actually supports.

Mechanism: Show a dark evidence spine with source nodes, claim labels, caveat tags, and a separate SharePlane interpretation lane.

Visual metaphor: Evidence control board with source nodes connected through governed claim rails.

Required visible text: `Evidence spine`; `Source`; `Claim posture`; `Caveat`; `SharePlane interpretation`; `No source mandates this architecture.`

Style: Dark graphite evidence board, deep navy panels, red caveat tags, muted gray non-claims, crisp typography.

Density: Medium. Make relationships obvious.

Footer: `Citations support claims, not vibes.`

Prohibited: Do not show generic legal graphics, abstract glowing networks, robot auditors, decorative dashboards, or prompt metadata labels.

Accessibility alt-text concept: Dark evidence board linking sources to claim posture and caveats, with SharePlane interpretation kept separate.
Prompt group

Prompt 5: Do Not Automate Architecture Without Authority

A: mainline white. B: dark expressive.

A: mainline white

Capstone comparison.

Create a premium 16:9 white-background capstone graphic titled `Do Not Automate Architecture Without Authority`.

Purpose: Contrast unsafe automation with a governed architecture review path.

Core thesis: A defensible architecture assistant starts with governed source authority, not document access.

Conflict: Broad search can produce confident answers from mixed-quality sources.

Mechanism: Compare unsafe shortcut versus defensible path.

Visual metaphor: Two-path architecture decision map. The unsafe shortcut is unstable and fragmented. The defensible path is structured and governed.

Required visible text: `Do Not Automate Architecture Without Authority`; `Unsafe shortcut`; `Broad search`; `Mixed documents`; `Confident answer`; `Weak decision`; `Defensible path`; `Source register`; `Authority tiers`; `Evidence brief`; `Human gate`; `Decision record`; `Source before agent.`

Style: Premium editorial comparison graphic. Warm white background, graphite structure, controlled red warning accents on the unsafe path, calm navy and slate stability on the defensible path.

Density: Medium-high. The contrast between paths must be obvious.

Footer: `The agent is the interface. Governed context is the authority.`

Prohibited: Do not show robots, magic AI brains, vendor UI, random neural networks, neon dashboards, clipart, or prompt metadata labels.

Accessibility alt-text concept: Two-path diagram comparing unsafe broad search with a defensible path through source register, authority tiers, evidence brief, human gate, and decision record.

B: dark expressive

Control-room map.

Create a premium 16:9 dark capstone graphic titled `Do Not Automate Architecture Without Authority`.

Purpose: Show that speed without governed source authority can industrialize weak architecture decisions.

Core thesis: Authority must be mapped before automation accelerates architecture review.

Conflict: Speed without source control can industrialize weak decisions.

Mechanism: Show the unsafe shortcut collapsing into a red weak-decision zone while the defensible path moves through governed gates toward a stable decision record.

Visual metaphor: Dark control-room decision map with red unsafe bypass and blue governed clearance path.

Required visible text: `Do Not Automate Architecture Without Authority`; `Unsafe bypass`; `Governed path`; `Source authority`; `Evidence brief`; `Human gate`; `Decision record`; `Speed without authority weakens review.`

Style: Dark graphite command-center aesthetic, deep navy governed path, restrained red unsafe bypass, clean labels, premium enterprise control tone.

Density: Medium-high. Strong visual contrast, no clutter.

Footer: `Source before agent.`

Prohibited: Do not show sci-fi AI, robot judges, glowing brains, random neon, cyberpunk cityscapes, fake SaaS dashboards, or prompt metadata labels.

Accessibility alt-text concept: Dark decision map showing a red unsafe automation bypass versus a governed path through source authority, evidence brief, human gate, and decision record.
Reader-facing receipt

Reader-facing receipt

This artifact is a public-safe teaching use case. It uses public governance sources, synthetic examples, and SharePlane interpretation to explain why an Enterprise Architecture Assistant needs governed source authority before automation. It does not include private source packets, transcripts, screenshots, employer materials, internal documents, real submissions, local paths, implementation history, or controlled information. The assistant model described here is a decision-support pattern, not an autonomous approval system.

Source posture

Public governance sources, synthetic teaching example, SharePlane interpretation.

Excluded

Internal documents, private sources, real submissions, employer/client details, operational traces.

Decision boundary

Decision-support pattern, not autonomous approval.