T02-L02

Chat & assistants · Power user

Your daily driver: files, projects and memory

This mini-book is for Level 2 Power user. Your setup now influences documents that colleagues may read or reuse. A stale instruction, mixed-up client detail, or wrongly shared file therefore has a wider blast radius than a private chat.

Level
Power userLevel 2 of 5
Curriculum position
Family 1 · Track 02
Reading time
21 minutes
Reading progress
0%Time on this book
Last revised
Sep 5, 2026

This mini-book is for Level 2 Power user. Your setup now influences documents that colleagues may read or reuse. A stale instruction, mixed-up client detail, or wrongly shared file therefore has a wider blast radius than a private chat.

2. The assistant remembers the wrong project

You start Monday by pasting the same background into a new chat: the purpose, preferred style, glossary, source files, and last week's decisions. By Wednesday, you have five chats with slightly different versions of that context. One answer follows an old decision. Another borrows wording from an unrelated task. A third cannot support a claim because the source was pasted two conversations ago.

A colleague avoids the repetition by putting everything into one enormous workspace. That feels efficient until a draft for Client North contains a detail from Client South—or a manuscript revision treats an old running note as current evidence.

The useful middle ground is a bounded project: one workspace for one job, with separate places for instructions, sources, current notes, and conversations. Memory can preserve preferences, but it is not evidence and it is not automatically confined in the way you expect. You must choose and test the boundary.

3. After this you can

  • Organise a project around uploaded files instead of repeatedly pasting source text.
  • Separate behavioural instructions, factual sources, working notes, and memory.
  • Test whether unrelated context appears inside a new project.
  • Remove stale decisions before they influence another deliverable.
  • Decide whether an aggregator solves a real switching need or adds another unnecessary account.

4. Prerequisites

  • T02-L01 · Getting good answers.
  • T12-L01 · What you may paste.
  • An approved assistant that supports projects, workspaces, or a similar grouping mechanism.
  • Three short synthetic, public, or explicitly approved files.
  • Permission to inspect the account's memory, sharing, retention, and data-use settings.

Do not use real customer files, participant or patient data, unpublished results, credentials, regulated records, or confidential contracts for this exercise.

5. The idea in one page

A durable workspace has four clearly different layers.

LayerPut hereKeep out
InstructionsPurpose, audience, output shape, exclusions, review ownerProject facts that change frequently
SourcesApproved documents that support the answerBehavioural rules hidden inside evidence files
Working notesDated decisions, open questions, temporary terminologySuperseded decisions without a warning
MemoryLow-risk preferences that genuinely help across chatsFacts that require a source; secrets; client-specific details

A project boundary is not automatically a privacy boundary

Putting files in a named project does not by itself answer who can access them, how long they remain available, whether connected applications can use them, or whether account-wide memory can carry context elsewhere. Those behaviours vary by provider, plan, workspace administration, and current settings.

Before uploading anything, check four things in the current primary documentation and in your account:

  1. who owns and administers the workspace;
  2. who can see a shared project or link;
  3. how uploaded files, deleted chats, and memory are retained;
  4. whether the content may be used beyond providing the service.

An upload is evidence access, not proof of understanding

An assistant may summarise, compare, extract, or transform uploaded files. It may still miss a table, misread a figure, ignore a late appendix, or lose a qualification during compression. Ask a few questions whose answers you already know. Require supporting passages. If a file matters to the final output, verify the relevant part yourself.

Memory is continuity, not authority

Memory can save a preferred tone or recurring format. It can also preserve an obsolete deadline or a detail that belongs to another context. Treat remembered information as a suggestion. Current project sources and dated decisions outrank it.

Decide on aggregators by observed use

An aggregator offers access to multiple models or capabilities through one account. That is useful when you genuinely switch often and the combined workflow satisfies your organisation's data rules. It is weak value when you use one model for nearly every task. It also introduces another provider relationship, policy, interface, and possible duplicate subscription.

For two weeks, record which capabilities you actually use. Compare direct and aggregator options on switching frequency, file handling, sharing, administration, data policy, and total account burden. Do not decide from a long model catalogue.

6. The worked example: one bounded workspace

The interface labels differ between products, but the configuration should remain recognisable. Create a project, add three synthetic sources, add one instruction set, run a known-answer test, and inspect the context controls.

Lab framing: Synthetic Manuscript M-17

Create three small files:

manuscript-draft.md

Project: Synthetic Manuscript M-17
Current section: Methods
Claim status: all scientific claims require a supplied source
Target reader: a researcher outside the immediate group

style-guide.md

Use direct sentences. Preserve units exactly. Do not replace a precise
condition with “approximately”. Mark missing support as [confirm].

running-notes.md

2026-08-28 — Use “reference condition”, not “control condition”.
2026-09-03 — The planned submission date was withdrawn; no date is approved.

Name the workspace Synthetic Manuscript M-17. Attach the files as sources. Put these rules in the project's instruction field rather than a source file:

Purpose: support revision of Synthetic Manuscript M-17.
Use only attached project sources for factual claims.
Preserve scientific meaning, numbers, units, and uncertainty.
Mark unsupported additions [confirm].
Return a proposed revision followed by a short change log.
Do not invent citations, results, authors, or submission dates.
The workspace owner reviews every proposed revision before reuse.

Run a known-answer request:

What submission date should the revised paragraph state? Quote the source.

The passing answer says that no date is approved and points to the 3 September note. A confidently invented date fails the workspace test.

Now add a deliberately stale note saying Submission: 30 September. Ask again. The conflict demonstrates why notes need dates and why superseded instructions must be corrected or removed, not merely buried under newer context.

Company framing: Synthetic Client C-04

Use the same structure with three synthetic files.

client-brief-c-04.md

Project: Synthetic Client C-04
Completed: navigation draft and two test pages
Open: mobile review and accessibility check
Decision needed: choose one of two fictional colour directions

approved-terms.md

Approved wording: “prototype review”
No delivery date is approved.
No commercial or contractual terms are included in this fixture.

meeting-notes.md

2026-08-27 — Earlier planning note mentioned 30 September.
2026-09-03 — 30 September was withdrawn; report no approved delivery date.

Configure this instruction set:

Purpose: support internal reporting for Synthetic Client C-04.
Use only attached project sources.
Separate completed work, open checks, and decisions needed.
Mark missing facts [confirm].
Do not send, publish, promise delivery dates, or infer contract terms.
The account owner approves every client-facing output.

Ask for a three-bullet status update, then ask What delivery date is approved? Quote the source. The passing response states that no date is approved and cites the 3 September note. Check every bullet against the files. A colleague may see the resulting draft, so one unsupported promise already exceeds the personal blast radius of Level 1.

Test the boundary

After either framing, open a separate empty chat or project. Ask for the synthetic project name and the obsolete decision without supplying context. The desired result is that the assistant does not reveal or confidently reconstruct the project details. This is only an observed test, not proof of every provider-side boundary. Record the account and memory settings you inspected.

7. What goes wrong

One workspace contains every job

Symptom: unrelated clients, manuscripts, and writing styles appear in the same answers.

Fix: split workspaces by purpose, audience, and data boundary. Archive completed work rather than turning the active workspace into a permanent attic.

Instructions are hidden inside source files

Symptom: a formatting note competes with factual evidence, or an old document silently changes current behaviour.

Fix: keep stable behavioural rules in the instruction field and facts in source files. Review both separately.

Memory is treated as a source

Symptom: the assistant repeats a remembered decision without showing current evidence.

Fix: ask for the supporting project source. If the decision is important, record it in a dated file and remove stale memory.

Upload means “the tool read everything”

Symptom: a summary omits a table, appendix, exception, or scanned page.

Fix: test representative sections and request supporting passages. Inspect the original file before sharing the output.

The workspace feels internal

Symptom: sensitive material is uploaded without checking sharing, retention, connected apps, or organisational approval.

Fix: apply T12-L01 before upload. A friendly interface is not a security classification.

Symptom: someone outside the intended group can open the project or a generated artifact.

Fix: inspect members, links, inherited permissions, and connected services. Test with an account that should not have access.

An aggregator becomes an expensive shortcut

Symptom: you pay for broad choice but use one capability and maintain duplicate accounts.

Fix: use a two-week activity log. Keep the aggregator only if repeated switching or consolidation produces a visible benefit.

8. Do it yourself: configure and test in 30 minutes

Minutes 0–5: choose one bounded job and give it a synthetic project name. Write one sentence describing its purpose and one sentence describing what does not belong.

Minutes 5–12: prepare three short files: a primary source, a style or policy source, and dated running notes. Remove all real sensitive information.

Minutes 12–18: create the project, attach the files, and add instructions covering purpose, source boundary, output shape, exclusions, and review owner.

Minutes 18–23: run one known-answer question and one missing-answer question. The second should produce [confirm] or an equivalent explicit gap, not an invention.

Minutes 23–27: inspect memory, sharing, connected applications, retention guidance, and workspace membership. Turn off or narrow anything the task does not require.

Minutes 27–30: capture the configured state. Recheck the screenshot for filenames, account details, notifications, browser tabs, or other accidental disclosure.

9. Exit check

Deliver exactly one artifact: one evidence screenshot showing the configured project name, its bounded purpose, the three attached synthetic sources, the visible or opened instruction set, and the passing known-answer result.

Add the provider, account or workspace type, capture date, and settings checked to the screenshot's caption or annotation. The screenshot fails if it contains real personal, client, laboratory, regulated, or credential data.

10. Rule to remember

One workspace, one job.

11. Further reading & tools