Decisions record the owner's accepted direction for this project. They do not certify an architecture, assign authority in another organization or close review findings. Proposed technical design decisions remain in the corresponding canonical architecture until explicitly adopted.
Entries are dated and retained. Supersede an entry with a new entry rather than rewriting its historical rationale.
| ID | Date | State | Decision and reason | Origin and scope | Revisit when |
|---|---|---|---|---|---|
| DEC-001 | 2026-09-08 | Accepted | Develop the original security architectures from the owner's brief and public primary sources; exclude unrelated workspace material. A folder's contents do not define the design basis. | Explicit owner instruction during initial creation. | The owner authorizes a specific additional source. |
| DEC-002 | 2026-09-09 | Accepted | Keep secure business AI, defend against AI-enabled attacks and defend with AI as three connected security perspectives. The same event may need all three. | Owner's requested series and overarching narrative. | Evidence shows an important security responsibility cannot be explained within the views and their interfaces. |
| DEC-003 | 2026-09-09 | Accepted | Maintain canonical Markdown and PNG visuals, detailed guides, a presentation and a public website. Capture common language and authoring rules for people and agents. | Owner's artifact and repeatability requests. | Reader testing identifies a format that adds maintenance burden without helping comprehension. |
| DEC-004 | 2026-09-09 | Accepted | Publish the selected public edition in jessepike/ai-security-reference-architectures and at ai.jessepike.dev, with feedback to jesse@jessepike.dev. Keep raw operational review material outside public packages. |
Explicit publication, domain and public-email selections. | The owner changes the public identity, host or sharing scope. |
| DEC-005 | 2026-09-09 | Accepted | Improve the introduction with situation, next decision, accountable owner and permitted data use. Present built, bought, embedded and unmanaged as overlapping discovery prompts. | Owner accepted the comparison recommendations on 9 September. Only the approved concepts transfer; the prior internal document is not published. | Reader testing shows these prompts confuse rather than clarify the starting conversation. |
| DEC-006 | 2026-09-09 | Accepted | Add one governance companion with canonical Markdown, PNG and a detailed guide. Explain decision rights and lifecycle oversight across the three security perspectives, including risks beyond cybersecurity. | Owner accepted the governance recommendation on 9 September. | An existing governance model can meet the need through a smaller interface guide, or the owner explicitly changes scope. |
| DEC-007 | 2026-09-09 | Accepted | Distinguish coordination from accountability. Identify the relevant decisions and evidence before mapping them to security, GRC, an AI office or other teams. Reuse existing governance processes where possible. | Accepted governance/ownership recommendation; no organization-specific roles are assigned. | A specific implementation supplies its actual authority and operating model. |
| DEC-008 | 2026-09-09 | Accepted | Scaffold this repository with a purpose, shared agent instructions, decisions, work state, contribution guidance and validation/release procedures. Public canonical sources live in content/. |
Explicit owner request to scaffold the project and capture decisions. | The structure becomes insufficient or creates unnecessary duplicate records. |
| DEC-009 | 2026-09-09 | Accepted | Introduce AI security and governance together in the opening story and explain how decisions, protections and operating evidence connect. Carry the relationship through the website, presentation and common example while retaining the three security perspectives. | Owner requested that the story include governance and how they work together after publication of the companion. This extends DEC-005 and DEC-006; it does not approve a particular organization's controls or authority model. | Reader testing shows that the explanation obscures the distinction or the continuing exchange between governance and security. |
| DEC-010 | 2026-09-09 | Superseded public wording | Establish this body of work as our canonical AI Security & Governance package for orientation, awareness and education, future evolution and exploration, and a basis for future downstream adaptations. Connect intent, roadmap, backlog, status, decisions and source records so the purpose and work remain traceable. | Jesse's explicit vision and alignment request, now represented by AISG-INTENT-001 v1.1. This establishes project direction and intended downstream use; it does not establish adoption, offers or commercial authority. | The owner changes the package's purpose, intended beneficiaries, canonical role or downstream relationship. |
| DEC-011 | 2026-09-09 | Accepted direction; implemented layout | Extract this package from the misplaced client directory and keep its workspace under ai-security/ref-architectures/, with publication/ retaining its independent Git history and public deployment boundary. Preserve historical files and existing public URLs. |
Owner explicitly requested relocation, GitHub continuity and validation. The nested layout is the implementation choice within that request; it does not merge this canon with the surrounding exploratory work. See workspace layout. | The owner explicitly chooses a different workspace arrangement or repository consolidation after reviewing history, source and publication boundaries. |
| DEC-012 | 2026-09-14 | Accepted | Remove organization-specific downstream language from the personal site and public repository. Retain a neutral, traceable downstream-adaptation boundary. | Jesse's direct instruction. This changes public project wording and does not establish a downstream program, offer, sponsorship, delivery commitment or external-use authority. | The owner directs a different public identity or a named downstream relationship. |
| DEC-013 | 2026-09-14 | Accepted scope for preview; content acceptance unassessed | Prepare a neutral “Applying Secure Business AI” application companion and Vercel preview after external review. Keep it separate from the three architectures, governance responsibilities, and existing presentation. | Jesse's direct instruction to run external reviews and prepare a Vercel preview before any production merge. Scope is source, derived map and guide, site integration, validation, and preview only. | The owner accepts, rejects, materially revises, or authorizes production publication of the companion. |
| DEC-014 | 2026-09-15 | Accepted scope for preview; content acceptance unassessed | Add a meeting-friendly CISO walkthrough for the Stage 0 starter playbook and its Stage 1 handoff. Keep the existing six-stage application guide as the complete journey reference and derive the walkthrough display and templates from one Markdown source. | Jesse's direct instruction to integrate the selected playbook pieces into the protected Vercel preview so he can walk a CISO through them. Scope is the walkthrough source, site display, derived template downloads, validation, and preview only; it does not change accepted intent or inherit prior external review. | The owner accepts, rejects, materially revises, or authorizes production publication of the walkthrough. |
| DEC-015 | 2026-09-15 | Accepted for public publication | Publish the reviewed Applying Secure Business AI companion and the selected CISO walkthrough at ai.jessepike.dev, while retaining their recorded source, review, and evidence limits. |
Jesse's explicit authorization to merge PR 1 and publish the integrated materials. This authorizes this public reference edition; it does not establish human architectural acceptance, field validity, control effectiveness, compliance, or organization-specific adoption. | Reader or field evidence warrants a source revision, or the owner changes the public scope. |
| DEC-016 | 2026-09-15 | Accepted | Introduce the current public resource by its purpose and vendor-neutral content without a personal ownership or organizational affiliation statement. Preserve functional public addresses and historical decision and evidence records. | Direct owner instruction to keep the resource unaffiliated with an organization and remove unnecessary personal ownership framing at this stage. This changes current public presentation, not authorship history, accepted intent, architecture meaning, or review state. | The publication gains an authorized organizational identity or the owner selects a different public presentation. |
| DEC-017 | 2026-09-15 | Accepted | Replace the ten identified abstract or formulaic passages with the reviewed plain-language alternatives and carry the changed wording through matching guides, the website, and presentation. Preserve the architecture, authority model, risk constraints, evidence requirements, and review status. | Jesse approved the specific recommendations in the 15 September foundation editorial review. This is a bounded wording decision, not acceptance of a broader rewrite or evidence of reader comprehension. | Reader testing or architectural review shows that the revised explanation changes meaning or remains unclear. |
Review boundary
The intent governs direction. The roadmap and backlog describe the work proposed or undertaken against it; status reports current state. Entries in those work records do not automatically become accepted decisions. The project guide connects all maintained records.
The original three component packages received model-assisted critique with material reservations. New content and successful browser/build checks do not inherit that review. Keep current coverage and open questions in review status.