About Platform Resources Articles Contact
About Platform Resources Articles Contact
IMA AI  ·  Resources

The AI Project
Context Standard

How to make AI agents actually follow your company standards — across every project, without anyone remembering the rules.
Version v1.0
Date June 2026
Free No form. No email.
The Problem

Documented standards are not followed standards.

Most companies adopting AI agents write their rules into documents. Then they discover the uncomfortable truth.

An AI session only obeys what is in its context. If your rules live in a wiki the agent never loads, they do not exist. If they live in per-project instruction fields you maintain by hand, every copy drifts — we have watched two hand-maintained copies of the same rule disagree within weeks. And when rules depend on the session "remembering" to check them, they fail exactly when it matters.

We run an entire company — products, client work, marketing sites — with AI agents doing the work. This standard is how our rules survive contact with reality.

The Principle

Three rules drive everything.

Rule 1Instructions are files, not settings.
Anything an AI session must obey lives in a version-controlled instruction file inside the repo — diffable, reviewable, synced. App-level instruction fields are pointers only. A setting you cannot diff, review, or sync is not a standard — it is a hope.
Rule 2One master, synced outward.
Shared rules are written once, in one place, and propagated mechanically. Never maintain the same rule in two places by hand. Two hand-maintained copies of a rule will disagree. It is not a question of if — it is a question of when, and whether you notice before the damage compounds.
Rule 3The session must carry the rules without anyone remembering them.
Your AI tool auto-loads the repo's instruction file — that file is your enforcement surface. If a rule requires a human to remember to mention it, it is not a rule. It is a suggestion with a failure mode.
The Architecture

The three layers.

Every AI-governed project at IMA AI operates on three layers. They never overlap, and each has one job.
Layer Lives in Contains Maintained by
1 — Pointer The AI tool's project-instruction field One line: "This project = X. Follow the instruction file in the repo — it is the source of truth." Set once. Never edited again.
2 — Instructions Instruction file in the repo A synced standards block + project-specific rules The AI agent, via your edit flow
3 — Knowledge Your knowledge base The actual specs, decisions, build logs The AI agent, per your KB rules

A session reads layer 1, loads layer 2, and is directed to layer 3. When a rule changes, you change it once in the master — it syncs into layer 2 — and layer 1 never changes again.

The Core Mechanism

The synced standards block.

The heart of the system. Every repo's instruction file opens with a generated block between markers.
<!-- STD-START v1.0 · synced from <master> on <date> · do NOT hand-edit -->
…file-edit flow · integrity guards · secrets rule · which standards apply to THIS repo…
<!-- STD-END -->
RulesHow the block works
Generated, never hand-edited inside a repo. If you edit the block directly in a project, your change disappears on the next sync — and you will not notice until the discrepancy causes a problem.

Version-numbered. The block carries a version number so any session can immediately see whether its copy is stale.

Project-specific rules live outside the markers. They belong to the project and are not touched by the sync.

When the master changes, bump the version and replace the block in every repo — mechanically, in the same session as the change. Not next week.
Block Contents

What goes in the block.

Four things. All four, every repo. No exceptions.
1The file-edit flow
How the agent edits and ships safely in this repo. The exact commands. The exact sequence. Every session reads this before touching a single file — it is why the same agent can walk into 12 different repos and edit them all correctly without a briefing.
2Integrity guards
Mechanical, hard-stop checks run before every commit. Ours: a truncation check (a silent truncation bug corrupted four files in one incident before we formalised this) and a secret scan (a real credential was committed before the scan was mandatory). Any hit blocks the commit — no judgment calls, no "it's probably fine."
3The secrets rule
Never commit a real credential. Placeholders only in the repo. Live values in one gitignored store. Every session reads this rule whether it needs it this session or not — because the session when it matters most is the one where you are in a hurry.
4The applies-to list
Which of your standards bind this repo — so the session loads the right ones. A marketing site loads the brand standard, the asset-naming standard, the website-build standard. A product backend loads the database standard, the auth standard, the deploy runbook. The list makes the loading automatic and verifiable.
The Template

The instruction file template.

Every project's instruction file follows this structure. Sections 1–3 and 8 are the ones most likely to drift — review them whenever you re-enter a project.
1. Title + what this project is (2–3 lines)
2. Read-first list         — which knowledge-base files to load, every session
3. Current state + resume  — what is shipped (do-not-redo) and what is next
4. SYNCED STANDARDS BLOCK  — between markers, generated
5. Folders & write permissions
6. Project-specific hard rules — the non-negotiables, condensed
7. Deploy command (if applicable)
8. On completion: update the knowledge base — keep the spec current
A stale instruction file is the same failure as a stale spec. Update the current-state section (section 3) whenever the project moves. If the session has to re-discover what was already done, time was wasted and risk was added.
Multi-Repo

When one project spans several repos.

Each repo keeps its own instruction file — never merge them, or the sync ritual breaks. The pointer names every repo and tells the session: read the instruction file of the repo you are touching, before any work.

The key discipline: the session knows which repo it is in before it does anything. The instruction file for that repo is the one that governs it. Cross-repo work is handled by the routing standard — see the companion resource below.

Enforcement

Measuring compliance.

What gets measured gets followed.

Keep one compliance matrix in your standards index: rows = projects, columns = key standards, cells = pass / partial / gap, with the date last audited. Re-audit a project whenever you enter it for other work, or monthly.

Our first audit surfaced gaps the documentation alone had hidden for weeks — including a credential committed to a repo and a deploy pipeline that violated its own standard. Both were caught before they caused real damage, but only because the matrix made the gap visible. Without it, they would have sat there quietly until they did not.
Starting Right

New project checklist.

1Create the repoWith an instruction file per the template. Copy the synced block from any current repo and verify it is the latest version before you start.
2Register the repoIn your standards index and compliance matrix. A project that is not in the matrix is not being governed.
3Decide the applies-to listWhich standards bind this repo. That list becomes the block's applies-to section.
4Set the pointerThe tool's project-instruction field: one line, points at the repo's instruction file. Done — never touch it again.

Built for founders and teams running multiple projects with AI agents in Malaysia — anyone who has discovered that writing a standard and having it followed are two different problems.

Free. No form. No email.

Companion Resource

Where work goes between projects.

This standard governs how rules stay consistent inside each project. The companion standard covers the other half: how work moves between projects — without you becoming the courier between your own AI sessions.

Pair with this
The AI Work Routing Standard
Where AI work should happen — and how it moves between projects without you becoming the courier. 1 hub. 2 artifacts per handoff. 1 sentence to pick it up.
Read the standard →