AI Projects

A quality AI Project is the container for one workstream: standing instructions, attached sources, and the decisions that still apply. A chat is a working session. It is not the archive.

When you ask for the current stance on tone, scope, or facts, the answer should cite the instruction file and the files sitting in the project. If a source is not attached, that part of the answer stays empty. The model should not complete the sentence from a prior chat, from a document nobody uploaded, or from a decision that was never written down.

ChatGPT, Claude, Gemini, Copilot, and Notion all offer some form of this container: a project, a page, a custom assistant, or a workspace with pinned files. Treat them as AI assistants that can hold context, not as a ranked list. The workstream needs one home. New threads start there.

The usual failure is treating a one-off chat as the project of record. A strong draft in an untitled thread feels finished. A week later nobody can say which file was cited, which version won, or whether the decision in that thread was accepted. Chat history is a trail of attempts. The project is what you update when an attempt becomes a decision.

Give the workstream a name a colleague would search for. "Q3 pricing notice" beats "AI help" or "drafts". The name is the index. A vague name trains people to open a blank chat instead of the existing project.

After the name exists, attach only the sources this workstream is allowed to cite: the current policy, the approved table, last year's published notice, a stakeholder list. Do not dump a folder of maybe-useful files. Extra files invite the model to quote a draft you already rejected.

If the source still lives in email or in someone else's drive, the project does not contain it. Leave that gap visible. Inventing a file that was never attached is a quality failure. Asked as if a retention schedule exists, the model will describe one. Your instructions should make that move illegal: only attached files count as sources, and a missing file produces a blank, not a guess.

Reusable citation rules can live in AI Skills and get pasted into many projects. Skills do not replace the attachment list for this workstream.

The instruction file is the standing brief. Write it as rules, not as a persona.

State the workstream in one sentence. State the audience. State what done looks like: a draft that cites the instruction file and the attached sources, with empty sections where a source is missing. State what the model must not do: invent a decision from a prior chat, cite a document that is not attached, or fill a blank so the page looks complete.

Keep the file short enough that you will edit it. A long manifesto goes stale. A one-page rule set gets updated when the decision changes.

You own the workstream named Q3 pricing notice. You attach three sources: the approved pricing table, last year's published notice, and the legal review checklist. The instruction file says: write the customer email from those three sources only; take every price from the table; reuse last year's structure unless the checklist forbids a line; if the table has no row for a plan, leave that plan's price blank and flag it; ignore any stance from chats that happened before this project existed.

You start a chat inside the project and ask for a first draft. The draft cites the table and last year's notice. The enterprise add-on has no row in the attached table, so that paragraph stays empty with a flag. The empty paragraph is the quality signal. A fluent paragraph with a made-up price would be a defect, even if it reads well.

Start the session from the project, not from the global new-chat control. The project should load the instructions and the file list before your first message. A thread started outside the project has none of that, even if you remember the workstream's name.

If you explore in a scratch chat, copy anything you keep back into the project as an attached source or as an edit to the instruction file. Do not leave the winning paragraph only in a private thread. Colleagues should open the project rather than forwarding a chat export. An export is a snapshot. The project is the live set of files and rules.

Some assistants reach live systems through MCP instead of static uploads. Use that when the source of record is a ticket, a doc, or a datastore you do not want to duplicate. The citation rule does not change: if the tool did not return the record, the field stays empty.

AI time tracking can show which workstream used the week. Name the project so time lands on Q3 pricing notice, not on chatting with the assistant.

Ask in a form that can be empty. List the sources you used, then write the notice. If a required source is not in the project, leave that section blank.

If the model cites a file you never attached, fix the project, not only the paragraph. Attach the file, or add a line to the instructions that the document is out of scope.

If the model recycles a decision from an earlier chat that never reached the instruction file, treat that as contamination. The chat is not the log. If the decision is real, write it into the instruction file. If it is not, say so in the next message and leave the field blank.

The third failure mode is never updating instructions after a decision. The team agrees the notice will not mention grandfathered plans. That agreement happens in a meeting or a thread. If nobody edits the instruction file, the next chat mentions grandfathered plans again, because last year's notice is still attached and the old structure still applies. The owner of the project makes the edit. Ownership is a person, not the model.

The owner updates the project. That rule keeps the container honest.

When a decision lands, change the instruction file the same day. Write it in a form the model can cite: do not mention grandfathered plans; decision dated 12 June; owner is the comms lead. Attach the new source if the decision replaced a file. Remove or mark stale files so they are not cited. Do not wait for a cleanup pass. The next chat will run before then.

Review the file list when the workstream changes phase, from research to draft, from draft to legal, from legal to send. Later phases often need fewer files, not more. Archive the project when the workstream ends so nobody treats it as current. A finished project that still accepts chats will keep producing current-sounding drafts from last quarter's table.

A healthy project passes a simple test. A new chat, started inside the project, cites the instruction file and the attached sources. Empty stays empty if a source is not attached. Nothing is invented from a prior chat. The owner still updates the project when the workstream changes.