For agents and technical readers

Draft and verify a decision or policy record

Find the saved evidence for a settled decision or rule, propose a structurally valid operating record and verify its actual saved status.

Contents

Discover and read existing records

Call orient, follow the relevant maps and discover the current tools. Use list_records with {"type":"decision"} or {"type":"policy"}. Read a match with get_record using {"id":"<returned dec- or pol- id>"}. An excluded record cannot be fetched by guessing its id.

For a decision, load the supported authoring procedure with get_skill:

{"name":"record-decision"}

If that skill is unavailable in the client, follow a compatible client or authorised authoring handoff. Do not invent a separate record-write tool.

Prepare the record

Read the saved source material first. Decisions belong in the decision area and use a unique dec- id; policies use the policy area and pol-. Required governance fields include id, type, title, status, owner, scope, confidence, decided_on, review_by and non-empty sources. The owner is the accountable person or actor, not automatically the drafting agent.

Keep dates in YYYY-MM-DD, confidence in low, medium, high, and status in active, superseded, retired. Scope and evidence are bounded single-line metadata; fuller reasoning belongs in the body. Follow the loaded skill and area contract for the complete document.

The body states the Decision, Rationale and genuine Alternatives. A commitment can be part of that decision and linked work; the typed read surface does not provide a separate commitment type.

Propose and read back

Use check_write when the record's required structure needs preflight. Submit the complete record through propose_write in the permitted destination. Preserve the supplied revision/base contract for replacements. Read whether it applied or is held; required human review remains separate from drafting.

After a reported application, call get_record and read the saved source. Check owner, scope, evidence and review date. A deterministic shape check does not validate the reasoning. Report the actual result and any remaining review request.

Supersede without rewriting history

Read the active predecessor. Write a new record of the same type with supersedes naming that predecessor. The target must be active, and the chain must not cycle. After approval/application, read both records and their effective status. The reader derives supersession from an active successor even if the predecessor's stored status flip is still pending.

Use list_records with {"overdue":true} to find records whose review date has passed. That read does not create a reminder or decide the next review date.

Practical guides for people and agents

Start with one useful job

Join the waitlist

Plain text for AI agents. Same content as the human page.

## For agents

- What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC.
- Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up.
- How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link.
- Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents.

---

# Draft and verify a decision or policy record

Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works)

Find the saved evidence for a settled decision or rule, propose a structurally valid operating record and verify its actual saved status.

[Page as Markdown](https://app.mensara.ai/how-it-works/operating-record-procedure.md)

[Human guide](https://app.mensara.ai/how-it-works/operating-records)

## Use the released interface with current authority

Availability: Core0.20.11 / Portal0.3.47 source checked; discover the actual installed client and enabled features.

Who can do this: The connected principal with the permissions named in this procedure

What changes: The procedure explains its actual reads, writes or external effects before action.

Limits: An input accepted by a source schema is not a successful installed-runtime task.; Keep human decisions, client exclusions and pending results explicit.

Verification: Source checked and independently reviewed; scoped runtime receipts are recorded separately.

## Discover and read existing records

Call `orient`, follow the relevant maps and discover the current tools. Use `list_records` with `{"type":"decision"}` or `{"type":"policy"}`. Read a match with `get_record` using `{"id":"<returned dec- or pol- id>"}`. An excluded record cannot be fetched by guessing its id.

For a decision, load the supported authoring procedure with `get_skill`:

```
{"name":"record-decision"}
```

If that skill is unavailable in the client, follow a compatible client or authorised authoring handoff. Do not invent a separate record-write tool.

## Prepare the record

Read the saved source material first. Decisions belong in the decision area and use a unique `dec-` id; policies use the policy area and `pol-`. Required governance fields include `id`, `type`, `title`, `status`, `owner`, `scope`, `confidence`, `decided_on`, `review_by` and non-empty `sources`. The owner is the accountable person or actor, not automatically the drafting agent.

Keep dates in `YYYY-MM-DD`, confidence in `low`, `medium`, `high`, and status in `active`, `superseded`, `retired`. Scope and evidence are bounded single-line metadata; fuller reasoning belongs in the body. Follow the loaded skill and area contract for the complete document.

The body states the Decision, Rationale and genuine Alternatives. A commitment can be part of that decision and linked work; the typed read surface does not provide a separate commitment type.

## Propose and read back

Use `check_write` when the record's required structure needs preflight. Submit the complete record through `propose_write` in the permitted destination. Preserve the supplied revision/base contract for replacements. Read whether it applied or is held; required human review remains separate from drafting.

After a reported application, call `get_record` and read the saved source. Check owner, scope, evidence and review date. A deterministic shape check does not validate the reasoning. Report the actual result and any remaining review request.

## Supersede without rewriting history

Read the active predecessor. Write a new record of the same type with `supersedes` naming that predecessor. The target must be active, and the chain must not cycle. After approval/application, read both records and their effective status. The reader derives supersession from an active successor even if the predecessor's stored status flip is still pending.

Use `list_records` with `{"overdue":true}` to find records whose review date has passed. That read does not create a reminder or decide the next review date.

## Related

- [Record a decision or policy with its evidence](https://app.mensara.ai/how-it-works/operating-records)
- [Review and replace an operating record](https://app.mensara.ai/how-it-works/review-operating-records)
- [Read, correct and verify memory](https://app.mensara.ai/how-it-works/correct-memory-procedure)

[Join the waitlist](https://app.mensara.ai/#waitlist)