Set Up Your AI Command Centre

Most professionals use AI the same way every time: open a blank chat, type a request, get a generic answer, then spend ten minutes correcting the tone, the structure and the assumptions. The next day they open another blank chat and pay the same tax again. The model never learns your role, your reader or your standards, because nothing you taught it yesterday survived the session.

An AI command centre is the fix. It is a configured workspace where the AI already knows your voice, your role, your sources and your boundaries before you type a word. The configuration lives in a small set of plain-text files and standing instructions: a voice profile built from a structured interview, a custom-instruction block that travels with every chat, a library of markdown files holding your templates and terminology, and a set of prompt chains for the work you repeat. Set it up once and every future session starts warm.

The difference compounds. A practitioner who has invested two or three hours in setup gets first drafts that sound like them, follow their templates and cite their sources. An ad hoc user gets a competent stranger. Over a year of daily use, the gap is measured in working weeks, and it shows up in quality as well as speed, because a configured workspace enforces the checks a rushed human forgets.

This module builds your command centre in four parts. Part 1 is the universal method: a voice-profile interview, custom-instruction blocks, a markdown source library, prompt chaining and process mapping, all platform-neutral. Part 2 turns the method into five role playbooks for workers compensation, WHS, GRC, HR and leadership work. Part 3 extends the workspace into a second brain that outlives any single chat, on either the ChatGPT Enterprise path or the Claude and Obsidian path. Part 4 sets the governance guardrails that keep the whole thing defensible. A 30-question assessment at the end checks what stuck.

Part 1: The universal method

Everything in this part works on any capable AI platform. The examples name ChatGPT and Claude because they are two of the most widely deployed enterprise AI platforms and the two this module has verified against current vendor documentation, but the method is the point: interview, instruct, file, chain, map. You can run all five steps this week, in order, in a few hours total.

Step 1. The voice-profile interview

Generic AI output fails first on voice. The fastest fix is not to describe your style from memory; it is to let the AI interview you, then compile what it heard. An interview surfaces preferences you would never think to write down, and it captures real example sentences, which teach a model more than any adjective can.

Run the prompt below in a fresh chat. Answer honestly and paste real writing samples when asked. The profile is only as good as the evidence you feed it.

You are going to interview me so you can learn to write the way I write. Ask the questions below one at a time, in order. Wait for my answer before moving to the next question. Do not skip ahead, do not summarise mid-interview, and do not offer opinions on my answers.

1. What is your role, and what kind of work does your team produce?
2. Who reads your writing most often: executives, operational teams, external stakeholders, or a mix? Who is the hardest reader to satisfy?
3. Paste a recent piece of your writing you consider strong. What makes it work?
4. Paste a piece of writing, yours or one you edited, that missed the mark. What was wrong with it?
5. How formal is your default register? Give me one sentence you would actually write and one you never would.
6. Do you prefer conclusions first, or arguments that build to a conclusion? Does that change by audience?
7. What structures do you reach for repeatedly: numbered recommendations, tables, headed sections, dot points, short paragraphs?
8. Which words and phrases do you ban from your writing? Which corporate cliches annoy you?
9. What spelling and style conventions do you follow, for example Australian English, no em dashes, specific citation habits?
10. How do you open and close documents and emails? Any standing sign-offs?
11. What should a reader feel after reading your work: informed, reassured, warned, persuaded?
12. What do colleagues consistently praise or correct in your writing?

When the interview is complete, tell me you are ready to produce my voice profile and wait for my go-ahead.

When the interview finishes, run the second prompt in the same chat. It converts the transcript into a file you will reuse everywhere.

Using the full interview transcript above, produce a file called writing-style.md that another AI could follow to write as me. Use these headings:

# Writing style profile: [YOUR NAME OR ROLE]
## Role and audience
## Register and tone
## Structure preferences
## Sentence and paragraph habits
## Vocabulary: preferred terms
## Vocabulary: banned words and phrases
## Conventions (spelling, formatting, citations)
## Openings and closings
## Worked example (short passage written in my voice)

Keep it under 600 words. Every rule must trace to something I said in the interview. Where I gave an example sentence, quote it. Do not invent preferences I did not state.

Save the output as writing-style.md. This file is the foundation stone of the command centre: it will be uploaded to your ChatGPT project, placed in your Claude working folder, and referenced by every prompt chain you build. Expect to refine it after the first week of use. The first version always over-weights how you think you write and under-weights how you actually write, so keep correcting it against real drafts until the gap closes.

Step 2. Custom-instruction blocks

Custom instructions are the standing brief the platform injects into every conversation. On ChatGPT they are available on every plan and apply immediately to all chats; the longer form fields have a 1,500 character limit, roughly 250 words, so every sentence has to earn its place. On Claude, the equivalents are project instructions inside a claude.ai project, and in Claude Cowork on the desktop, standing instructions that apply to every session plus folder instructions that add context when you connect a local folder.

One behaviour matters more than any other on the ChatGPT side: inside a project, project instructions apply only in that project and override your global custom instructions. So write the two layers to different jobs. Global instructions carry who you are everywhere; project instructions carry the rules of one workspace. Written that way, they never fight.

Use the fill-in template first, then read the worked example to calibrate the level of specificity that actually works.

About me:
I am a [YOUR ROLE] at [ORGANISATION TYPE, e.g. a large Australian financial services organisation]. My work covers [TWO OR THREE CORE RESPONSIBILITIES]. My main readers are [PRIMARY AUDIENCES].

How to respond:
Write in Australian English. [FORMALITY RULE, e.g. professional but plain; no corporate cliches]. Default to [STRUCTURE PREFERENCE, e.g. conclusion first, then numbered reasoning]. Keep paragraphs short. Never use [BANNED ITEMS, e.g. em dashes, exclamation marks, the phrase going forward].

Standing rules:
1. Ask one clarifying question if my request is ambiguous; otherwise proceed.
2. Flag any factual claim you cannot verify rather than asserting it.
3. Never treat your output as final: end substantive drafts with a short list of what a human reviewer should check.

About me:
I am a compliance manager in the risk function of a large Australian financial services organisation. I test controls, map obligations to business processes, and prepare reporting for governance committees. My readers are senior managers and committee members who want the finding first and the method second.

How to respond:
Write in Australian English. Professional, plain and direct; no hype and no filler. Lead with the conclusion, then evidence, then recommended action. Use numbered lists for findings and actions. Cite the specific obligation, standard or policy clause when one is relevant, and say plainly when you are unsure which applies. Banned: em dashes, exclamation marks, utilise, going forward, touch base.

Standing rules:
1. Distinguish clearly between what a document says and what you infer from it.
2. Never invent regulator positions, citations or dates. If you cannot verify, say so.
3. End every draft with "For human review:" followed by the two or three highest-risk points a reviewer should verify.

Notice what the worked example does not contain: no task, no confidential detail, no politeness padding. Custom instructions are for stable facts and standing rules. Tasks go in individual prompts; knowledge goes in files. That three-way split is the whole discipline.

Step 3. The writing-style file and the source library

The third layer is a small library of markdown files holding the knowledge your instructions cannot fit. Four files cover most professionals:

• writing-style.md: the voice profile you built in Step 1.
• key-sources.md: the documents, registers, legislation and internal pages you rely on, each with a one-line note on what it is authoritative for.
• glossary.md: your organisation’s terms, acronyms and preferred usage, so the AI stops calling a determination a verdict.
• stakeholders.md: your recurring audiences and what each needs. The committee wants the finding first; the operations team wants the steps.

On ChatGPT, upload the library to a Project: Enterprise workspaces support 40 files per project, file types include documents, spreadsheets and text files (which covers markdown), and ChatGPT searches and references what you upload when it answers. On Claude, place the same files in the local folder you connect to Cowork, or add them to a claude.ai project knowledge base, which automatically switches to a retrieval mode on paid plans when the knowledge grows large. Same library, either platform.

Quality in these files means density, not length. A good key-sources.md entry looks like this: "Obligations register (SharePoint, Risk team page): the authoritative list of our regulatory obligations, owners and linked controls. Update cadence monthly. If a draft conflicts with this register, the register wins." One line of description, one line of authority ranking. Ten entries written that way outperform a fifty-page knowledge dump, because the AI can tell what to trust when two sources disagree, and so can the colleague who inherits your setup.

Step 4. Prompt chaining

A single mega-prompt asks the model to research, organise, write and check in one pass, which is where quality quietly dies. A chain breaks the work into steps with a checkpoint after each: research, then structure, then draft, then review. You approve the output of each step before the next begins, so an error in step one never contaminates step four.

The pattern generalises to almost any document. Here is a complete three-step chain that turns a regulator media release into a one-page team briefing. Run it inside your project space so writing-style.md is available to the AI, and paste one step at a time, approving each before the next.

STEP 1 (research)
Here is a regulator media release: [PASTE TEXT HERE]. Extract every factual claim into a list. For each claim, note whether it is a new obligation, a change to an existing position, or commentary. Quote the exact wording of anything that reads like an expectation of regulated entities. Do not add interpretation yet. Wait for my confirmation before continuing.

STEP 2 (structure)
Using the extraction above, propose an outline for a one-page team briefing with these sections: what happened, what changed for us, what we need to do, by when, and open questions. Under each heading, list the extracted points that belong there. Do not write prose yet. Wait for my approval of the outline.

STEP 3 (draft and review)
Draft the briefing following the approved outline and my writing-style.md. Then review your own draft against three criteria: every claim traces to the Step 1 extraction, no obligation is overstated, and every action is specific enough to assign to a person. List anything that fails a criterion and fix it before showing me the final version.

Two habits make chains work. First, forbid the model from running ahead: each step ends by waiting for your approval, which is where your judgement enters the process. Second, make the review step check the draft against named criteria rather than a vague "improve this". A chain with an explicit review step catches most of what a tired human reviewer would miss at 4.55pm on a Friday.

Step 5. Mapping and combining processes

The final step of the universal method is deciding where to aim all this. Inventory your recurring work, score it, and template the top three processes only. Frequency multiplied by time saved, discounted where the cost of an error is high, is the ranking that works: a monthly report that takes four hours beats a daily email that takes four minutes.

Help me inventory my recurring work processes so I can decide which to template for AI support.

Step 1: Ask me to list every task I repeat weekly, fortnightly, monthly or quarterly. Prompt me with categories: documents I produce, meetings I prepare for, reports I assemble, reviews I conduct, and communications I send.

Step 2: For each task, ask me two questions: roughly how long it takes per occurrence, and the cost of an error (low, medium, high).

Step 3: Build a table of task, frequency, time per occurrence, error cost, and a suitability note on how well the task suits AI drafting. High suitability means structured inputs and a repeatable output format; low suitability means heavy judgement calls, sensitive data, or stakeholder nuance.

Step 4: Recommend the three processes I should template first, and explain why. Optimise for time saved multiplied by frequency, weighted down where error cost is high.

Template the winners as prompt chains, save them into your library (an ai-prompts folder, or a single prompt-chains.md), and resist templating anything else until the first three run smoothly. The discipline matters: three working chains change your week; fifteen half-built ones change nothing.

Part 2: Five role playbooks

The universal method gets specific fast once a role is attached. The five playbooks below share one anatomy: a role-tuned interview to gather your context, a project-space blueprint you paste as instructions, a starter pack of markdown files, and two or three prompt chains for the artefacts the role actually produces. Build the playbook nearest your role this week; borrow from the others as your scope grows.

Playbook 1: Workers compensation

Workers compensation is the highest-stakes playbook in this module, because the inputs are personal injury information and the outputs affect entitlements. The payoff is real: determination briefs, RTW plan summaries and file notes are structured, repeatable documents that AI drafts well. The risk is real too, which is why this playbook starts with a rule rather than a prompt.

Interview me one question at a time so you can support my workers compensation practice. Ask:
1. Which scheme and legislation do I work under, and which sections come up most often?
2. Which claim stages and decision points do I handle: initial liability, ongoing entitlements, return to work, disputes?
3. Who reads my work: delegates, injured workers, employers, tribunals?
4. What does a strong determination brief look like in my team, and what do reviewers most often correct?
5. What is my de-identification practice before any material enters an AI tool?
6. Which templates and precedents do I reuse, and where do they live?
Then summarise my answers as folder-ready context notes for my WC project space.

You support a workers compensation practitioner. Context files in this space: writing-style.md, wc-legislation-map.md, determination-brief-template.md, rtw-plan-summary-template.md, de-identification-checklist.md, glossary.md.

Hard rules:
1. All inputs are de-identified. Expect and preserve the placeholders [CLAIMANT_NAME], [CLAIM_NUMBER] and [DATE_OF_BIRTH]. If I ever paste material containing a real name, claim number or date of birth, stop immediately and tell me to de-identify before you do anything else.
2. You draft; you never decide. Frame every output as material for my assessment, not as a determination. Use deterministic language in drafts of decision documents and never present an outcome as if it were yours to make.
3. Every reference to legislation must name the specific section. If you are not certain a section applies, say so and list what needs checking.
4. Follow writing-style.md for tone and structure. Determination briefs follow determination-brief-template.md exactly.
5. End every draft with "For human review:" and the highest-risk points a delegate must verify against the claim file.

Starter pack for the WC space:

• writing-style.md: your voice profile.
• wc-legislation-map.md: the sections you use most, each with a one-line plain-language summary and the tests it sets.
• determination-brief-template.md: your team’s brief structure, headings and evidence table.
• rtw-plan-summary-template.md: the fields a return to work summary must cover.
• de-identification-checklist.md: what gets replaced, with the placeholder for each item.
• glossary.md: scheme terminology and your organisation’s preferred usage.

Chains worth building first:

• Determination brief chain: extract the de-identified evidence and map each item to the relevant legislative test, then structure the brief against determination-brief-template.md and approve the skeleton, then draft in deterministic language with a For human review list for the delegate.
• RTW plan summary chain: extract obligations, milestones and review dates from the de-identified plan, then structure them against rtw-plan-summary-template.md, then draft the summary and flag any milestone at risk.
• File note chain: paste de-identified call or meeting notes, then structure them into facts, actions and follow-ups, then draft the note in your register’s required format.

Playbook 2: Work health and safety

WHS work produces three artefacts on repeat: incident summaries, hazard register updates and toolbox talk outlines. All three are structured documents with known fields, which makes them ideal chain material. The discipline this playbook adds is separating observed fact from inference, because an incident summary that blurs the two is worthless in any later proceeding.

Interview me one question at a time so you can support my WHS practice. Ask:
1. Which WHS legislation and codes of practice apply to my sites, and which duties come up most?
2. Which incident types do I summarise most often, and who reads the summaries?
3. What fields does my hazard register use, and what does a good entry look like?
4. Who attends my toolbox talks, and what format holds their attention?
5. What is my rule for de-identifying injured workers and witnesses before material enters an AI tool?
6. Which templates do I reuse: incident summaries, risk assessments, talk outlines?
Then summarise my answers as folder-ready context notes for my WHS project space.

You support a work health and safety practitioner. Context files in this space: writing-style.md, whs-duties-map.md, incident-summary-template.md, hazard-register-fields.md, toolbox-talk-format.md.

Rules:
1. All incident material is de-identified before it reaches you. Injured workers and witnesses appear as [WORKER_A], [WITNESS_1] and so on. If identified details appear, stop and ask me to de-identify.
2. Incident summaries follow incident-summary-template.md: facts first, sequence of events, contributing factors, actions. Separate observed fact from inference, and label every inference as one.
3. Hazard register entries use the exact field names in hazard-register-fields.md so they paste cleanly into the register.
4. Toolbox talk outlines follow toolbox-talk-format.md: one hazard theme, one real de-identified example, three questions for the crew, under ten minutes of content.
5. Never state that a duty has been discharged or breached. Frame legal characterisations as matters for assessment.
6. End drafts with "For human review:" listing the points to verify against source records.

Starter pack: writing-style.md, whs-duties-map.md (the duties and codes you work under, in plain language), incident-summary-template.md, hazard-register-fields.md (exact field names and allowed values), and toolbox-talk-format.md.

Chains worth building first:

• Incident summary chain: extract the timeline and facts from de-identified reports, then structure them per the template with facts and inferences separated, then draft and review that no legal characterisation crept in.
• Toolbox talk chain: pick the hazard theme and a recent de-identified example, then structure the talk per toolbox-talk-format.md, then draft the outline with three discussion questions for the crew.
• Hazard register chain: extract hazards from inspection notes, then map each to the register fields, then draft entries ready to paste into the register.

Playbook 3: Governance, risk and compliance

GRC work rewards a command centre more than any other role in this module, because its artefacts are dense with citations: control testing summaries, obligation mapping and board paper skeletons all fail on a single wrong clause reference. The blueprint therefore makes verification a standing rule rather than a request, and it forces the distinction between design effectiveness and operating effectiveness that reviewers look for first.

Interview me one question at a time so you can support my GRC practice. Ask:
1. Which obligations and prudential standards does my team own, and which regulators do we answer to?
2. What does my control testing methodology look like: sampling, evidence standards, rating scale?
3. Who reads my reporting: line management, risk committees, the board?
4. What does a strong board paper look like in my organisation, and what gets papers sent back?
5. Which registers do I maintain: obligations, controls, incidents, attestations?
6. Which source documents should the AI treat as authoritative, and in what order?
Then summarise my answers as folder-ready context notes for my GRC project space.

You support a governance, risk and compliance practitioner. Context files in this space: writing-style.md, obligation-register-extract.md, control-testing-template.md, board-paper-skeleton.md, regulator-watchlist.md, glossary.md.

Rules:
1. Precision over polish. Every reference to an obligation, standard or clause must be specific. If you cannot ground a claim in a context file or in material I paste, mark it "unverified" and list what would confirm it.
2. Never invent regulator positions, citations, dates or quotes. This is a hard rule with no exceptions.
3. Control testing summaries follow control-testing-template.md: objective, method, sample, results, exceptions, rating, remediation.
4. Board papers follow board-paper-skeleton.md: recommendation first, then the minimum reasoning a director needs, then appendices. Plain English; assume an intelligent reader with limited time.
5. Distinguish design effectiveness from operating effectiveness whenever controls are discussed.
6. End drafts with "For human review:" naming the claims a reviewer must verify against source systems.

Starter pack: writing-style.md, obligation-register-extract.md (a de-identified slice of the register: obligation, source, owner, controls), control-testing-template.md, board-paper-skeleton.md, glossary.md, and regulator-watchlist.md (which regulators you track and what each has signalled recently).

Chains worth building first:

• Control testing summary chain: extract results and exceptions from working papers, then structure them against control-testing-template.md, then draft with every rating justified and a For human review list of claims to verify.
• Obligation mapping chain: paste an obligation extract, then map each obligation to the business processes and controls that address it, then draft a gap table with owners and next steps.
• Board paper chain: extract findings from the control testing summaries, then structure against board-paper-skeleton.md, then draft with citations back to the obligation register and review against your board’s known send-back triggers.

Playbook 4: Human resources

HR sits closest to the governance guardrails in Part 4, because so much of its raw material is personal information about employees. The playbook splits the work cleanly: structural artefacts (position descriptions, policy comparisons, consultation packs) belong in the project space; case work about named individuals does not enter it at all.

Interview me one question at a time so you can support my HR practice. Ask:
1. Which parts of the employee lifecycle do I own: recruitment, performance frameworks, policy, change, employee relations?
2. Which instruments govern my drafting: awards, enterprise agreements, contracts, policies?
3. Who reads my work: managers, employees, executives, unions, external advisers?
4. What does a strong position description look like here, and what do hiring managers usually get wrong?
5. What is my rule for de-identifying employee information before it enters an AI tool?
6. Which recurring documents cost me the most time each month?
Then summarise my answers as folder-ready context notes for my HR project space.

You support a human resources practitioner. Context files in this space: writing-style.md, pd-template.md, policy-index.md, consultation-pack-checklist.md, glossary.md.

Rules:
1. Employee information is de-identified before it reaches you. Individuals appear as [EMPLOYEE_A] or by role title only. If identified personal details appear, stop and ask me to de-identify.
2. Position descriptions follow pd-template.md and describe the role, never a person. Requirements must be genuine, measurable and free of biased language; flag anything that could operate as indirect discrimination.
3. Policy comparisons present a clause-by-clause table: current wording, proposed wording, what changed, who is affected, transition questions.
4. Consultation packs follow consultation-pack-checklist.md and must be complete before they are polished: scope of change, affected roles, rationale, timeline, feedback channels.
5. Never draft findings about a named individual's conduct or performance. Case work stays out of this space entirely.
6. End drafts with "For human review:" listing the legal and industrial points a reviewer should confirm.

Starter pack: writing-style.md, pd-template.md, policy-index.md (every policy you touch, with its current version date and owner), consultation-pack-checklist.md, and glossary.md covering your instruments and classification language.

Chains worth building first:

• Position description chain: run a short question set with the hiring manager and paste the answers, then structure them against pd-template.md, then draft the PD and run an explicit bias and genuineness check over every requirement.
• Policy comparison chain: extract the clauses from both versions, then build the clause-by-clause comparison table, then draft a one-page briefing on what changed and who needs to know.
• Consultation pack chain: extract the scope and rationale of the change, then structure the pack against the checklist, then draft with every affected role named and every open question listed.

Playbook 5: Leaders

People leaders produce a different artefact set: team communications, one-on-one preparation and decision memos. The command centre earns its keep here on consistency: the same decision-memo skeleton every time makes decisions comparable months later, and a comms rhythm file stops the weekly note drifting in tone. The privacy rule is simpler than HR’s but just as firm: nothing about an individual’s performance, health or personal circumstances enters the space.

Interview me one question at a time so you can support my work as a people leader. Ask:
1. What does my team do, how large is it, and what does success look like this year?
2. Who do I communicate with most: my team, my peers, my manager, executives?
3. Which decisions land on my desk repeatedly, and which are hardest to write up?
4. How do I like to run one-on-ones, and what preparation actually helps?
5. What tone do I want in team communications: direct, warm, formal, brief?
6. Which recurring communications do I send: weekly notes, project updates, recognition?
Then summarise my answers as folder-ready context notes for my leadership project space.

You support a people leader. Context files in this space: writing-style.md, team-context.md, decision-memo-template.md, comms-rhythm.md, achievements-log.md.

Rules:
1. Team members are referenced by initials or role, never by full name, and nothing about an individual's performance, health or personal circumstances enters this space.
2. Decision memos follow decision-memo-template.md: the decision in one sentence, context, options considered, reasoning, risks accepted, and what would change my mind.
3. Team communications follow writing-style.md and lead with what the reader needs to do. One message, one purpose. Cut every sentence that serves the writer rather than the reader.
4. One-on-one preparation draws only on team-context.md and the agenda points I paste in. Produce questions to ask, not conclusions about the person.
5. Recognition drafts must cite the specific work and its effect, drawn from achievements-log.md, never generic praise.
6. End drafts with "For human review:" noting anything a second reader should sanity-check before it is sent.

Starter pack: writing-style.md, team-context.md (what the team does, current priorities, standing constraints), decision-memo-template.md, comms-rhythm.md (what you send, to whom, how often, in what format), and achievements-log.md (a running record of wins, updated weekly, which quietly becomes the best input to recognition, reporting and your own performance review).

Chains worth building first:

• Decision memo chain: paste the context and the options on the table, then structure them against decision-memo-template.md, then draft with the risks accepted stated plainly and a closing line on what evidence would change the decision.
• Team comms chain: state the single purpose of the message and paste the raw points, then structure with the action first, then draft in the register set by writing-style.md and cut it by a third.
• One-on-one prep chain: paste the agenda points and relevant team-context.md extracts, then structure into themes, then draft open questions for each theme rather than conclusions.

A note on combining playbooks: the five spaces share their foundations deliberately. writing-style.md is written once and copied into every space, and glossary.md into every space that works with organisational terminology, so a correction made during the weekly review propagates everywhere on the next sync. If your role spans two playbooks, a WHS practitioner who also manages claims, or a leader who owns an HR portfolio, build two separate project spaces rather than one hybrid. Separate spaces keep the rules clean: the WC space enforces claimant de-identification without exception, and blending it with softer rule sets is how exceptions creep in.

Part 3: The second brain

Everything so far configures the conversation. A second brain goes one layer deeper: it is persistent, organised, retrievable knowledge that outlives any single chat, any project and, if built properly, any platform. Chats are ephemeral. Platform memory features help, but they are platform-bound and largely opaque. A folder of well-organised markdown files is yours, forever, and both major platforms can work from it.

Two frameworks from Tiago Forte give the structure. PARA organises everything you keep into four categories: Projects (short-term efforts with a defined goal), Areas (parts of your work and life that need ongoing attention), Resources (topics you are interested in and learning about) and Archives (inactive material from the other three, kept for reference). CODE describes the flow through it: Capture what is valuable, Organise it into usable pieces, Distil what matters for your current goals, and Express it as output. PARA is the filing cabinet; CODE is what your hands do.

Here is a concrete PARA tree for a compliance professional. The numbers force the sort order, the inbox gives capture a home, and the ai-prompts folder keeps your chains inside the system they serve.

second-brain/
  00-inbox/                 capture: unsorted notes, clippings, meeting scraps
  10-projects/
    cps230-gap-review/      active engagement with an end date
    q3-board-paper/
  20-areas/
    control-testing/        standing responsibility
    obligation-register/
    team-management/
  30-resources/
    regulator-guidance/     reference notes by topic
    ai-prompts/             your prompt chains and templates
    glossary.md
    writing-style.md
    key-sources.md
    stakeholders.md
  40-archive/
    2025-completed/         closed projects, kept searchable

Build A: the ChatGPT Enterprise path

ChatGPT has no local-folder mount, so the second brain lives as a folder on your machine and mirrors into Projects. Create one project per major Area or live Project, and upload the relevant slice of your tree: Enterprise supports 40 files per project, with unlimited projects and up to 10 files per upload batch. Set the project instructions to name the uploaded files and what each is authoritative for, and ChatGPT searches and references them when answering.

Memory needs one deliberate decision at project creation: default memory or project-only memory. In Enterprise and Edu workspaces, project chats are contained within the project either way; they cannot reference conversations outside it, and outside conversations cannot reference them. Sharing a project with your team switches it to project-only memory automatically and permanently, and shared projects never access any member’s personal memories or custom instructions. For a second brain, that containment is a feature: each project accumulates its own working context without bleeding into the rest of your account.

The one operational habit this path demands: the local folder stays the source of truth, and the project holds a mirror. When a file changes, re-upload it. Fold that into the weekly review below and the mirror never drifts far.

Build B: the Claude path (Cowork plus Obsidian)

Claude Cowork removes the upload step entirely. Cowork reads from and writes to files in folders you connect, so you point it at the second-brain folder and it works on the files in place: reading your sources, drafting new documents into the right subfolder, updating your logs. It runs on the Claude Desktop app (macOS, Windows, and Linux in beta) on paid plans, the app must stay open while it works, and folder instructions carry the standing context for the folder, which Claude can update itself during a session. Cowork projects bind a folder, instructions and memory together, with memory scoped per project and stored locally.

Pair the folder with Obsidian and you get a proper reading and linking interface over the same files. Obsidian stores notes locally as plain-text markdown, is free without limits for personal use, and has been free for commercial use since 20 February 2025, with the commercial licence now an optional way to support development. Make your Obsidian vault the same folder Cowork connects to: because the vault is just plain-text files, Cowork reads and writes it directly, while you browse, link and search it in Obsidian. Two tools, one set of files, no sync step.

If you work on Claude through the browser rather than the desktop app, claude.ai projects are the fallback: upload the relevant slice of your tree as project knowledge, set project instructions, and let the automatic retrieval mode handle scale. Memory on claude.ai is available on every plan, with a memory summary synthesised from your chats and a separate memory space per project, so each workspace accumulates its own context there too. The trade-off against Cowork is the same as ChatGPT’s: uploads instead of a live folder, so the weekly re-sync habit applies.

The weekly rhythm

A second brain decays without maintenance, and the fix is older than AI. David Allen’s Getting Things Done names the weekly review as the critical behaviour that makes personal organisation real, done at least once a week. Tiago Forte rebuilt it as a 15 to 30 minute operating system for digital work. Adapted for the command centre, the checklist is:

1. Capture: sweep loose notes, downloads and meeting scraps into 00-inbox, then empty the inbox into the right folders.
2. File: move new documents into projects, areas or resources; delete duplicates and dead drafts.
3. Update: add the week’s wins to achievements-log.md if you keep one (the performance review module, LM-S02, builds a full system on that file); correct key-sources.md and glossary.md if anything changed.
4. Archive: move finished or stalled projects to 40-archive so live folders stay lean.
5. Re-sync: re-upload changed files to your ChatGPT projects; the Claude folder needs no sync step.
6. Refresh (monthly): skim writing-style.md against your latest approved drafts and correct any drift.

Thirty minutes on a Friday afternoon keeps the whole system honest. Skip it for a month and the glossary is stale, the inbox is a landfill, and the AI is confidently citing last quarter’s version of your sources.

Part 4: Governance and privacy guardrails

The command centre only works if it is defensible, and defensibility rests on three rules. Rule one: workplace data belongs in employer-approved enterprise tools, never in personal consumer accounts. The enterprise tier is not a cosmetic upgrade; OpenAI does not train its models on ChatGPT Enterprise business data by default, covering conversations, uploaded files and project content, and workspace admins control retention. Claude’s Team and Enterprise plans carry their own organisation-level admin controls over capabilities and connectors. But contractual and technical controls are configured by your organisation, not by you, so the practical rule is simple: check the approved-tool list and your organisation’s AI policy before you build anything in this module, and build inside whatever it approves. When you read the policy, look for four specific answers: which tools are approved, which data classifications may enter them, whether AI-assisted outputs must be disclosed or labelled, and who signs off on new use cases. If the policy is silent on any of these, ask the question in writing before proceeding rather than after.

Rule two: de-identification is a default habit, not a WC-only rule. Any individual’s personal information (a worker, an employee, a complainant, a customer) gets placeholders before it enters an AI tool, even an enterprise one, because training exclusion reduces one risk while the disclosure itself remains another. The habit costs seconds and removes an entire category of exposure.

Rule three: verification is part of the job, not an optional extra. Every blueprint in Part 2 bans invented citations and forces unverified claims to be labelled, and every chain ends with a review step against named criteria. Keep those lines in your instructions even when they feel repetitive. They are the difference between a command centre a risk function can sign off and a productivity hack it has to shut down.

What you have built

Finish this module’s exercises and you own a working command centre: a voice profile compiled from a real interview, custom instructions that carry your standing rules into every chat, a markdown library any platform can read, chains for your three highest-value processes, a role project space with de-identification built into its instructions, a second brain organised by PARA and maintained by a weekly review, and guardrails a risk function would recognise. The blank chat box is gone, and everything you configured is in plain-text files you control.

The 30-question assessment below tests the method, the platform mechanics and the guardrails. Take it now, note the tier you land in, and come back after four weeks of running the system to see how far the practice has moved you.