The argument in one paragraph
The Culture Stack is the core intellectual product of the Direct Create Knowledge Engine, present at every layer rather than sitting in any one box. It appears as a concept in the wiki spine, as engagement outputs in the strategic artifacts, as the thing the Culture Stack Automator tools build, and as the source content the public surfaces draw on. The engine’s job is to produce Culture Stacks well, to keep them readable and retrievable, and to support the Commentary that grows around each one. All terms used in this page are fixed in the DC-KE Glossary.
DC-KE in brief
The Direct Create Knowledge Engine is a wiki-spined knowledge system with capability layers stacked around it. Read top to bottom:
- Public surfaces, LinkedIn, Instagram, Substack and the Codex, the DC website, and client decks.
- Content production, the
dc-ke:draftskill and the four Pillars. - Strategic artifacts, portfolio dashboard, the Culture Stack visual library, the pricing calculator, the site generator.
- Intelligence reference layer,
wiki/published/,wiki/foundations/,wiki/visual_assets/. - Wiki spine, entities (projects, clients, people, places), concepts, crafts, synthesis.
- Source archive and image intelligence, the Dropbox project archive and the Image Intelligence Pipeline (IIP) catalogs.
- Tooling and model stack, the Culture Stack Automator pipeline and the model tiers (Opus for voice and argument, Sonnet for drafting, Gemini and local models for scale).
Where the Culture Stack lives in the engine
| DC-KE layer | The Culture Stack’s presence |
|---|---|
| Wiki spine, concepts | The canon: the Culture Stack definition, the glossary, the method, the Commentary layer. |
| Strategic artifacts | The Culture Stack visual library: one catalogued Study per engagement (for example Pune, Delhi, Gurgaon, Worli, BITS Pilani). |
| Content production, Pillars | Pillar 2 essays argue the discipline drawing on Studies; Pillar 1 dispatches reference an engagement’s Study; Pillar 3 features a craft Finding. |
| Source archive and IIP | IIP catalogs and the project archive feed Fieldwork and supply material for the Visual intention of exhibits. |
| Tooling and model stack | The Culture Stack Automator runs Culture Stacking; the model tiers route its stages. |
| Public surfaces | A Study rendered into a client deck or proposal; essays that carry the discipline. |
The Culture Stack Automator mapped to Culture Stacking
The CSA pipeline at ~/Dropbox/07 DC Projects/00 Culture Stack Automator/ assists the method. The mapping:
- CSR (cultural research pipeline) assists Fieldwork and Mapping: it gathers and organizes the evidence into Findings.
- IIP (image intelligence) assists Fieldwork: it builds the visual evidence and informs the Visual intention of exhibits.
- CW (the writer) assists Argument and Edition: it builds the narrative and lays out Chapters and Exhibits.
- GD (the designer) renders Exhibits into finished slides, downstream of Edition.
- CD (the creative director) orchestrates the pipeline, the conductor of a Culture Stacking run.
A standing caution from the Alila Coorg postmortem: the research tools (CSR, IIP) have proven value, while automated visual production (GD and image generation) has not yet met the bar and is currently done by hand. Treat the pipeline as assisting the method, with the Argument and the final visual judgment staying human.
Use cases: when to call the Culture Stack in
- A new place or project engagement. Run Culture Stacking to produce a Study. This is the primary use.
- A client proposal or deck. The Study is the spine; render its Chapters and Exhibits into the deck. Scoping also informs the proposal’s shape and price.
- A Pillar 2 essay. Argue a principle of the discipline, drawing on Studies as evidence rather than running a client case study. Load the canon first.
- A Pillar 1 dispatch. Reference a specific engagement’s Study for a short project dispatch.
- A Pillar 3 craft feature. Feature a craft Finding from a Study or from the craft fields.
- Briefing a designer or architect. Hand them the Study to read and build from; point them to the Commentary for interpretation support.
- An interpretation question. Answer it as Commentary, and capture the answer as an Annotation in
wiki/commentary/. - Maintaining the visual library. Catalogue each completed Study as a library entry.
Cross-reference index, where to find things
- The canon (authoring home in Dropbox):
00 DC Projects Automation/Culture Stack Canon/. Start atREADME.md. - The cascaded canon in the wiki: the Culture Stack, the glossary, the method, the Commentary layer.
- The visual library artifact:
artifacts/culture_stack_library.htmland per-engagement pages. - The tools:
00 Culture Stack Automator/(CSR, IIP, CW, GD, CD). - The drafting skill:
dc-ke:draftloads the glossary and the Culture Stack definition first for any Culture Stack topic. - Architecture diagrams:
dc_ke_master_architecture.svg,dc_ke_information_flow.svg,dc_ke_model_stack.svg.
The calling convention
When any DC-KE work touches a place, a project’s cultural grounding, or a site-specific deliverable, the canon is in scope. The convention: load the glossary, then the Culture Stack definition, confirm the task against the use cases above, and proceed using the glossary terms only. Every deliverable that draws on a Study should name the Study it came from, so the chain from place to Study to design stays traceable.
The two governing laws
Outputs are weighted by Emphasis and non-deterministic, so the engine offers readings and resolutions, never a single verdict. The Study informs and is interpreted, so it supports the human author and never authors in their place. These laws are enforced at the schema layer in CLAUDE.md and inherited by every tool, skill, and surface the engine produces.