A type describes a reusable kind of fact and its identity fields. A Resource is a broad parent type suitable for things a project uses. Relationships add context such as author and project scope. See relations and types before this advanced exercise.
We will use fictional subscription prices to distinguish a value that changed from one that was wrong. These prices are illustrative, not current provider quotes or a reason to buy anything.
Have a working harness connection and the attribution/scope setup from project memory. You do not need the hook exercise. Use store loom_demo, project durmem practice notebook, and only the synthetic facts below. Do not modify another project's facts or types.
loom_demo and project scope durmem practice notebook for this session, without changing persistent defaults or showing credentials. Check the catalog before proposing a reusable paid-service type for this exercise.Ask the agent to compare candidate types by meaning, parent and fields, not just name similarity. If a compatible PaidService already exists, reuse it. If an incompatible declaration uses that name, stop and explain the conflict rather than replacing a shared type.
PaidService under Resource, with fields name, monthly_cost, asof, in that order. Explain the reuse check, then declare the agreed shape and read it back before any saves.The readback must show the actual parent and field order. Each service belongs in the data; do not create one type per vendor. A canonical identity is the exact type and field values. Changing an identity field creates a different identity rather than editing an existing fact in place.
Current facts exclude claims replaced or disputed by later lifecycle edges. History keeps those earlier claims and why they were retired. Exact repeated saves reuse the same identity; that does not rewrite its content or scope.
For this historical scenario, distinguish the date knowledge became known (known_from) from a price's domain-effective date (asof). The latter is a field we interpret, not an automatic price-history engine.
| name | monthly_cost | asof |
|---|---|---|
| AWS | 340 | 2026-04-01 |
| OpenAI | 120 | 2026-04-01 |
| Cursor | 60 | 2026-04-01 |
| Vercel | 20 | 2026-04-01 |
The illustrative baseline arithmetic is 540 per month. If this project already contains the later rows below, ask for these exact baseline identities with history rather than adding them again or calling them current.
A Supersedes relationship means replacement, not that the old claim was always false. After this change alone, the example's current total is 576: 340 + 120 + 96 + 20. Do not count both Cursor records.
A Negates relationship records that the target claim was false. This is different from the once-valid Cursor price. After both changes, the illustrative current total is 581: 340 + 120 + 96 + 25.
A point-in-time read asks what the store knew at a specified knowledge date. A domain-effective question instead asks which prices now appear to have applied on that date. They need different reasoning.
With the scenario recorded correctly, the expected knowledge-date arithmetic is 540, while the prices now understood to have applied that day total 581. The backdated known_from values are part of this synthetic exercise, not proof that these facts were physically saved in April. Results require actual historical reads; this page's arithmetic alone does not validate that path.
You should have one verified reusable type, a current total drawn from the intended project rows, and an explanation of each retired record. If totals differ, inspect identities, dates, scope and lifecycle before changing anything. If it is unclear whether an old claim changed or was false, preserve that uncertainty rather than guessing a relationship.
For repeated queries over such structured facts, see rule promotion. Planning with past decisions is a separate exercise and does not require this custom type.