Understand the outcome first
Your Mind’s settings, the rules for the area, the proposer’s access and the required checks determine whether a proposal can save. Why changes wait for review explains those controls. The named Automatic approval option is a separate feature, not a universal switch for saving corrections.
Out of the box, a change is saved without a person only when an automatic check passes and both the proposer’s trust level and the area’s own limit allow it. Deleting or renaming a file always waits for the owner or another approver. Areas that hold governed material, such as decisions, typically hold members’ changes for the owner, while ordinary areas can apply them once the check passes. Your Mind’s settings can make this stricter or looser.
An applied proposal has changed the saved record. A held proposal is waiting and has not changed it. A rejected proposal is not a saved change. Read the returned result instead of treating submission as success.
An area, called a zone, can give someone permission to suggest edits without giving them authority to approve. Choose access explains that separation.
Open the request you intend to decide
The Portal is your Mind’s web interface. Its Inbox brings together work needing attention, including held changes, questions and other approvals. An owner or other authorised approver can also answer a request from a connected chat client that supports it, where the request is shown with the exact change; the Portal Inbox is the place to look first. Read the kind of request before acting; a question waiting for an answer is not necessarily a proposed file edit.
You can also ask your connected agent, the AI tool you use with the Mind, to show the original request and its reference. Use the supported review controls for that request and your account. An incomplete or unavailable Inbox read does not establish that nothing is waiting.
Review one proposal
- Open the current saved record and the proposed difference. Check that you are looking at the intended request and area.
- Read the reason and supporting evidence. Make sure the change says what you intend without replacing unrelated information.
- Check that you have authority to decide this kind of request. Being able to read it or propose a change is not enough.
- Approve or reject through the request’s supported controls. If it asks you for an explicit human confirmation, read the exact request before answering it.
- Read the resulting state. After a successful save, open the record again and check the intended wording.
For a fictional example, a later leadership decision might change a refund period. Review that decision and the proposed edit to the policy together. The source supports the change; an agent’s confident explanation on its own does not.
Approval and saved output are different checks
Approval is a decision on the request. Readback checks the saved result. A request can encounter a conflict or another failed check rather than producing the change you expected, so keep the actual outcome and source in view.
If the file changed while the proposal was waiting, compare the current wording before preparing another edit. Correct a saved record walks through the whole correction job.
A decision and its saved result
Follow the request through to the source.
An authorised reviewer reads the current record, the proposed difference and its evidence, then approves or rejects the request. After that decision, inspect the actual result. If it says applied, open the saved record and verify the intended change. A waiting request or an interrupted connection is not proof that the source changed.
If the connection stops
Keep the request’s reference. Ask the agent to inspect that original request and the current record before submitting or approving anything again. A lost response does not tell you whether the action already happened.
If a check fails, use the reason to decide what needs changing. Do not reword or resubmit the same request just to get around a review rule. A missing permission needs an authorised handoff, not a different identity.
Understand the record of a change
The Mind keeps a signed, tamper-evident receipt for each read and change, including refusals. A receipt shows who asked, the kind of action, which areas it touched and the outcome (allowed, refused or held). It does not store the file path or the text, only fingerprints of the request and response. The owner can read the receipts in the Mind’s policy area (25-policy/audit.jsonl (older sealed segments are in 25-policy/audit-segments/)). A saved record also has earlier versions, and that version history is where you see the actual wording that changed. Current information and its history explains why earlier wording is not automatically today’s guidance.
The record of a save shows what the Mind did. It does not prove that the original email, meeting note or decision was true. Keep checking the evidence behind important information.
Related
Practical guides for people and agents