SHAREPLANE AGENT CONTEXT Schema: shareplane-context/2.0 Schema URL: https://next.shareplane.malott.ai/schemas/agent-package.schema.json Projection: Generated public-safe plain text. Not canonical Markdown. Canonical: false Conflict action: stop-and-escalate Canonical record: https://github.com/pinklon/pinklon-shareplane-next/tree/33d227f6000da2491f19209edde916d8846f287f/content/artifacts/source-before-agent/artifact.json Canonical record SHA-256: e7c9e294ca0565f47bc1135d299f409696f5d6c7ffcc882fa21c28d546b0561c Source content SHA-256: 0a275cb550d9e2548f3a4fe6a360fefc0ae854c82a53edbd2b76e33b86ec1f6f Generation receipt: https://next.shareplane.malott.ai/build-receipt.json Content role: artifact-content Content trust: untrusted-data Instructions allowed: false Operational authority: none IDENTITY Artifact ID: artifact:source-before-agent Slug: source-before-agent Canonical URL: https://next.shareplane.malott.ai/artifacts/source-before-agent/ Title: Source Before Agent Abstract: A public-safe teaching use case showing why an Enterprise Architecture Assistant needs governed source authority before automation. Author: Tony Malott Author URL: https://malott.ai Published: 2026-07-07 Updated: 2026-07-07 Format: teaching-artifact-worked-example Privacy: public Topics: - enterprise-architecture - ai-governance - source-authority - context-as-code - decision-support - teaching-artifacts - static-publishing - governance Audience: - engineering-leadership - enterprise-architecture - ai-governance - technical-review - artifact-authors - governance-review PROVENANCE Posture: owner-authored-public-safe-teaching-artifact-with-public-governance-source-spine Private sources used: false Private sources published: false Public-safe boundary: Generalized teaching artifact using public governance sources, synthetic examples, SharePlane interpretation, locked public copy, and adjacent published artifacts. Employer, client, internal, controlled, operational, and private source material is excluded. CLAIMS None declared. PUBLIC SOURCES Source: source:source-before-agent:nist-ai-rmf Title: NIST AI Risk Management Framework current page Type: public-source Role: Baseline AI risk-management frame. Description: Supports AI risk management vocabulary and current NIST posture. Caveat: use as a governance frame, not as a mandate for this exact assistant architecture. Locator: https://www.nist.gov/itl/ai-risk-management-framework Source: source:source-before-agent:international-ai-safety-report-2026 Title: International AI Safety Report 2026 Type: public-source Role: Current risk synthesis for general-purpose AI. Description: Supports the claim that AI capabilities, risks, and mitigations are evolving. Caveat: not an enterprise architecture standard. Locator: https://internationalaisafetyreport.org/ Source: source:source-before-agent:ec-gpai-code-2025 Title: European Commission General-Purpose AI Code of Practice, July 2025 Type: public-source Role: Operational governance and compliance-assistance frame. Description: Supports transparency, copyright, safety, security, and accountability framing. Caveat: applicability depends on provider role, jurisdiction, and use case. Locator: https://digital-strategy.ec.europa.eu/en/news/general-purpose-ai-code-practice-now-available Source: source:source-before-agent:ec-gpai-obligations-2025 Title: European Commission GPAI obligations start applying, August 2025 Type: public-source Role: Regulatory timing and accountability frame. Description: Supports the current public signal that GPAI obligations are becoming operational. Caveat: do not imply universal applicability to every internal enterprise assistant. Locator: https://digital-strategy.ec.europa.eu/en/news/eu-rules-general-purpose-ai-models-start-apply-bringing-more-transparency-safety-and-accountability Source: source:source-before-agent:fda-ai-device-draft-2025 Title: FDA AI-enabled device software draft guidance, January 2025 Type: public-source Role: Regulated lifecycle side rail. Description: Supports lifecycle-risk, documentation, safety, and effectiveness thinking. Caveat: draft, nonbinding, and context-dependent. Locator: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/artificial-intelligence-enabled-device-software-functions-lifecycle-management-and-marketing Source: source:source-before-agent:fda-ai-regulatory-decisions-draft-2025 Title: FDA AI for drug/biologic regulatory decision-making draft guidance, January 2025 Type: public-source Role: Context-of-use and credibility side rail. Description: Supports credibility expectations for AI used to support regulated decision-making. Caveat: draft, nonbinding, and context-dependent. Locator: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological Source: source:source-before-agent:nist-csf Title: NIST Cybersecurity Framework current page Type: public-source Role: Cybersecurity governance side rail. Description: Supports cybersecurity risk-management framing for enterprise review. Caveat: not AI-specific. Locator: https://www.nist.gov/cyberframework RELATIONSHIPS Relationship: migratedFrom Target: repository:pinklon/shareplane Posture: declared Evidence: site/pages/source-before-agent/index.html Relationship: relatedTo Target: legacy-artifact:context-is-the-product Label: Context Is the Product Display posture: Foundation pattern Description: Explains why durable context is the product layer and the assistant is only an interface. Posture: declared-legacy Evidence: site/pages/source-before-agent/index.html#related-artifacts Locator: https://shareplane.pages.dev/pages/context-is-the-product/ Relationship: relatedTo Target: legacy-artifact:the-right-model-is-the-one-your-eval-can-defend Label: The Right Model Is the One Your Eval Can Defend Display posture: Evaluation discipline Description: Shows why model choice must be supported by evidence, traces, failures, and decision records. Posture: declared-legacy Evidence: site/pages/source-before-agent/index.html#related-artifacts Locator: https://shareplane.pages.dev/pages/the-right-model-is-the-one-your-eval-can-defend/ Relationship: relatedTo Target: artifact:demo-debt Posture: declared-registry Evidence: site/registry.json ARTIFACT CONTENT [HEADING 1] Source Before Agent [PARAGRAPH] Building a defensible Enterprise Architecture Assistant [PARAGRAPH] The agent is the interface. Governed context is the authority. [PARAGRAPH] 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. [HEADING 2] Where this comes from [PARAGRAPH] 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. [PARAGRAPH] The public sources provide governance signals, caveats, and risk framing. The assistant architecture is SharePlane interpretation, not a mandate from any cited source. [PARAGRAPH] This artifact does not disclose employer materials, client materials, internal documents, real submissions, controlled screenshots, local paths, or operational traces. [HEADING 2] Before the model, decide what counts as authority [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] Source Before Agent starts with a simple constraint: the first deliverable is not a chatbot. The first deliverable is a source authority model. [PARAGRAPH] 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. [PARAGRAPH] Search can find related material. Governance decides what can be trusted. [PARAGRAPH] Decision context is scattered across standards, exceptions, platform guidance, prior decisions, decks, chat threads, and email. [PARAGRAPH] Letting broad retrieval turn uncontrolled material into apparent decision authority. [PARAGRAPH] Build the source authority model before building the assistant interface. [PARAGRAPH] The deeper bottleneck is unmanaged decision context. [HEADING 2] Executive TLDR [PARAGRAPH] 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. [PARAGRAPH] The correct move is to build the source authority model first. [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] Search can find related material. Governance decides what can be trusted. [HEADING 2] Why search alone fails architecture review [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] That is worse than a slow review. A slow review can still be corrected. A confident weak decision can spread. [PARAGRAPH] A source can be related, recent, and still not decision-grade. [HEADING 2] Teaching use case: too many requests, too little governed context [PARAGRAPH] 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. [PARAGRAPH] The architecture team wants to move faster. The business wants answers. Reviewers need help turning messy submissions into complete, comparable review packets. [PARAGRAPH] 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. [PARAGRAPH] Without that control layer, the assistant is not accelerating architecture review. It is accelerating uncertainty. [HEADING 2] Access is not authority [PARAGRAPH] The unsafe shortcut is tempting: [PARAGRAPH] Broad search. Mixed documents. Confident answer. Weak decision. [PARAGRAPH] The defensible path is slower to design but stronger to operate: [PARAGRAPH] Source register. Authority tiers. Evidence brief. Human gate. Decision record. [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] 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. [HEADING 3] Unsafe shortcut [HEADING 3] Defensible path [HEADING 2] The source authority model [PARAGRAPH] The source authority model defines what the assistant is allowed to trust and how strongly it may use each source. [PARAGRAPH] 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. [PARAGRAPH] The model should use tiers. [PARAGRAPH] Tier 0: Mandatory governance authority [PARAGRAPH] 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. [PARAGRAPH] Tier 1: Enterprise architecture authority [PARAGRAPH] 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. [PARAGRAPH] Tier 2: Prior decisions and exceptions [PARAGRAPH] 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. [PARAGRAPH] Tier 3: Implementation guidance [PARAGRAPH] 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. [PARAGRAPH] Tier 4: Discovery only [PARAGRAPH] 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. [PARAGRAPH] Useful evidence, but not independent decision authority. [HEADING 3] Tier 0: Mandatory governance authority [PARAGRAPH] Hard constraints and mandatory governance authority. [HEADING 3] Tier 1: Enterprise architecture authority [PARAGRAPH] Approved platform standards, reference architectures, patterns, and catalogs. [HEADING 3] Tier 2: Prior decisions and exceptions [PARAGRAPH] Precedent, decision consistency, and exception boundaries. [HEADING 3] Tier 3: Implementation guidance [PARAGRAPH] Supporting implementation context that does not override authority. [HEADING 3] Tier 4: Discovery only [PARAGRAPH] Useful evidence, but not independent decision authority. [HEADING 2] Related is not authoritative [PARAGRAPH] A source can be useful without being decision-grade. [PARAGRAPH] This is one of the most important rules in the whole pattern. Enterprise knowledge is full of useful material that should not be treated as authority. A deck can explain the current thinking. An email can point to the right owner. A chat thread can reveal that a standard is changing. A draft page can show where a platform team is headed. [PARAGRAPH] Those are useful signals. They are not the same thing as approved guidance. [PARAGRAPH] The assistant should use source state rules before it uses source content. [PARAGRAPH] Controlled, owned, current, approved material can support decision preparation. [PARAGRAPH] Owned and current, but not formally controlled material can support a caveated recommendation. [PARAGRAPH] Useful material with unclear owner or version should be reference-only. [PARAGRAPH] Email, chat, deck, and informal notes should be discovery-only. [PARAGRAPH] Conflicting, stale, or superseded material should be blocked until resolved. [PARAGRAPH] Useful does not mean decision-grade. [HEADING 3] Controlled, owned, current, approved [PARAGRAPH] Controlled, owned, current, approved -> Decision support [HEADING 3] Owned and current, not controlled [PARAGRAPH] Owned and current, not controlled -> Conditional support with caveat [HEADING 3] Owner or version unclear [PARAGRAPH] Owner or version unclear -> Reference only [HEADING 3] Email, chat, deck, informal note [PARAGRAPH] Email, chat, deck, informal note -> Discovery only [HEADING 3] Conflicting, stale, superseded [PARAGRAPH] Conflicting, stale, superseded -> Blocked until resolved [HEADING 2] The platform documentation failure mode [PARAGRAPH] The hardest cases are not always caused by bad documentation. Sometimes the problem is almost the opposite: too much documentation, but no clear authority. [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] The answer is not to ignore those materials. The answer is to quarantine them until they are validated. [PARAGRAPH] 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. [HEADING 2] Context-as-code is the control plane [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] The context layer is managed like a product, not treated like background noise. [PARAGRAPH] 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. [PARAGRAPH] This is the work that makes the assistant defensible. [HEADING 3] Source register [PARAGRAPH] Versioned source inventory and source authority tiers. [HEADING 3] Source packs [PARAGRAPH] Eligible decision-support sources for review domains. [HEADING 3] Intake schema [PARAGRAPH] Required fields, completeness checks, and risk-domain classification. [HEADING 3] Review workflow [PARAGRAPH] Controlled path from submission through human decision. [HEADING 3] Decision rules [PARAGRAPH] Rules for what the assistant may cite, compare, or recommend. [HEADING 3] Claim ledger [PARAGRAPH] Traceable posture for public-source facts, interpretation, and caveats. [HEADING 3] Decision records [PARAGRAPH] Captured rationale and approved decision knowledge. [HEADING 3] Evaluations [PARAGRAPH] Tests that monitor drift and review-brief usefulness. [HEADING 2] What the assistant actually does [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] A defensible assistant makes the human decision easier to inspect. It does not make the human disappear. [PARAGRAPH] 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. [PARAGRAPH] The assistant prepares. Humans decide. [HEADING 2] What the assistant must not do [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] The safest assistant is not the one that refuses everything. The safest assistant is the one that knows the boundary between preparation and decision. [HEADING 2] MVP boundary [PARAGRAPH] The first useful version should be narrow. [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] The MVP should prove that governed context improves review preparation before anyone expands the assistant’s authority. [HEADING 3] MVP includes [LIST ITEM] AI and AI-adjacent solution submissions [LIST ITEM] Standard intake schema [LIST ITEM] Completeness checker [LIST ITEM] Risk-domain classifier [LIST ITEM] Source authority register [LIST ITEM] Initial source packs [LIST ITEM] Evidence-backed review brief [LIST ITEM] Human architecture gate [LIST ITEM] Decision record capture [LIST ITEM] Pilot evaluation set [HEADING 3] MVP excludes [LIST ITEM] Autonomous approval [LIST ITEM] Broad crawling as decision authority [LIST ITEM] Unrestricted document ingestion [LIST ITEM] Regulatory classification by agent alone [LIST ITEM] Security/privacy/quality/legal/procurement approval automation [LIST ITEM] Silent source promotion [LIST ITEM] Direct source mutation by assistant [HEADING 2] How success should be measured [PARAGRAPH] The assistant is successful only if it improves review preparation without weakening accountability. [PARAGRAPH] 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. [PARAGRAPH] Do not measure success only by answer speed. A fast answer from weak authority is not progress. It is just failure with better latency. [HEADING 3] Completeness [PARAGRAPH] Submissions are more complete before human review. [HEADING 3] Preparation time [PARAGRAPH] Review preparation takes less time. [HEADING 3] Citations [PARAGRAPH] Citations are present and relevant. [HEADING 3] Caveats [PARAGRAPH] Caveats remain visible. [HEADING 3] Conflicts [PARAGRAPH] Source conflicts are detected. [HEADING 3] Exceptions [PARAGRAPH] Exceptions are routed correctly. [HEADING 3] Reviewer trust [PARAGRAPH] Reviewers can use, challenge, and improve the brief. [HEADING 2] Risks and controls [PARAGRAPH] 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. [PARAGRAPH] Another risk is stale guidance. That is controlled by source ownership, freshness metadata, review dates, and retirement rules. [PARAGRAPH] Another risk is hidden approval automation. That is controlled by explicit decision boundaries and workflow language that keeps the assistant in the preparation role. [PARAGRAPH] Another risk is unresolved source conflict. That is controlled by stop/report behavior and owner resolution. [PARAGRAPH] Another risk is source sprawl. That is controlled by source packs, not one giant pile of documents. [PARAGRAPH] The control pattern is simple: the assistant may accelerate preparation, but it cannot bypass authority. [HEADING 3] Risk: overtrust [PARAGRAPH] Control: source eligibility rules, citation requirements, visible caveats, and a hard human gate. [HEADING 3] Risk: stale guidance [PARAGRAPH] Control: source ownership, freshness metadata, review dates, and retirement rules. [HEADING 3] Risk: hidden approval automation [PARAGRAPH] Control: explicit decision boundaries and preparation-role workflow language. [HEADING 3] Risk: unresolved source conflict [PARAGRAPH] Control: stop/report behavior and owner resolution. [HEADING 3] Risk: source sprawl [PARAGRAPH] Control: source packs instead of one giant pile of documents. [HEADING 2] Evidence spine: public sources, claim posture, and caveats [PARAGRAPH] The public sources support the governance frame. The assistant architecture remains SharePlane interpretation. [PARAGRAPH] 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. [PARAGRAPH] 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. [PARAGRAPH] Public-source-supported fact: AI risk management requires attention to design, development, use, evaluation, and context. [PARAGRAPH] Governance signal: AI governance expectations are becoming more operational, especially around transparency, accountability, safety, and security. [PARAGRAPH] Regulated-context side rail: AI used in life-sciences-style contexts may require lifecycle thinking, documentation, credibility, safety, and effectiveness considerations. [PARAGRAPH] Cybersecurity side rail: Enterprise technology review still needs cybersecurity risk governance. [PARAGRAPH] SharePlane interpretation: An architecture assistant should be built on source authority before automation. [PARAGRAPH] Explicit non-claim: No listed source requires this exact assistant architecture. [HEADING 3] Public-source-supported fact [PARAGRAPH] Official public sources support specific governance, risk, lifecycle, or cybersecurity framing. [HEADING 3] Governance signal [PARAGRAPH] Current public materials show direction of travel without becoming local operating rules. [HEADING 3] Regulated-context side rail [PARAGRAPH] FDA draft guidance informs risk thinking only where context makes it relevant. [HEADING 3] Cybersecurity side rail [PARAGRAPH] NIST CSF supports the enterprise-risk frame without becoming AI-specific authority. [HEADING 3] SharePlane interpretation [PARAGRAPH] The source-before-agent architecture is an applied teaching pattern, not a public-source mandate. [HEADING 3] Explicit non-claim [PARAGRAPH] No listed source requires this exact assistant architecture. [HEADING 2] Related artifacts [PARAGRAPH] Related artifacts should help the reader navigate the broader SharePlane pattern language without turning this page into a link farm. [HEADING 3] Context Is the Product [PARAGRAPH] Relationship: Foundation pattern. [PARAGRAPH] Reason: Explains why durable context is the product layer and the assistant is only an interface. [HEADING 3] The Right Model Is the One Your Eval Can Defend [PARAGRAPH] Relationship: Evaluation discipline. [PARAGRAPH] Reason: Shows why model choice must be supported by evidence, traces, failures, and decision records. [HEADING 3] Source Before Agent [PARAGRAPH] Relationship: Source authority pattern. [PARAGRAPH] Reason: Defines the governed context layer an architecture assistant needs before automation. [HEADING 2] Visual prompt suite [PARAGRAPH] 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. [PARAGRAPH] 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. [HEADING 3] Prompt 1: Source Before Agent [PARAGRAPH] A: mainline white. B: dark expressive. [HEADING 4] A: mainline white [PARAGRAPH] Teaching graphic. [HEADING 4] B: dark expressive [PARAGRAPH] Technical graphic. [HEADING 3] Prompt 2: Related Is Not Authoritative [PARAGRAPH] A: mainline white. B: dark expressive. [HEADING 4] A: mainline white [PARAGRAPH] Source-state matrix. [HEADING 4] B: dark expressive [PARAGRAPH] Quarantine console. [HEADING 3] Prompt 3: From Submission to Evidence Brief [PARAGRAPH] A: mainline white. B: dark expressive. [HEADING 4] A: mainline white [PARAGRAPH] Runway sequence. [HEADING 4] B: dark expressive [PARAGRAPH] Evidence flow. [HEADING 3] Prompt 4: Evidence Spine [PARAGRAPH] A: mainline white. B: dark expressive. [HEADING 4] A: mainline white [PARAGRAPH] Source dossier rail. [HEADING 4] B: dark expressive [PARAGRAPH] Evidence control board. [HEADING 3] Prompt 5: Do Not Automate Architecture Without Authority [PARAGRAPH] A: mainline white. B: dark expressive. [HEADING 4] A: mainline white [PARAGRAPH] Capstone comparison. [HEADING 4] B: dark expressive [PARAGRAPH] Control-room map. [HEADING 2] Reader-facing receipt [PARAGRAPH] 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. [HEADING 3] Source posture [PARAGRAPH] Public governance sources, synthetic teaching example, SharePlane interpretation. [HEADING 3] Excluded [PARAGRAPH] Internal documents, private sources, real submissions, employer/client details, operational traces. [HEADING 3] Decision boundary [PARAGRAPH] Decision-support pattern, not autonomous approval. PUBLIC SURFACES Human page: https://next.shareplane.malott.ai/artifacts/source-before-agent/ Metadata JSON: https://next.shareplane.malott.ai/artifacts/source-before-agent/artifact.json Receipt: https://next.shareplane.malott.ai/artifacts/source-before-agent/receipt.json Context: https://next.shareplane.malott.ai/artifacts/source-before-agent/context.txt Agent-package manifest: https://next.shareplane.malott.ai/artifacts/source-before-agent/agent-package.json Agent-package ZIP: https://next.shareplane.malott.ai/artifacts/source-before-agent/agent-package.zip Collection catalog: https://next.shareplane.malott.ai/catalog.json Graph: https://next.shareplane.malott.ai/graph.json Agent index: https://next.shareplane.malott.ai/llms.txt