Spec catch-up with the reference implementation: saved queries, template identity, mail/thread vocabulary, trigger execution, blob lifecycle, subject reachability

[sathish-mg]

Context

Building a production email→expense agent on the reference implementation (Areev 1.2.1, AreevAI/areev#23–#29) surfaced a set of places where the spec either restricts a construct it never defines, stays silent where the implementation had to commit to semantics, or has a reachability hole with compliance consequences. Filing as one consolidated catch-up ticket per maintainer request; each section can be split out when picked up. Spec refs are OMS 1.6-draft / CAL 1.3 / SML 1.1 as of openmemoryspec/oms@HEAD.

1. Saved queries are restricted four times, defined zero times

CAL §8.14.3, §8.16.1, §8.17 and CAL-E125 all constrain what may appear "inside saved-query bodies", and OMS §8.12 makes query:<namespace>/<name> a valid Recommendation target_ref — but there is no DEFINE QUERY statement, no grammar production, no naming/parameterization/versioning rule, no DESCRIBE target, and CAL §1.3 declares "no persistent variables".

The reference implementation has now shipped the whole lifecycle: DEFINE QUERY "name"($params) [DESCRIPTION "…"] AS { body }, RUN "name"($p = v), DESCRIBE QUERIES, DROP QUERY, storage as host meta rows (qry:<name>) that replicate in bundles with latest-wins convergence, a define-time parse of the body with parameters standing in (AreevAI/areev#24), and a mandatory read-only verification pass. Ask: adopt this as the normative definition (or amend as needed), including: bodies are Tier-0-only, define/drop are admin-gated, definitions are host metadata not grains, and define-time validation MUST parse the body as it would run.

2. Templates have no identity to version

OMS §8.12 rule 4 requires summary.template_id to "reference a deterministic template" and makes template:<ns>/<name> a Recommendation target — but CAL §10.6/§10.8 give templates a bare 64-char name: no version, no supersession, no content address, and UNDEFINE is reserved (Appendix D) with no semantics. A Recommendation applied against template:acct/invoice_row cannot say which revision it changed or store an honest inverse. Ask: minimal template identity — at least an updated_at-style revision the audit trail can pin, ideally a content hash of the definition body; define DROP TEMPLATE/UNDEFINE semantics.

3. No mail/thread vocabulary

Events model LLM turns (role is a chat enum). There is no From/To/Cc/Subject/Message-ID/In-Reply-To/References vocabulary anywhere; threading is session_id + parent_message_id (§28.6). Every email-shaped agent invents its own context-map keys, which defeats portability of exactly the grains most worth porting. Ask: either (a) a registered mail: domain profile (Appendix A) — noting CAL's domain_prefix grammar is closed, so this needs a CAL minor — or (b) the smaller change: a first-class thread_id common field alongside session_id/run_id, plus a note mapping RFC 5322 identifiers onto Event fields.

4. Triggers have a declaration format but no execution contract

§27.6 defines trigger declarations (Observation grains, observer_type: "trigger:*", int: config) and stops. Nothing normative says what evaluates a declaration, how a firing becomes a grain, what idempotency/dedup a twice-delivered webhook gets, or how a trigger binds to a Workflow. The reference implementation is about to commit to semantics here (AreevAI/areev#26: one-shot host-invoked evaluation, connector subprocess contract, firing journaled as an Observation, binding = Workflow hash). Ask: specify the execution contract — even a minimal one: firing MUST be journaled, item ingestion MUST be idempotent on a declared dedup key, binding resolution rules. Also: register the "trigger:*" observer_type values in §24 (today they exist only in §27.6 prose).

5. Blob lifecycle and surfaces

Three related gaps:

• cas:// is never defined — it appears once as an example URI in §7.1. The reference implementation treats cas://sha256:<64-hex> as normative (address = plaintext digest, stable across encrypted/plaintext stores, re-verified on read). Specify the scheme.
• No blob operations in §28.4 — the operation table is grains-only. The implementation now ships put_blob/get_blob on CLI + bindings (Expose the CAS blob store beyond Rust: areev blob put|get, bindings AreevAI/areev#27), including a deliberate lock-free read path (a blob is immutable; its address is its checksum). Specify put_blob/get_blob and the locking expectation.
• Erasure does not reach referenced blobs — FORGET SUBJECT and crypto-erasure act on grains; a subject's invoice PDF referenced via content_refs survives erasure of every grain referencing it, and the spec is silent. The implementation reclaims sole-referenced CAS attachments during subject erasure and reports blobs_reclaimed. Make that normative — this is a GDPR-grade hole, same severity class as the vault-row rule in §10.5.2.

6. Subject reachability for erasure/DSAR selection (compliance-grade)

Found as AreevAI/areev#23: a grain carrying a subject with no relation/object (an Event about an identity) reached no structural index, so FORGET SUBJECT / REPORT SUBJECT — which select through those indexes — missed it: the grain survived erasure and went undisclosed in a DSAR while the operation reported success. The spec defines the selector (FORGET SUBJECT <id>, CAL §8.14) but never states the reachability obligation. Ask: a conformance requirement that subject selection MUST reach every grain whose subject (and user_id, and partition-key derivatives) matches, regardless of grain type or the presence of relation/object — with a conformance test. Implementations should not be able to pass conformance while silently under-erasing.

7. Housekeeping (drive-by, same doc pass)

• mg:step_action:<node_id> is used normatively in §8.4 but absent from the §8 / CAL §7.1 relation vocabularies — a conformant validator warns CAL-W001 on the spec's own relation.
• SPECIFICATION.md header says 1.6-draft while the footer says "v1.5 revision"; SML 1.1 self-describes as "Part of OMS v1.5"; CONTRIBUTING.md references a non-existent oms-specification.md.
• CAL §10.x: WITH progressive_disclosure(...) semantics shipped in the implementation (body-axis clipping at 40/80 chars, full adds Skill instructions/when_to_use) — worth capturing while defining, since §10.5's tier ladder is the same mechanism.

[sathish-mg]

All seven sections are now drafted on #11 (release/oms-v1.6). §4 landed earlier in the trigger batch; the other six are new.

§	Where it landed	Notes
§1 Saved queries	CAL §8.18 + OMS §28.4.1	Adopted as asked, plus the metadata table it needed
§2 Template identity	OMS §28.4.1 + CAL §10.6.3	Took both stamps, not either
§3 Mail/thread	OMS Appendix A.8 + CAL domain_prefix	Option (a); (b) rejected
§4 Triggers	§8.13, §27.8, §17.4	Landed 2026-08-19
§5 Blob lifecycle	OMS §7.1.1, §28.4, §28.4.2, §28.4.3	All three parts
§6 Subject reachability	OMS §28.4.4 + CAL §8.19	Required conformance case
§7 Housekeeping	Various	Plus one found in passing

Where the drafting diverged from the ask, and why:

§2 — took both stamps rather than choosing. The issue asked for "at least an updated_at-style revision, ideally a content hash." The draft requires both, because the two consumers need different things: latest-wins replication needs an ordering (a hash cannot provide one), and an audit trail needs an identity (a timestamp cannot provide one — two hosts editing a template to the same body produce different stamps for identical content). The same rule covers saved queries, since §8.12 makes query:<ns>/<name> a target_ref too and it had exactly the same hole.

§3 — took option (a), rejected option (b). A first-class thread_id common field would add a compact key to a field map §6 declares normative and frozen, for a concept session_id already carries. The mail: profile rides context, which costs no format change. The mapping table's load-bearing row is In-Reply-To, which maps to both parent_message_id (the parent grain's content address) and mail:in_reply_to (the transport's Message-ID) — collapsing them loses the reply edge on every partially-ingested thread.

This is also the one batch written ahead of an implementation rather than from working code, and the section says so in the spec.

§1 — needed a foundation that did not exist. Specifying saved queries meant specifying what a definition is stored in, and §10.5.1, §10.5.2 and §27.8 had all been referring to "reserved store-metadata prefixes" without this spec ever defining a store-metadata row. That is now OMS §28.4.1, and those three sections have a referent.

§1 — the error codes could not follow the implementation. The reference implementation's CAL-E040–E059 block (templates and saved queries) overlaps the Evolve codes this registry published in 1.5; only CAL-E044 agrees. Registries are append-only on both sides, so the saved-query family takes a fresh CAL-E130–E137 block. The overlap is recorded in Appendix C as an implementation defect to reconcile rather than encoded as a disagreement.

§6 — pulled in a statement that was missing entirely. The requirement that erasure and disclosure share one selector is only meaningful if the disclosure statement exists, and REPORT SUBJECT was in the implementation but nowhere in CAL. It is now CAL §8.19, Tier 0, with two properties stated because they are easy to get wrong: it must not sit behind the cap that disables destruction (a deployment that turned destruction off still owes data subjects access), and it writes no audit grain (an audit grain naming the subject of a DSAR would itself be personal data about them, immutable and replicating).

§7 — one item was bigger than housekeeping. WITH progressive_disclosure was not under-documented but contradictorily documented: the grammar has read summary | headlines | full since 1.0 against a §14.3 table reading summary | standard | full. Those were never the same control — one is metadata density, the other body extent. §14.3 now documents both axes and how they compose.

Also found while sweeping: §6.14 was used twice (the trigger batch added "Trigger-Specific Fields" without bumping the "Compaction Rules" below it). Fixed.

Every CAL example added across these batches parses against the reference implementation's actual parser.

Ready for review section by section — each batch is one commit, and any of them can be split out or reverted independently.