Skip to content

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

8 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 

Repository files navigation

remember — OKF v0.2 sample bundle (deletion semantics)

A small, fixture-driven OKF v0.2 bundle emitted by the remember wiki compiler (Lexenne), published so the deletion-semantics conventions discussed on knowledge-catalog #207 can be tested against real producer output rather than prose.

What this is, and is not

  • Is: the unedited output of our production emitter (private repo lexenne-remember, commit 16c724382bbf8af9f59ed4e5d314fdb5a49f348b, PCC-7096) run over two fixture lessons, two log write-claims, one confirmed supersession resolution, and one tombstone. Every byte under bundle/ came out of the compiler; nothing was hand-written.
  • Is not: an export of our live corpus. That is a larger artifact and separate work. This bundle proves the emission path end to end, no more.

What is planted in it (expected findings)

case where expected reading
write-claim that landed bundle/log.md → okf-conformance-fixture-001 resolves to the concept in bundle/facts/
confirmed supersession (rung 3) bundle/log.md → Supersession under 2026-07-25 names the survivor and superseded lesson by stable id and attributes the resolution to human:1c8998e4, the same pseudonymous fixture human as the asserted lesson
actor-class routing (OKF v0.2 section 7) bundle/claims/ asserted lesson vs bundle/facts/ observed lesson asserted emits generated.by: human:<8-hex> (pseudonymous, derived from the session id when the lesson carries one, otherwise from its stable lesson id); observed emits the process form remember/0.2
basis mapping (#159 enum) same two lessons observed emits basis: live-source; asserted OMITS basis - who stood behind it travels in generated.by, and omission carries no negative claim
write-claim that never landed bundle/log.md → okf-conformance-never-landed-999 never_landed — recorded, nothing behind it
deliberate removal bundle/tombstones.md presence: removed, reason curation, successor named
dangling lifecycle edges concept frontmatter supersedes / contradicts targets ordinary §6.1 tolerance — references, not assertions; contradicts is one-sided and no reverse key is serialized

Presence is sparse per the #207 convention: removed and never_landed are the only values; the default carries no marker.

bundle/tombstones.md is the human narration of a removal. The machine-readable location for absence records is bundle/.manifest.json, under its absences key: every removed and never-landed concept is filed there against its stable remember://lesson/<id>, so a checker never has to parse prose. A removed record carries the tombstone date, the reason, the attributing recorded_by, and a successor where one exists; a never_landed record carries none of those, because nobody recorded that absence — it is inferred by reconciling log.md write-claims against the bundle. The sibling absenceReconciliation key states whether that reconciliation pass actually ran (ok with a parsedCount, failed, or not_run), so an empty never-landed set is never mistaken for a clean corpus that was never examined. entries and absences are mutually exclusive: a currently removed concept is excluded from entries and has no generated page.

One identifier form for the exclusivity check. entries is keyed by bare lesson id for page addressing, but every entries value now carries an id field in the same remember://lesson/<id> form that keys absences. A checker asserts DC-F2 exclusivity by intersecting the id VALUES of entries with the id values (or keys) of absences — one identifier form, no normalisation step — so an empty intersection is a real assertion, not an accident of two disjoint key namespaces (knowledge-catalog #207, leesharks run 08; producer fix PCC-6668). Legacy manifests without the field are backfilled on load. absenceReconciliation also now carries falseRemovalClaims (write-claims that named a removed concept), empty here.

For checker authors — two things you need about our format

  1. Our log prose. Write-claims in log.md look like * **Lesson created**: lesson <id> . The compiler's own reconciliation pass parses them with:

    /^\*\s\*\*[^*]*created[^*]*\*\*:\s+lesson\s+(\S+)/i
    

    Note the claim verb precedes the id.

  2. Our identity scheme. The stable id lives in each concept's frontmatter id: key (remember://lesson/<id> in edge references); filenames are summary slugs and do not contain the id. A checker that resolves claims against filename stems will not resolve ours — it needs to read id: from frontmatter. This is the stable-id-versus-path question from knowledge-catalog #120 showing up as tooling.

Integrity

SHA256SUMS covers every file under bundle/. Verify in a shell:

shasum -a 256 -c SHA256SUMS

License

CC0 1.0 Universal (see LICENSE) — same terms as the deletion conformance fixture this is meant to be tested alongside.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors