---
name: exomem-capture
description: Preserve a durable conclusion or recurring entity from a conversation without dumping transcripts into compiled memory.
metadata:
  skill_contract: 559a751112793020de7a074aafa3713c510c410293d92246c7d3adffcaea3ef6
  version: "0.1.0"
---

# exomem-capture

## Purpose
Save durable conclusions and recurring entities at the right epistemic layer.

## When to use
Use when the user asks to save or the session lands on durable reusable knowledge, including stable context about a recurring entity.

## Portable operating rules

Before the first operation, inspect the exposed bootstrap schema. If it lacks `skill_contract`, obtain `bootstrap(profile="compact")` directly. Otherwise obtain `bootstrap(profile="session", skill_contract=<metadata.skill_contract>)` if current policy or capabilities are missing; honor `engagement.envelope` and `available_product_tools`. Reuse returned state until policy, connection, adapter, or returned vault configuration/registry state changes. If the server rejects the session profile or argument, obtain `bootstrap(profile="compact")` once. Use the harness's supported discovery mechanism and load only the tools needed now. If the applicable local procedure cannot be read, obtain the portable compact contract; do not improvise a write.

Do not invoke tools absent from `available_product_tools`; use the live capability list even when a bundled workflow mentions a withheld operation.

Use `configure_memory` set/clear only for an explicit user request to change saved engagement.
Recall, capture, installation and missing hooks use the existing preference;
none authorizes changing it. Inspect first when the user requests a change.

Sources/Evidence are immutable, and content outside the managed Knowledge Base
is read-only. Before a compiled write: reuse current relevant search/read results,
check for duplicates, and include known source references and reviewed connections
in the first write. Use `connect_memory(operation="suggest-links")` when useful
connections are still unknown, not to recheck links already established in context.
Honor the live confirmation ceiling;
a workflow or standing capture preference does not grant restructure authority.

Inspect mutation results before reporting success. On `success: false`, follow
the structured error. For warming, busy, pending, or
`MUTATION_COMMITTED_ACKNOWLEDGEMENT_UNCERTAIN`, preserve the same mutation identity
and unchanged payload; wait/reconcile/retry only as instructed, never with a new
identity after an uncertain commit.

## Durable personal baselines
A stable preference, recurring routine, historical baseline, or durable affiliation
is eligible only when both stability or recurrence and reusable comparison,
interpretation, or decision value are clear. Attach a facet or affiliation to a
uniquely resolved Entity; otherwise write one concise compiled observation. Use
Records only for an observed measurement accepted by a compatible existing
collection. Fleeting preferences, one-off activity, incidental associations, trivial
metrics, and tentative events stay quiet. Durable interpretations retain explicit
attribution and uncertainty rather than becoming established facts. Eligibility never creates an Entity,
collection, or schema. Concise observations and narrow additive facts follow
`proactive_capture`; affiliation relations use `link_acceptance`; a new Entity follows `proactive_capture`; merge or
substantial curation uses confirmed `restructure_execution`.

## Workflow
Before choosing a destination, partition the exchange into independently reusable
objects by retrieval question, subject/domain, temporal episode, and epistemic
role. Reuse current relevant recall and resolve each meaningful cluster against
canonical homes. The open note has no priority; keep details within one coherent
scope together. Preserve durable hypotheses as attributed, uncertain claims.
Perform one completeness/destination review for the whole write plan, not a new
review after every write. During development, repository/specification artifacts
carry transient progress; capture reusable decisions and verified milestones.

1. Decide whether the material is raw evidence or a compiled conclusion.
2. Use `capture_source` for raw captured text or source material. Classify it on
   two open axes: `source_kind` (what it is, required) and `domain` (what it is
   about), plus `projects` for the work it serves. Name the closest known kind
   or a new one; there is no catch-all.
3. Pick the lane before the transport. Raw material stays with `capture_source`, which takes `files` for attachments as well as `content` for text. Proof-bearing material takes `preserve_evidence` for factual text, `preserve_artifacts` when file handles are available, and `transfer_artifact` only as the binary-upload fallback.
4. Draft distilled conclusions as: `research-note`, `insight`, `failure`, or `pattern`. Pass any path captured in steps 2-3 as `sources:` so the conclusion links to its provenance and the source leaves the unprocessed queue.
5. Reuse known meaningful connections; use `connect_memory(operation="suggest-links")`
   when candidates are still missing. Then write with
   `remember`, carrying the sources and accepted links in the first write; prefer
   `edit_memory` or `replace_memory` for near-duplicates.
6. For an entity, consult the active entity registry and selected knowledge packs,
   then call `connect_memory(operation="resolve-entity", name=...)` before writing.
7. When one active entity matches, use `edit_memory` for a small stable-fact
   correction or the canonical relation workflow for a new connection.
   A stable, uniquely attributable fact about a resolved person, including the
   vault owner's own entity (role, affiliation, relationship), is an entity-level
   fact: route it to that entity under `proactive_capture`, not just in the reply
   that used it. Contact details (phone, address, email, identifiers) go on the
   same entity page, in a dedicated `## Contact` section, each as its own
   `- [contact] ...` unit. Never put them in the summary or in `fact` units:
   activation serves `contact` units only when the turn asks to reach the person,
   and a restricted audience that cannot see the entity cannot see the section.
   Do not create a separate contact page or page type.
8. Only when no entity matches and the identity is stable, and central or
   recurring, and useful beyond this source, use `connect_memory(operation="create-entity")`.
   When the name you write is in another script than the user's own spelling
   of it, add a native-script alias (`aliases=[...]` at create, or the
   `aliases` field through `edit_memory` on an existing page); see
   `references/writing.md` § Names in another script.

## Lifecycle
Two more classes land here. A **stated intent or commitment** routes to Planning after resolving workflow posture and inspecting for an existing item to update before creating one. An **observed outcome or event** routes only to one compatible Records collection with `record_memory(action="append")`; when collections compete ask one focused question, and when none fits propose one rather than creating it silently. Records never transition Planning: only explicit user intent may request a guarded transition, while a `propose-after-outcome` posture may only propose one. A tentative claim is never written as an event, and elapsed time is never an outcome.

## Artifact role and current state
Read the supporting units for `artifact_role_promotion` and
`transient_state_review`; neither signal grants mutation authority. Choose a home
by role even within one topic: a repeatable successful procedure belongs in a
suitable reusable note, and an attributed multi-source synthesis in a research
note. Search existing eligible homes first. Keep exact source-unit provenance:
reference both the procedure and outcome units when extracting a method, or the
synthesis unit and its distinct sources when compiling a research note. Retain
the experiment history. A title match or parent backlink does not establish that
the identified material has a home; exact represented content does, while a
paraphrase remains a review candidate for the reader to assess.

For example, a batch may contain two separately successful reusable methods and
a synthesis across two sources. Give each method its own evidence and check the
synthesis independently; extracting one does not settle the others. A protocol
without reusable success or a list of citations alone needs no such promotion.
For a single batch, “No taste results yet” alongside an observed taste result
invites a current-wording correction; “Previously no taste results existed” is
history, and taste results do not settle an awaited safety result or a new trial.
Preserve that history through a governed edit or exact valid supersession.

Extraction/restructuring uses confirmed `restructure_execution`; an
already-authorized local correction acquires no additional confirmation step.
Observed transaction state still follows the existing Records claims handoff,
never an automatic append from a review signal. Item triage changes presentation,
not evidence coverage. Explicit review exposes complete/capped/unknown coverage;
compact omission is not proof of a clean page. Apply this role-first reasoning to
visible conversation transitions before writing too. An MCP-only server cannot
guarantee detection or capture of a tool-free turn.

## Vocabulary

Read [vocabulary](references/vocabulary.md) before changing a registry.
If the vocabulary reference is missing, inspect the exposed bootstrap schema.
Use `bootstrap(profile="compact", section="vocabulary")`, or
`bootstrap(profile="full")` when `section` is unavailable. Follow the returned
inspect routes and `save` contract. Reuse or alias before proposing justified
new meaning; save with the current hash and `why`. Report saved versus queued
and the returned restore route. Use only exposed operations.

## Relation governance
Resolve typed meaning with `resolve-relation` before authoring. Reuse a specific
truthful match; otherwise choose honest `relates_to` or no edge. Durable recurring
meaning is proposal-first through `propose-relation` and hash-guarded
`save-relations`; corrections use a new canonical key and deprecate the old one.

## Output contract
After writing, report exactly `Saved -> <path>` plus one short phrase if needed. If nothing durable was saved, say why. Report a lifecycle consequence in the user's own vocabulary and cite the collection the way recall cites a page; the words Planning, Records, collection, schema and natural key never lead the report.

## Save rules
Keep raw source verbatim when it matters. Keep compiled notes concise, attributed, linked, and written as conclusions, not transcripts.

## Mistakes to avoid
Do not save unresolved brainstorming as a conclusion. Do not bury raw evidence
inside a compiled note. A single incidental mention, unresolved identity, or
transient participant stays in source/note context. Do not create a parallel
page when an existing active note or entity should be edited, linked, or
superseded.

<!-- exomem-semantic-authoring:v7 sha256:d24af455f8e0e09831f07fd273dfd1812e029046ef512b69524a3f206c51b5f2 -->
## Semantic authoring contract

Every new, replaced, or activated compiled note in the live class needs at least one valid, non-empty semantic unit. Either compact or rich form satisfies the minimum; compact is preferred, and a valid rich unit does not need a duplicate compact restatement.

Semantic roles:

- Category: One primary open-vocabulary label describes what a unit is about; rich category defaults to its governed kind unless explicitly overridden.
- Tag: Zero or more optional secondary retrieval labels refine lookup and never replace category or determine kind.
- Kind: The governed semantic form: compact units always use `observation`; rich units use their recognized heading kind.

Compact grammar: `- [category] content #tags (context) ^anchor`. Parse valid compact observations anywhere outside fenced code blocks. Exomem writers use `-` under the canonical `## Observations` section. Parser bullet markers are `-`, `*`, `+`; the canonical marker is `-`. Parse from the end by taking anchor, then context, then trailing tags; the authored display order remains tags, context, anchor. Category uses open vocabulary.

- Compact category: the unit's one primary open-vocabulary subject or domain label. After trimming, use 1-64 Unicode code points; begin with a Unicode letter; then use only Unicode letters or digits, spaces, `_`, or `-`. Apply Unicode NFKC and casefold, then collapse runs of spaces, `_`, and `-` to one `_`. Registry alias resolution is separate from authored canonicalization; an unseen valid category needs no registry write.
- Compact content: the unit's substantive observation. Use non-empty content that remains on one Markdown line. Escaped parentheses, embedded hashes, and non-trailing tag-like text remain content.
- Compact tags: zero or more optional secondary retrieval labels; tags do not replace the primary category or governed kind. Write `#slug`. Use 1-64 Unicode letters or digits, `_`, `-`, or `/`; begin with a letter or digit; do not use empty path segments or a trailing `/`. Use one contiguous trailing run after content and before optional context and anchor.
- Compact context: one optional authored qualifier for the observation. Write `(<context>)`. Use one balanced, unescaped parenthesized suffix preceded by whitespace.
- Compact anchor: one optional stable authored unit identifier. Write `^anchor`. Use 1-64 ASCII letters, digits, or hyphens and begin and end alphanumeric. Place it at the end of the line.
- Compact exclusions: observation-shaped rows inside fenced code blocks; task labels `[ ]`, `[x]`, `[X]`, and `[-]`; reserved or punctuation-bearing bracket labels outside category grammar. Compact units do not carry typed unit relations; use a canonical note-level relation or the rich form.
- Rich: write `## <Governed Kind>` with optional leading metadata `- category: <open category>`, `- id: <stable-id>`, `- tags: <comma-separated tags>`, `- context: <context>`, `- relations: <relation-type>: [[Target]]`. Metadata rows are optional and leading; the canonical writer emits category, id, tags, context, then relations; category defaults to the governed kind when omitted. Accepted metadata order is flexible while rows remain leading. After optional leading metadata, add a blank line and a substantive Markdown body. Typed unit relations require the rich form. A `#anchor` target addresses a unit.
- Rich boundary: A heading at level N owns content until the next non-fenced heading at level N or shallower; deeper headings remain in its body. `empty_rich_unit` means a recognized rich heading has no substantive body; Add substantive body content or remove the empty recognized heading.
- Exact applicability: obtain `bootstrap(profile="compact", section="authoring")` and read `semantic_authoring.minimum_semantic_unit` for current structural applicability and the status-class rule. If the exposed bootstrap schema lacks `section`, use `bootstrap(profile="full")` instead; released profiles reject section arguments. Apply `compiled_intent(after_state) = canonical_compiled_destination(path) OR the normalized type's note-type role is compiled`. Shipped compiled types: `research-note` in `Notes/Research`, `insight` in `Notes/Insights`, `failure` in `Notes/Failures`, `pattern` in `Notes/Patterns`, `experiment` in `Notes/Experiments`, `production-log` in `Notes/Productions`. More may be registered; `schema_memory(subject="note-types", operation="inspect")` lists the live set. Reject missing, invalid, or mismatched compiled frontmatter before evaluating the minimum-unit predicate. The minimum predicate applies when the path and normalized compiled type structurally match; the result is writable managed Markdown in the governed subtree; the result is outside Sources, Evidence, and trash; no activation exclusion applies; the admitted effective status class is live. Check live creates, replacements and transitions to live; pending compiled notes may remain unit-free until activation.
- Existing active pages: A post-activation compliant page cannot lose its final valid semantic unit.
- Exempt content: arbitrary non-compiled Markdown, dataset cards, Evidence artifacts, hubs, indexes, logs, non-Markdown files, schema and admin artifacts, snapshots, Sources, templates, trash.
- Routes: use `remember` for a new compiled note, `replace_memory` for a replacement, `observe_memory` for one unit, and `edit_memory` for a small edit or activation. Tier 2 manage_memory_file create, overwrite, and append receive the same semantic precommit contract on the complete resulting compiled Markdown; prefer remember or replace_memory when their typed route fits.
- Findings: `missing_semantic_unit` means an applicable live-class compiled result has no valid non-empty unit; `empty_rich_unit` means a recognized rich heading has no substantive body. Add substantive body content or remove the empty recognized heading.
- Compact remediation: Add `## Observations` and `- [operating constraint] Keep retries bounded #reliability`.
- Rich remediation: Alternatively add `## Decision`, a blank line, and a substantive body.
- Semantic-unit coverage and relation-review disposition are independent obligations.
- Portable categories: Choose exactly one primary category: prefer a meaningful epistemic or operational role and put the domain in tags, but if the role would only be a generic fact, finding, or observation and the domain is the durable lens, use a domain category instead. The category vocabulary is open: these core keys are a shared starting point, not a closed list. When no core key is a good primary fit, author a new meaningful category rather than forcing an ill-fitting one. Use exactly one primary category; kind is the governed form, tags are secondary facets, and relations are typed edges. The rich form's category defaults to its kind, so `category: decision` is redundant when the kind is Decision. Create multiple distinct semantic observations and typed relations when the source genuinely supports them, but never multiply units or relations to satisfy a quota and never duplicate the same fact. Core keys are `action`, `assumption`, `code`, `config`, `constraint`, `decision`, `design`, `fact`, `finding`, `insight`, `preference`, `problem`, `question`, `requirement`, `risk`, `technique`. Core aliases are `actions` → `action`, `assumptions` → `assumption`, `configs` → `config`, `configuration` → `config`, `configurations` → `config`, `constraints` → `constraint`, `decisions` → `decision`, `designs` → `design`, `facts` → `fact`, `findings` → `finding`, `insights` → `insight`, `open_question` → `question`, `open_questions` → `question`, `preferences` → `preference`, `problems` → `problem`, `questions` → `question`, `requirements` → `requirement`, `risks` → `risk`, `techniques` → `technique`. Role example: `- [decision] Relocate to a coastal city next spring #life ^relocation`. Domain example: `- [nutrition] Evening protein improves adherence #experiment ^evening-protein`. Breadth example (life, finance, legal/travel, and career alongside one retained code line):

```markdown
- [constraint] Keep retry windows bounded #code ^retry-windows
- [risk] Variable-rate mortgage payments could spike #finance ^mortgage-rate-risk
- [question] Does the destination require a visa before travel #legal #travel ^visa-requirement
- [career] Weigh a sabbatical before the next promotion cycle #growth ^sabbatical-timing
```

Rich example:

```markdown
## Decision
- id: commit-to-morning-training
- tags: health
- relations: supports: [[Knowledge Base/Notes/Health/Morning training]]

Commit to a fixed 6am training block on weekdays so consistency compounds and health stays the durable lens for this decision.
```