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.
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.
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.
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.
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.
None of the following is provided by, or substituted by, a context method. Each is built, tested, and enforced independently:
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.
Where a product embeds an MCP server, that server writes tool calls to a per-tenant audit table holding the tool name, the arguments, the result, any error, and the time. The write 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.
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.
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.
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.
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.
We reply inside one business day. No sales qualification gauntlet.
Talk to the teamNot ready to talk yet? Take the two-minute readiness check and we will come back with the first thing worth automating.
Microphone not available? Pick your industry and type a quick note. We reply inside one business day.