How we build

Context is readable. Control is compiled.

How Simple Intelligence applies selected principles from Interpretable Context Methodology, and where that method stops and enforcement has to take over.

Methodology note

ICM was developed by Jake Van Clief and David McDermott. Simple Intelligence Group did not originate the methodology.

Ameer Abdur-Razzaaq participates in their ICM learning community and is studying the methodology through their teaching. Simple Intelligence Group applies selected ICM principles to product context design, source authority, reviewable intermediate work, human approval, provenance, and traceability.

Participation does not imply certification, endorsement, partnership, or an official ICM Architect designation.

Primary paper: Interpretable Context Methodology: Folder Structure as Agentic Architecture, by Jake Van Clief and David McDermott.

Here for the products rather than the method? See the portfolio, or read how this shows up in them.

What ICM is

ICM treats the structure a piece of work sits in as part of the architecture rather than as filing. Work is broken into named stages. Each stage declares what it may read, what it must produce, and where its output goes next. Reference material is kept separate from working artifacts, so an agent reading a stage's inputs is not also reading everything else the project has ever touched.

The consequence a reader should care about is that the intermediate work stops being invisible. A stage that has to hand its successor a named artifact produces something a person can open, disagree with, and send back. That is a different property from a system that produces a good final answer, and it is the property a regulated buyer is usually asking about.

The authors describe the method, its lineage, and its limits far better than a summary can. The paper is linked at the bottom of this page and it is worth reading before taking our description of it as complete.

Why bounded context and stage contracts help

An agent given everything has no basis for deciding what matters, and the failure is quiet: it produces something plausible built on the wrong input, and nothing in the output says which input it used. Bounding what a stage can see turns that into a question with an answer. If the output is wrong, the inputs it was allowed to read are a short, named list, and the fault is somewhere a person can look.

A stage contract does the same for the output. A stage that must produce a named artifact in a stated shape can be checked mechanically before anything downstream consumes it. A stage that merely produces text can only be judged after the fact, by whoever notices.

Where a person approves

The portfolio rule is that every multi-step workflow declares where its human review point is, before anything reaches production. That declaration is part of the design of the workflow, not a confirmation dialog added at the end. It is the same idea the diagram on our homepage draws: the work is prepared, it becomes a reviewable artifact, a person approves it, and only then does it reach execution, evidence, and an outcome.

Placing the seam is a design decision with a cost either way. Too early and the person is approving something too vague to judge. Too late and they are approving something already half-done. Making it an explicit part of the workflow is what forces that decision to be made deliberately rather than inherited from whichever screen happened to have a confirm button on it.

How work becomes approved

From an authorized source to an approved output

Interpretable Context Methodology is about where an agent's material comes from, what standing its output has, and who is allowed to change that standing.

In sequence: Authorized source, then Governed reference, then Working artifact, then Human review, then Approved output, then Evidence, recovery, or escalation.

  1. Authorized source

    A place the person already has permission to read. The permission comes from the source system, which means revoking it there revokes it here. Nothing about this method creates access that the source does not grant.

  2. Governed reference

    The agent works from a reference to that source rather than from a private copy of it. The reference records what was read and under whose authority, which is what makes the rest of the chain traceable later.

  3. Working artifact

    What the agent produces starts as Working. Agents normally produce Working and Review artifacts and stop there. Where a file happens to sit is not a decision anybody made about it, so placement alone is not approval.

  4. Human review

    A person reads the artifact and the references behind it. Changing Context, which is the material other work gets built on, requires explicit human approval and is not something an agent does on its own initiative.

  5. Approved output

    Only authorized people promote work to Approved or Published. The promotion is the act that changes an artifact's standing. It is a decision with an author, not a side effect of where something was saved.

  6. Evidence, recovery, or escalation

    The promotion and its author are recorded, and the artifact still points at the references it was built from. That is what lets somebody find the work that depended on a source after the source changes or its permission is withdrawn.

These are the stages of a working method rather than the steps of a running system, so they have no availability state. Whether any given product implements a stage is a fact about that product, and each product page carries its own diagram for that.

ICM guides context, provenance, lifecycle, traceability, and human review. It does not replace a product's database, its tenant isolation, its MCP audit, its compiled controls, or its approval enforcement. Those are product mechanisms, and ICM does not stand in for any of them.

The human decision in this sequence

What a person reviews
The working artifact, together with the references it was built from.
What gets approved
That artifact in the version being read. Promotion applies to a version. It does not apply to a folder, and it does not apply to the agent that produced it.
What approval makes possible
Promotion to Approved or Published, which is what allows other work to be built on top of it. Only authorized people can perform that promotion.
What invalidates it
A changed artifact is no longer the artifact that was approved. A source permission that is withdrawn removes the authority the reference depended on, and the work that cited it inherits that.
How failure is detected
Work that cites a reference which no longer resolves, or a source whose permission has been revoked, is findable precisely because the citation was recorded at the time rather than reconstructed afterwards.
Recovery and escalation
The work returns to Working and is rebuilt from a source the person is still authorized to read. Escalation goes to whoever owns that source, because they are the only one who can restore the access or confirm it should stay revoked.

Why readable context does not replace compiled enforcement

This is the part of the page that matters most, and it is the part most likely to be skipped. A readable structure is a description of intent. It is not a control. A file that says a stage may only read two inputs does not stop a process from reading a third. A document that names an approval seam does not stop a write that skips it.

Enforcement has to live where it cannot be talked out of: in the query layer, in middleware, in the type system, in database constraints, in the identity provider. In our products that means tenant isolation enforced on every query rather than declared in a document, authorization checked server-side rather than by hiding rows in the interface, and approval recorded as a row rather than as a note.

So the two do different jobs. ICM makes the work legible to a person reviewing it. Compiled controls make the work safe when nobody is reviewing it. A system with only the first is auditable and unsafe. A system with only the second is safe and opaque, which is its own problem when somebody has to explain a decision to a regulator.

What ICM influences here

Context selection
Deciding what a stage is allowed to see, rather than handing an agent everything and hoping relevance emerges.
Source authority
Naming which artifact is authoritative when two disagree, before they disagree.
Stage contracts
Writing down what a stage takes in and what it must produce, so a stage can be checked rather than trusted.
Reviewable artifacts
Making the intermediate work a thing a person can open and read, not a hidden step between a request and a result.
Human seams
Placing the approval point deliberately and in one identifiable place, instead of scattering confirmations.
Provenance and traceability
Recording that a record came from a model, how confident it was, and what it reasoned, on the record itself.

What it does not replace

None of the following is provided by, or substituted by, a context method. Each is built, tested, and enforced independently:

  • Multi-tenant product databases
  • Tenant isolation
  • Entra identity
  • Product-embedded MCP servers
  • Compiled guardrails
  • Authorization
  • Queues, locks, retries, and idempotency
  • Entitlements and billing
  • Approval records
  • Evidence ledgers

How this shows up in the products

Not every product applies these ideas, and none of them applies all of them. What follows is what is implemented in the reference products today, stated narrowly on purpose.

Domain records written by AI carry their provenance as columns on the record itself: an AI-generated marker, a confidence value, and the reasoning. This is implemented in the Simple Time and Simple Projects schemas and is the pattern the rest of the portfolio is built to. It is a column, not a log, which is why it survives a report, an export, and a database restore.

Product MCP implementations vary, and the intended pattern is a per-tenant audit table holding the tool name, the arguments, the result, any error, and the time. How far any given product has taken that is a fact about that product rather than about the portfolio, and a customer-facing MCP capability is not treated as available here until tenant scoping, authorization, and durable audit behaviour have been verified for the specific product offering it.

Where the audit write exists it is deliberately best-effort: it is wrapped so that a failed audit write can never break a customer's read. That is the right engineering trade and it is also the reason we do not claim that every call is recorded. An audit store that is allowed to fail is an audit store with gaps, and saying otherwise would not survive a security review.

Human review points are declared per workflow rather than assumed. Where a workflow produces a production effect, the approval is part of the design of that workflow.

What is still design direction

The provenance pattern is a portfolio rule and a reference implementation, not a completed rollout. Products earlier in their build do not yet carry it everywhere. Stage contracts as a formal, checked artifact are how we work, not a feature any product currently exposes to a customer. Nothing on this page should be read as a claim that a given product already does all of it. Where a product's own page and this page disagree, the product page is the narrower and more reliable statement.

Limits, and what this is not evidence of

A method that makes work reviewable does not make the work correct. It makes the work checkable by someone competent to check it, which only helps if that person exists, has time, and is empowered to reject the artifact. A review seam nobody uses is theatre with a database row attached.

Nor is any of this a compliance claim. Structuring work so a reviewer can follow it is not a certification, an attestation, or a control framework, and it does not substitute for one. We hold no certification on the strength of this method and claim none.

The evidence boundary is worth stating plainly. The paper below is a methodology paper. At the time of writing it is an arXiv preprint that the authors have submitted for peer review, and it reports the method and its rationale rather than a controlled trial of outcomes. Our own use of it is internal practice, not a study. Neither establishes that this approach produces better results than another, and this page does not claim it does.

Two companies, two applications

Simplicity IT Inc. and Simple Intelligence Group are separate companies, and both apply this method to different work. Simplicity IT applies ICM through Microsoft implementation, governance, security, adoption, and managed operations, which is service delivery inside a customer's own environment.

Simple Intelligence Group applies selected ICM principles inside AI-native software products. What that means here is design: how a product decides what a stage may read, which source wins when two disagree, what intermediate artifact a person opens before approving, and what provenance the resulting record carries. Neither company speaks for the methodology or its authors.

Source

Jake Van Clief and David McDermott. Interpretable Context Methodology: Folder Structure as Agentic Architecture. arXiv:2603.16021. Submitted 17 March 2026, revised 18 March 2026.
https://arxiv.org/abs/2603.16021
https://doi.org/10.48550/arXiv.2603.16021

Related reading on this site: the engineering principles the products are held to, and what you can actually get today.