Strategic Architecture: Specify AI-Assisted Marketing Work Before Execution
Strategic Architecture is the kōdōkalabs delivery method for converting an approved business problem into an explicit execution specification covering audience, outcome, evidence, scope, workflow, human responsibility, AI boundaries, governance, measurement, and acceptance criteria.
Executive Summary
Strategic Architecture exists because AI-assisted work that begins before its intended outcome, audience, evidence, boundaries, and acceptance criteria have been made explicit tends to look complete without actually answering the right question, the output arrives polished and confident, and the gaps only surface once an approver tries to use it for its intended purpose. Strategic Architecture is kōdōkalabs’ repeatable method for closing that gap: a twelve-field specification that gets written and reviewed before execution begins, not reconstructed afterward to justify whatever was produced. This page distinguishes Strategic Architecture from the broader Architect framework phase, covers all twelve specification fields, and explains how evidence, human/AI responsibility, and acceptance criteria get defined before a single piece of work is drafted.
Key Takeaways
- Strategic Architecture is a repeatable delivery method for specifying one workstream, distinct from the Architect framework phase, which defines an organization’s broader target operating model.
- A twelve-field specification captures outcome, audience, evidence, scope, workflow, responsibility, governance, format, measurement, and acceptance criteria before execution starts.
- Prompts alone are not architecture: a good prompt without a defined specification still produces unreviewable, unaccountable output.
- The Assumption Register and Source Resolution Plan make hidden assumptions and evidence gaps visible and reviewable, rather than discovered after the fact.
- Strategic Architecture ends in an explicit review and approval gate before work moves to Agentic Drafting.
What Is Strategic Architecture?
Strategic Architecture takes an approved business problem, already prioritized, already connected to a defined outcome, and converts it into a specification detailed enough that research, workflow design, AI-assisted execution, human review, and measurement can all proceed from a shared, explicit basis rather than from individual assumptions about what “good” looks like. It’s the method kōdōkalabs uses to specify one workstream at a time, applied repeatedly across every piece of AI-assisted work the firm delivers.
Strategic Architecture Versus the Architect Phase
Strategic Architecture and the Architect phase of the kōdōkalabs Transformation System are related but distinct, and confusing them tends to produce either an overbuilt specification for a single small workstream or an underspecified operating model for an entire organization.
| Architect Phase | Strategic Architecture Methodology | |
|---|---|---|
| Scope | The organization’s target operating model across workflows | One specific workstream or deliverable |
| Frequency | Once per major transformation initiative | Repeated for every individual piece of AI-assisted work |
| Output | Target operating model, governance control stack, workflow architecture | A twelve-field specification for a single execution |
| Question it answers | How should our marketing function operate? | What, specifically, are we producing, and how do we know it’s right? |
Architect defines the operating model a set of workflows will run within; Strategic Architecture is the repeatable method for specifying one workstream to run correctly inside that model. A single Architect phase typically produces the target operating model that dozens or hundreds of individual Strategic Architecture specifications will subsequently be written against.
This distinction also clarifies who’s responsible for what. Architect is typically a leadership-level exercise, involving executive sponsors, governance stakeholders, and workflow owners deciding how marketing should operate as a system. Strategic Architecture, by contrast, is a practitioner-level discipline applied by whoever is specifying a given piece of work: a content strategist specifying a cornerstone guide, a campaign lead specifying a launch sequence, or a growth lead specifying a measurement report. Treating Strategic Architecture as something only leadership does slows delivery to a crawl; treating Architect as something any individual practitioner can improvise on their own tends to produce workflows that don’t actually cohere into a consistent operating model once several of them exist side by side.
Why Prompts Are Not a Substitute for Architecture
A well-crafted prompt can produce a strong single output, but a prompt alone doesn’t capture the underlying decisions that make that output reviewable and repeatable: what evidence was it supposed to draw on, what was explicitly out of scope, who is accountable for checking it, what would make an approver reject it, and how will its performance be measured once published. Without a specification behind it, a prompt that worked well once is difficult to reproduce reliably, difficult to hand to another practitioner, and difficult to defend when an approver asks why a specific claim or framing was included. Strategic Architecture makes the reasoning behind the prompt explicit and reviewable, rather than leaving it implicit in whoever wrote the prompt’s head.
The Twelve Fields of a Strategic Architecture Specification
Every kōdōkalabs Strategic Architecture specification covers twelve required fields.
| # | Field | What It Captures |
|---|---|---|
| 1 | Business decision or outcome | What decision this work is meant to support or enable |
| 2 | Audience and use context | Who will consume the output, and in what context |
| 3 | Problem statement | The specific problem this work addresses |
| 4 | Scope and exclusions | What’s in scope, and explicitly what is not |
| 5 | Approved evidence and source hierarchy | What sources are permitted, and their priority order |
| 6 | Entities, terminology, and framework references | Required naming, definitions, and canonical framework references |
| 7 | Workflow and dependencies | The sequence of steps and what each depends on |
| 8 | Human and AI responsibility allocation | Who or what does each part of the work |
| 9 | Governance, privacy, security, and IP constraints | Applicable rules and boundaries |
| 10 | Output and format requirements | Required structure, length, and format |
| 11 | Measurement and observability | How performance will be tracked once published |
| 12 | Acceptance criteria, approvers, and handoff | What “done and correct” means, and who confirms it |
Each field exists because its absence has a predictable failure mode: no defined audience produces work pitched at no one in particular; no defined exclusions produces scope creep discovered mid-execution; no defined acceptance criteria produces approval disputes based on subjective preference rather than agreed standards.
How Evidence and Sources Are Planned
Before execution begins, Strategic Architecture requires an explicit Source Resolution Plan: what source is needed, what class of source is preferred, who owns retrieving it, how fresh it needs to be, what permitted use applies, where the citation or evidence will live in the final output, and, critically, an honest record of any gap that remains unresolved. This plan does not endorse uncontrolled scraping, unauthorized access to systems or data, or treating an AI system’s unverified summary of search results as evidence in its own right; every source in the plan traces back to something a human can actually check.
Alongside the Source Resolution Plan, kōdōkalabs maintains an Assumption Register for every specification: each assumption made during planning, its source, the confidence behind it, the consequence if it turns out to be wrong, who’s responsible for validating it, when it was or will be validated, and its current disposition (open, validated, or rejected). Making assumptions explicit and reviewable, rather than leaving them buried in the reasoning behind a prompt, is one of the most direct ways Strategic Architecture reduces the risk of confidently wrong output.
How Human and AI Responsibilities Are Defined
Field eight of the specification, human and AI responsibility allocation, assigns each step of the workflow explicitly: does an AI system draft it, does a human draft it, and regardless of who drafts it, who reviews it and what are they checking for. This allocation is decided during Strategic Architecture, before execution, specifically so a reviewer isn’t left guessing what they’re responsible for catching after the fact.
| Responsibility Type | Example |
|---|---|
| AI-drafted, human-reviewed | Initial content draft reviewed for accuracy and brand fit before publication |
| Human-authored | Strategic positioning or legally sensitive language |
| AI-assisted research, human-verified | Source gathering checked against the approved source hierarchy |
| Human-only decision | Final approval and publication sign-off |
How Risk and Governance Shape the Specification
Field nine of the specification connects each piece of AI-assisted work to the governance requirements that already apply to it: the risk classification, review requirements, privacy considerations, and any intellectual-property constraints established during Architect and enforced during Build. Strategic Architecture doesn’t invent new governance rules; it applies the organization’s existing governance framework to the specific workstream being specified, making it explicit rather than assumed.
How Acceptance Criteria Are Written
Field twelve, acceptance criteria, is where subjective disagreement at review time gets prevented in advance, by defining up front what “correct” and “complete” actually mean for this specific piece of work, across several criteria types.
| Criteria Type | What It Checks |
|---|---|
| Factual | Claims are accurate and traceable to an approved source |
| Functional | The output actually does what it was specified to do |
| Brand | Tone, terminology, and positioning match approved standards |
| Accessibility | Output meets applicable accessibility requirements |
| Governance | Output complies with the applicable risk classification and review process |
| Measurement | Required tracking and observability are in place |
| Ownership | A named individual is accountable for the final result |
Acceptance criteria written only as “does it look good” invites disagreement rooted in personal preference rather than agreed standards: the criteria above are written to be checkable, not merely felt.
Strategic Architecture Outputs
A completed Strategic Architecture specification produces: the twelve-field specification document itself, a completed Assumption Register, a completed Source Resolution Plan, and an explicit sign-off from the specification’s approvers confirming it’s ready for execution. These outputs become the shared reference that Agentic Drafting, Pilot Review, and eventual measurement all work from.
Review and Approval Gates
Before execution begins, the specification passes through a review gate where the assigned approvers confirm the twelve fields are complete, the Assumption Register’s open items have a validation plan, the Source Resolution Plan’s gaps are acceptable or resolved, and the acceptance criteria are specific enough to be checked objectively later. Work does not begin against an unapproved specification. This gate exists specifically to catch ambiguity while it’s still cheap to fix, rather than after execution has already consumed time and resources.
Common Strategic Architecture Failure Modes
- Vague objectives: a specification that states a general direction without a specific, checkable business decision or outcome.
- Hidden assumptions: proceeding on unstated assumptions that never make it into the Assumption Register, and therefore never get checked.
- Generic ICP descriptions: an audience field so broad it doesn’t actually constrain how the work should be written.
- Keyword-first briefs without business purpose: specifications built around search terms rather than the business decision the content is meant to support.
- Evidence gaps papered over: treating an unresolved item in the Source Resolution Plan as resolved rather than flagging it honestly.
- Undefined exclusions: no explicit scope boundary, inviting scope creep discovered only mid-execution.
- Architecture written after execution: reconstructing a specification retroactively to justify work that’s already been produced, defeating the entire purpose of specifying in advance.
- Subjective-preference-only acceptance criteria: “make it better” instead of checkable factual, functional, brand, accessibility, governance, and measurement criteria.
How Strategic Architecture Leads to Agentic Drafting
Once a specification clears its review and approval gate, it becomes the direct input to Agentic Drafting: kōdōkalabs’ method for executing AI-assisted work against an approved specification, with the human/AI responsibility allocation, evidence sources, and acceptance criteria already defined rather than improvised during execution.
Frequently Asked Questions (FAQ)
How does kōdōkalabs turn a business problem into AI-assisted marketing work?
Through Strategic Architecture, a twelve-field specification covering outcome, audience, evidence, scope, workflow, responsibility, governance, format, measurement, and acceptance criteria, reviewed and approved before execution begins.
How is Strategic Architecture different from the Architect phase?
Architect defines an organization’s broader target operating model, applied once per major transformation initiative. Strategic Architecture is a repeatable method for specifying one workstream at a time, applied to every individual piece of AI-assisted work. See the comparison table above.
Why isn’t a good prompt enough?
A prompt can produce one strong output without capturing the underlying decisions (evidence sources, exclusions, accountability, acceptance criteria) that make the work reviewable, repeatable, and defensible.
What are the twelve specification fields?
Business decision, audience and use context, problem statement, scope and exclusions, approved evidence and sources, entities and terminology, workflow and dependencies, human/AI responsibility, governance constraints, output requirements, measurement plan, and acceptance criteria with approvers. See the full table above.
How do you handle evidence and sources?
Through a Source Resolution Plan that specifies required sources, ownership, freshness, and permitted use, explicitly excluding uncontrolled scraping, unauthorized access, or unverified search-result summaries as evidence.
How do you split responsibility between humans and AI?
Explicitly, field by field, before execution: see “How Human and AI Responsibilities Are Defined” above.
What if an assumption in the specification turns out to be wrong?
The Assumption Register records its consequence and validation owner in advance, so a wrong assumption is identified through a defined validation step rather than discovered by surprise after publication.
How do you write acceptance criteria that can be checked rather than argued about?
Across seven checkable criteria types (factual, functional, brand, accessibility, governance, measurement, and ownership) rather than a single subjective judgment of quality.
What happens once a specification is approved?
It becomes the direct input to Agentic Drafting, kōdōkalabs’ method for executing AI-assisted work against an approved specification.
Does every piece of work need a full twelve-field specification?
The depth of documentation can scale with the risk and complexity of the work, but all twelve fields should be considered explicitly: even a brief specification benefits from confirming none of the twelve areas has been silently skipped.
Ready to Architect Your Growth?
If you’re tired of fragmented, keyword-centric strategies, it’s time to build a foundation that withstands algorithm shifts. Let’s start with the blueprint that guarantees high-ROI execution.Get In Touch With Us