> ## Documentation Index > Fetch the complete documentation index at: https://powercontext.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Mental model overview > Separate the three paths first, then read the object pages. Calling PowerContext “memory for agents” is not enough. Is every prompt a Memory (Selected project knowledge that should matter later.)? Can a generated Skill (An approved repeatable method. Export is still required. PowerContext grants no execution authority.) install itself? Why does a Handoff (Packages the current objective, verified progress, blockers, and next action. It stays temporary until an explicit commit.) sometimes have no latest revision? Those questions are about object boundaries, not API syntax. ## Look at three paths first PowerContext runs three paths at once. They may cite one another. They do not collapse into one lifecycle. ![Keep knowledge, review first, and hand off work as three separate paths.](https://mintcdn.com/powercontext/1t_ajifOEOG5YQjP/assets/mental-three-paths-en.svg?fit=max\&auto=format\&n=1t_ajifOEOG5YQjP\&q=85\&s=8d7487f6eb70ee0cfc8fa22cd99d39db) Keep knowledge. A Source (Records what happened. Capture does not write durable knowledge.) only proves that something happened. Write a Memory when you will reuse it. The next request recalls it through a PreparedContext (A bounded view for one request. It includes Citations and is not a durable asset.). Review first. Experience (Approved judgment for similar situations. It enters Review as a Candidate.) and managed Skill first become a Candidate (An Experience or Skill proposal awaiting Review.). A model may draft it. Successful generation is not approval. Review (Approve creates an Artifact Revision. Reject records the reason and creates no result Artifact.) decides what stays. An approved Skill still needs an explicit export. A handoff can stay temporary. A Handoff is packed for the next actor. It becomes a durable milestone only after an explicit commit. Writing Memory does not create a Handoff. Approving a Skill does not place it in the next PreparedContext. ## Six values that should stay separate The values differ in lifetime and authority. Keeping them separate prevents a temporary model input from being mistaken for durable or executable state. | Value | What it answers | Durable | Current instruction authority | | - | - | -: | -: | | `Source` | What happened, and where is the evidence? | Yes | No | | Artifact `Revision` | What immutable version of a durable asset was saved? | Yes | No | | `Candidate` | What Experience or Skill proposal is awaiting Review? | Yes | No | | `PreparedContext` | What cited context is relevant to this request? | No | No | | Prepared `Handoff` | What current work should another actor inspect and continue? | Held by the caller | No | | Skill projection | What approved Skill Revision was exported to a host directory? | Yes, rebuildable | Decided by the host | ### Source is evidence A Source may contain a prompt, a task result, or another work artifact. It answers what happened at a particular point. Capturing a Source does not write Memory. Automatic extraction requires a generation pipeline. If you already know what should be kept, write the Memory explicitly instead. ### Artifact Revision keeps history Memory, Experience, Skill, and committed Handoff use Artifact Revisions. A Revision is immutable. Updating the logical asset creates another Revision, while exact historical references remain readable. An exact Artifact reference contains the family, artifact ID, and revision: ```text theme={"theme":{"light":"github-light","dark":"github-dark"}} family/artifact_id@revision ``` Candidates have a separate `version` for concurrency control before Review. Candidate version 2 does not imply Artifact Revision 2. ### PreparedContext lasts for one request `prepare_context` builds a PreparedContext from a Scope, query, and byte budget. Two results are normal: * `ready`: non-empty content with Citations; * `empty`: no suitable content, which is not an error. PreparedContext is not written back to durable history. Hosts label it `untrusted_history` and inject it into the current model request only. ### A Handoff does not need to be committed A Prepared Handoff is an inspectable value that can be passed to the next actor. You may continue directly from it, or commit it as a Handoff Revision when the work needs a durable milestone that can be selected by exact revision or latest. Commit is a separate operation. Without it, there is no new durable Handoff head. ### Experience and Skill go through Review A model or user may submit a Candidate. Review has two terminal decisions: * approve creates or revises an Artifact and records an exact `result_artifact`; * reject records a reason and creates no result Artifact. Only the approved current Experience head can enter PreparedContext. Skills never do. A Skill needs an explicit export, and PowerContext does not grant execution authority when that export succeeds. ## Three boundaries ### Persistence PreparedContext and Prepared Handoff are temporary. Sources, Candidates, and Artifact Revisions are durable. A Skill projection is a host-side copy of an Artifact, not a new authority. ### Review Generation drafts a proposal. Review decides whether to approve it. “The model generated valid output” does not mean the content has shipped. ### Execution authority Scope selects data. Citations identify sources and versions. Review decides whether to create an Artifact. None of these grants tool permissions or proves that historical content still matches the live workspace. ## Later chapters reuse one example This is not a procedure. You do not need to change any API now. Later pages on Source, Memory, Handoff, Experience, and Skill keep the same story. They all use one example. That lets you compare which objects one piece of work leaves behind. The example is: the PowerContext OpenAPI contract changed. You regenerate the checked-in client, then run the contract tests. The same work leaves these objects separately. They do not chain themselves together: | What you do | What it leaves | What it does not become | | - | - | - | | Record that the contract changed, and the client and tests must follow | Source | Memory | | Write the reusable decision: regenerate and inspect the client before tests | Memory | Handoff | | Ask in a new request what to do after the contract change | PreparedContext | A durable asset | | Pass current progress to the next agent | Prepared Handoff | The committed `latest` revision | | Submit the judgment from the result | Experience Candidate | An approved Experience | | After approval, draft a repeatable method | Skill Candidate | An approved Skill | | Export the approved Skill to a supported host | Skill projection | Execution authority or recall content | When you follow those walkthroughs, check the ID, Citation, or Revision that comes back. Finishing one step does not mean the next step already happened. ## Common mistakes > [accordion] Why can I not search Memory after capturing a prompt? > > Capture stores a Source. Configure a generation pipeline and process the Source window, or write the Memory explicitly. > [accordion] Why is an approved Skill missing from recall? > > PreparedContext may include active Memory and the approved current Experience head. It does not include Skill. Export the Skill to a host instead. > [accordion] Why did a Prepared Handoff not become latest? > > It was not committed. You may continue from the prepared value, but no durable milestone is created automatically. > [accordion] Does a Citation prove that the content is still correct? > > A Citation makes the source and version inspectable. The receiver must still check live files, current capabilities, and authorization. ## How you know the objects are separate After this page, check these four facts: 1. A successful capture is not a Memory write. 2. PreparedContext lasts for one request. It does not become a durable asset by itself. 3. A Prepared Handoff does not become `latest` until you commit it. 4. An approved Skill still needs an explicit export, and it never enters PreparedContext. If any of those still blur together, read the matching object page before you install anything. > [!TIP] > > If PowerContext fails while automatically fetching context, keep working. If you explicitly write a Memory, commit a Handoff, approve a proposal, or export a Skill, you must see the failure. Read [fail-open](https://powercontext.mintlify.site/en/mental-model/fail-open.md) for the full rule. ## Next > [card] [See how evidence is stored](https://powercontext.mintlify.site/en/mental-model/source.md) > > A Source only proves that something happened. Journal position, processing cursor, and Memory belong to later layers. > [card] [Read Scope before you integrate](https://powercontext.mintlify.site/en/mental-model/scope.md) > > A wrong Scope rarely errors. Search is just empty. Before you connect a host, also read [fail-open](https://powercontext.mintlify.site/en/mental-model/fail-open.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.