Use ChatGPT Projects to Keep the Review Standard Visible

A recurring ChatGPT Project can save setup time, but persistence creates a new problem: instructions, reference material and today’s request can blur into one long context. When that happens, a good result may depend on an old file, a hidden assumption or a quality rule that nobody can find.

Use three visible layers instead. Put the stable review standard in project instructions. Keep current evidence in project sources. Put the task for this run in a fresh chat. The structure is simple, but it answers a crucial maintenance question: when something changes, which layer should you edit?

Why the review standard belongs in its own layer

OpenAI’s current Projects guidance says a project can keep chats, files and instructions together for ongoing work. Files provide reference material; project instructions apply inside that project and override global custom instructions. That makes Projects useful for recurring work, but the product does not decide which information should remain stable.

The most durable content is usually the rule for accepting the work. A review standard might require every material claim to point to a source, every uncertainty to be labelled and every decision to remain with a named person. Those rules should survive a new evidence pack and a new weekly request. If they sit only in last week’s prompt, they are easy to lose.

Decide what goes where before you upload anything

The separation also prevents a common form of context debt. A project grows because everything useful is added, but little is retired. More context then looks like more capability even when the active source set contains contradictions. A small, owned pack is easier to review than a project that has become a filing cabinet.

Worked example: a weekly supplier-risk brief

Imagine a procurement manager produces a weekly supplier-risk brief. The output must fit on one page and support a decision about which suppliers need follow-up. The recurring work uses a current supplier status export, the approved risk policy and notes from open cases.

The project instructions hold the stable review standard: separate facts from interpretation; cite the source document and date for every red flag; mark missing evidence; never recommend suspension automatically; route a high-risk case to the named procurement owner. These rules describe how the result will be judged, not what happened this week.

The project sources hold the latest status export, current policy and approved case notes. If the risk policy changes, replace the policy source and record the effective date. If the acceptance test changes—for example, every warning now needs a counter-evidence check—edit the project instructions. If the manager only wants a brief for France by Thursday, put that in the new chat.

Use three different change triggers

A project stays trustworthy only when each layer has a clear trigger. Review the standard when the business decision, risk tolerance or approval route changes. Review the sources when a file expires, a policy is replaced or a new data period begins. Start a new request whenever the audience, scope or deliverable changes.

Do not treat project memory as evidence. Earlier chats can be useful context, but a decision-critical claim still needs an identifiable current source. Likewise, a polished output is not proof that the source pack is complete. The reviewer should be able to see which layer supplied the rule, the evidence and the immediate task.

Connect the project to the wider workflow

A Project is a context container, not the whole operating process. The prompt, project or workflow guide helps choose the right container. The clean-context drill tests whether a method can travel without hidden support. The separate acceptance test shows why checking rules should remain distinct from generation.

Bokili’s short, tool-specific missions help employees practise choices like these on realistic work. The point is not to memorise where a setting lives; it is to build a repeatable habit for context, sources and review.

Keep the standard stable, not invisible

ChatGPT Projects are valuable because they keep useful context together. Good project design also keeps different kinds of context apart. Give the review standard a stable home, keep evidence current and make each request explicit. Then a recurring task becomes easier to maintain, easier to hand over and easier to trust.