Particulars · the Dialectical Knowledge Format

Knowledge that doesn’t go stale.

An open format and CLI for the knowledge you and your AI agents build together. When the world changes, particulars doesn’t overwrite what you knew — it records the challenge, reconciles it, and keeps the reasoning.

Get started Read the spec

The dialectic A thesis and an antithesis are reconciled into a synthesis, which keeps the reasoning and declares what is unresolved. The synthesis becomes the next thesis, ready to be challenged again. thesis what you believed antithesis what challenged it synthesis keeps the reasoning declares what’s unresolved the next thesis …until it’s challenged again

One fact, two fates

In March, Priya owns the billing service. In June, Ada takes over. When billing breaks at 2 a.m. in September — who does your agent page?

One fact, two fates In ordinary memory, the March note that Priya owns billing is never challenged, so in September the agent pages Priya at 2 a.m., wrongly — and nothing knows it is stale. In particulars, a June claim that Ada took over billing challenges the March claim, and a synthesis reconciles them: Ada owns billing since June 12 is the current belief, with the reasoning kept and open questions declared. ordinary memory particulars “Priya owns billing.” March June passes. Nothing challenges it. “Priya owns billing.” September · stale nothing knows it’s wrong — the agent pages Priya at 2 a.m., wrongly “Priya owns billing.” claim · March · thesis challenged “Ada took over billing.” claim · June · antithesis reconciled “Ada owns billing since June 12.” reasoning & open questions kept synthesis · CURRENT the agent pages Ada — and can show why
The same fact, in a memory that stores state and in one that records change.

Overwriting loses the why. Appending loses the truth. Reconciling keeps both.

Notes & wikis

Store the current state. How you got there — and what was rejected along the way — is archaeology in an edit log.

Vector memory

Recalls everything ever said, with no notion of which claims have been superseded — or why.

Docs with expiry dates

A best-before date tells you when to doubt a document — not what’s true now. Refreshing overwrites the reasoning.

Agents propose. You decide.

A particulars workspace is plain YAML in a git repository. Your agent recalls before it asserts, reasons about what it finds, and writes its conclusions on a branch. Everything an agent writes is a proposal until a human merges it.

The collaboration loop In its session, the agent recalls what is already believed, reasons about whether new information extends or contradicts it, and asserts claims and syntheses as YAML files on a branch. It opens a pull request. You review a graph of claims rather than a diff, then merge; merging is acceptance, and the next session starts from what you accepted. your agent’s session recall — what’s already believed? reason — does this extend or contradict? assert & synthesise — on a branch claims/clm_….yaml syntheses/syn_….yaml opens a pull request you review — a graph of claims, not a diff question — amend, or push back merge — acceptance into shared belief the next session starts from what you accepted
The review loop: agents do the bookkeeping, humans keep the authority.

Dogfooded into existence

This isn’t a mock-up. Below is the shareable knowledge in the workspace this format was designed in, at full depth: eight generations of synthesis over nine days, 48 claims reconciled — including the launch of this very site, and the reasoning behind how this page positions itself.

The workspace’s full dialectic, at organisation scope A vertical chain of 8 syntheses, oldest at the bottom, each citing its predecessor as thesis and each reconciling a counted cluster of claims, down to the particular they are all about: the Dialectical Knowledge Format. Every node carries its full text as a tooltip. synthesis · CURRENT — DKF's positioning is now settled in substance, expression, and boundary. Substance: the differentiation from OKF is the update model, not the storage model — both are vendor-neutral plain files in git maintained by humans and agents, but OKF schedules staleness (status/stale_after frontmatter, per its own README) and refreshes by rewriting, while DKF detects staleness through a contradicting claim and reconciles it with a synthesis that keeps the reasoning. Expression: the landing page argues this by category (”docs with expiry dates”), never by name, because named comparisons date a page and invite feature-by-feature rebuttal while categories are evergreen. Boundary: the no-naming decision looked absolute until verbatim workspace knowledge reached the page as proof-graph tooltips, and one claim named OKF; on 2026-08-29 the maintainer resolved the tension as a qualification, not a reversal — the rule governs the page's own voice, while verbatim knowledge names what it names, because redacting the record would falsify it. Both original decisions stand, each in its context, and the boundary case itself illustrates the format's premise: the record outranks the message. synthesis · CURRENT “DKF's positioning is now settled in substance, expression, and boundary. Substance: the differentiation from…” claim · qualifying — OKF (v0.2, Google Cloud Platform) represents knowledge as plain markdown files with YAML frontmatter in git-versioned bundles, and treats trust and freshness as queryable frontmatter metadata: generated/verified derive a trust tier, and status plus stale_after declare whether a concept is still current — staleness is scheduled in advance, and a stale document is refreshed by rewriting it. claim · thesis — DKF's differentiation from OKF is the update model, not the storage model: both are vendor-neutral plain files in git maintained by humans and agents, but OKF schedules staleness in advance (frontmatter status/stale_after) and refreshes by rewriting the document, leaving the why in git history, whereas DKF detects staleness when a contradicting claim arrives and resolves it with a synthesis that carries the reasoning and declares what remains unresolved. claim · thesis — The particulars.fyi landing page positions against OKF-style freshness metadata only by category (its 'docs with expiry dates' card) and deliberately names no competitor, per the maintainer's 2026-08-29 decision recorded in the add-landing-page design: named comparisons date the page and invite feature-by-feature rebuttal, while beating categories is evergreen. claim · antithesis — On 2026-08-29 the maintainer relaxed the landing page's no-naming rule for verbatim workspace knowledge: tooltips in the proof graph reproduce claim text that names OKF directly, while the page's own prose still names no competitor. This qualifies the earlier decision to position only by category. 4 claims cited thesis synthesis — The declared format now has a public face. The previous belief closed with the declaration itself — tag v0.1, 2026-08-26 — and left open only what follows a declaration; what followed, within three days, was its publication surface: the GitHub release ”DKF v0.1” the same day (2026-08-26T02:49:20Z, an announcement of the tag, no artefacts), and particulars.fyi live on 2026-08-29 — a single-page practitioner-facing site served by GitHub Pages from docs/ of the spec repository with enforced HTTPS, so the page versions with the format it describes. The page is addressed to practitioners rather than implementers, staleness-led (”knowledge that doesn't go stale”), and positions only by category, naming no competitor — the qualifying decision records why. Launching was itself a small dialectic: the site's footer contradicted the repo (MIT LICENSE file vs the spec's declared CC0), and the contradiction was resolved the same day by correcting LICENSE to CC0 1.0 Universal. The declaration the previous belief called an invitation for a second implementation now has a public artifact extending that invitation beyond the spec's own README. synthesis “The declared format now has a public face. The previous…” claim · thesis — The v0.1 declaration was published as GitHub release ”DKF v0.1” on 2026-08-26T02:49:20Z: a full release (not draft or prerelease) on tag v0.1 with no assets and an auto-generated changelog-only body, so the release adds an announcement surface for the tag rather than any artefact. claim · thesis — particulars.fyi went live on 2026-08-29: a single-page practitioner-facing landing site served by GitHub Pages from docs/ in the spec repository, with enforced HTTPS. The launch surfaced that the LICENSE file still carried MIT while the spec text declared CC0; LICENSE was corrected to CC0 1.0 Universal the same day (88e0e11). claim · qualifying — The particulars.fyi landing page positions against OKF-style freshness metadata only by category (its 'docs with expiry dates' card) and deliberately names no competitor, per the maintainer's 2026-08-29 decision recorded in the add-landing-page design: named comparisons date the page and invite feature-by-feature rebuttal, while beating categories is evergreen. 3 claims cited thesis synthesis — DKF v0.1 is declared: tag v0.1 (db55fbf), 2026-08-26. The previous belief had narrowed its own unresolved to a single item — only the declaration itself, the maintainer's call and outside what any change could settle — and this closes it: the maintainer made the call, and made it as the spec's Status framed it, a deliberate act performed as a tag with no accompanying text change. Eight days separate the draft that asked for feedback from the declared format. The trajectory the earlier syntheses recorded holds to the end: nineteen reference-implementation items across five issues, three rounds where implementation pushback changed the spec text, one round where the spec moved first and every objection was adopted, and a final blockers round hardened by a parser probe that turned a prudent rule into a provably load-bearing one. The declared format is the one this workspace is written in — the declaration changes no byte here, which is itself the compatibility story working: a workspace written against the draft is a conforming v0.1 workspace, undeclared evidentials and legacy provenance included, because every evolution was reader-lenient by construction. synthesis “DKF v0.1 is declared: tag v0.1 (db55fbf), 2026-08-26. Th…” claim · thesis — DKF v0.1 was declared on 2026-08-26: tag v0.1 on nodelogicau/particulars points at db55fbf, the archive commit of clear-v01-blockers. The tagged Status says nothing remains open and frames the declaration as a deliberate act rather than a side effect of the last change landing — which is what the tag is: no text changed, the act was the tag itself. 1 claim cited thesis synthesis — The previous belief committed its next update to be the declaration or the reason it did not happen; what happened instead was the precondition landing. On 2026-08-26 the three blockers cleared in one reviewed round: the signed payload is the typed data model minus retracted and signature under RFC 8785, never file bytes; public discovery is a normative publishing contract with crawling deliberately out of scope; and urn:dkf: ships deliberately unregistered, collision-proofed by the workspace UUID every minted URN embeds. The signing decision corrected the spec's own past: the claim that canonical field order was a prerequisite for signing was removed as false, the error being a conflation of the two artefacts of determinism — the hash covers bytes, the signature never needed to. The review then hardened the result the way every round here has been hardened: a parser probe showed a YAML 1.2 library typing unquoted timestamps as native time values, converting the typed-data-model rule from prudent to provably load-bearing, and the alias prohibition's justification was corrected from signing integrity to resource exhaustion, since aliases resolve before the payload exists. Status now lists nothing. Sixteen capabilities, ten archived changes, nineteen feedback items resolved across nineteen days of drafts and eight days of implementation dialogue, and the spec's closing sentence assigns the one remaining act to a person: declaring v0.1 is deliberate, not a side effect. synthesis “The previous belief committed its next update to be the…” claim · thesis — DKF defined its signed payload on 2026-08-26 (e571d3b): the object parsed to its typed data model with retracted and signature removed, canonicalised per RFC 8785, never the file bytes. A signature therefore survives reformatting, field reordering, and retraction-appending, and confidence 0.9 and 0.90 sign identically. Signature suites remain reserved — v0.1 defines only what the bytes would be. claim · thesis — The claim that canonical field order was a prerequisite for signing was removed from DKF as false: under a data-model payload, file layout never touches the signature. The error was conflating the two artefacts of determinism — the document hash covers bytes, the signature never needed to. Canonical order keeps its diff-review rationale, which was always the stronger half. claim · qualifying — The strings-stay-strings mapping rule in DKF's signing payload is provably load-bearing, not merely prudent: the reference implementation measured gopkg.in/yaml.v3 — a YAML 1.2 parser — returning an unquoted timestamp as native time.Time under generic decode, so a payload built by generic YAML-to-JSON conversion silently mistypes the field. The spec therefore states the payload is built from the parsed, typed data model, never from a generic conversion. claim · qualifying — DKF's prohibition on YAML anchors and aliases in object files carries a resource-exhaustion rationale, not a signing rationale — the reference implementation measured aliases expanding silently before the data model exists, so two files differing only in aliases produce identical payloads. The initial draft justified the prohibition by signing integrity, which the review corrected: prohibiting something for a reason it cannot affect is borrowed justification. claim · thesis — DKF's Public Discovery section became a normative publishing contract on 2026-08-26: manifest keys, site-root path resolution, every published object fetchable at feed path plus id, only effective-scope-public served with the promotions feed as a consumer's verification, and the index as a potentially lagging enumeration. Crawler behaviour — scheduling, change detection, politeness — is deliberately out of scope, on the model of .ics and RSS. An authenticated private surface is not a feed. claim · thesis — DKF ships v0.1 with urn:dkf: deliberately unregistered, stated in the spec rather than left as an admission: the NID syntax conforms to RFC 8141, every minted URN embeds the workspace UUID so collision requires a UUID collision, and registration would change no identifier and may follow later. Gating the release on an IANA review queue was rejected as inverting the project's cadence. claim · antithesis — As of 2026-08-26 (db55fbf) DKF's Status lists nothing open before v0.1: 16 capabilities, 10 archived changes, zero open issues on both repositories, 19 feedback items resolved. The spec states that declaring v0.1 is a deliberate act, not a side effect of the last change landing — the declaration is the only act remaining in the project. 7 claims cited thesis synthesis — As of 2026-08-26 the DKF draft has absorbed all 18 feedback items across both repositories and holds zero open issues anywhere, with 15 capabilities and 8 archived changes. The previous belief's ”one decision away from v0.1” understated what remained; what actually followed was three more rounds, each smaller and later in the stack than the last: index tolerance extended to unknown entry types so a future record type cannot break existing drift checks, the held-confidence rule split into three verbs so that writers refuse, validators fail, and readers never strand an uncorrectable file, and a condition-reporting capability distinguishing findings about objects from facts about the corpus. The pattern across the three is that the spec's remaining defects were all at the seams where tooling meets the format — a cache rebuilt by an older tool, a rule ambiguous between write and read, a warning strategy that assumed warnings get read — rather than in the object model, which has not moved since the evidential landed. The reporting round also demonstrated the review loop working in both directions in one issue: the spec's classification caught a shipped renderer defect (severity used as a proxy for corpus-facts), and the implementation's diagnosis of why the proxy failed — severity answers how much, the split answers where to look — is a better justification for the capability than its own design doc carried. What remains before v0.1 is exactly the three items Status has named for four days, and nothing else is open or in flight for the first time since the project began. synthesis “As of 2026-08-26 the DKF draft has absorbed all 18 feedb…” claim · thesis — DKF resolved issue #16 on 2026-08-26 (4bc94b2): index tolerance now covers entry types as well as fields, a rebuild preserves entries whose type it does not recognise, and a drift check does not report them — a check must not fail on evidence of a newer conforming writer. Without this, every future record type broke every existing index --check, and a rebuild by an older tool silently stripped the newer rows from the cache. claim · thesis — DKF's held-confidence rule names three roles with three verbs as of a275d34: writers refuse to create the claim, validators fail validation reporting confidence_on_held, and readers still read the file — it cannot be corrected, so a reader that rejected it would strand it permanently. It is the first rule in the format where the write-side and read-side verbs genuinely differ. claim · thesis — DKF gained a condition-reporting capability on 2026-08-26: a finding about an object (drift, scope_wider_than_inputs, an unverifiable defect) reports per object because the object is the unit of action, while a fact about the corpus (undeclared, legacy markers, unverified documents) aggregates, because its discovery value is spent on first sight, its cost recurs on every run, and it can never be cleared without rewriting an immutable file. An aggregate line carries a count always and a message only when uniform across the group. claim · qualifying — The review question on particulars-cli#4 found a real defect in the CLI's renderer: it used severity as a proxy for the corpus-fact pile, so defect_unverifiable — informational but naming one specific retraction a reviewer would open — vanished into a count line. The diagnosis generalises: severity answers how much this matters, the reporting split answers where the reader should look; they correlate, and correlation was all it was. claim · antithesis — As of 2026-08-26 the DKF spec has 15 capabilities, 8 archived changes, and zero open issues on both the spec and reference-implementation repositories, with all 18 feedback items absorbed. The only work standing before v0.1 is declared is the three blockers: the signed payload's serialisation basis, the .well-known crawling protocol, and registration of the urn:dkf: namespace. 5 claims cited thesis synthesis — As of 2026-08-26 the DKF draft has taken three further rounds and is one decision away from v0.1. Issue #15 — which the previous belief recorded as undecided — was resolved by generalising the existing no-cascade warning rather than adding a rule: warn when a synthesis's effective scope exceeds any input's, because reconciling private evidence into a shareable conclusion is legitimate and no tool can judge whether prose discloses its sources. The substance of the period is that provenance became checkable and claims became honest about what backs them. A document reference may now carry a hash and a verbatim quote; drift is read from both together, since a quote can survive intact inside a document whose surrounding context has changed underneath it. A retraction may declare why the claim died, and that declaration is what finally makes harness attribution computable — the format recorded who produced a claim from the first draft and never whether they produced it soundly. Every claim now declares an evidential, confidence is defined for the first time and forbidden where nothing backs the claim, and a synthesis carries a method instead, the two axes being orthogonal. The round also produced the project's first spec-first change and its first defect. Applying verifiable-provenance before the implementation reviewed it cost a review of merged text and shipped a cross-check that was a category error: drift is a signal about the source joint while supersession asserts the world moved. The implementation declined to ship it and was right. Its review then supplied the LF normalisation rule, the deciding argument for ref over uri, and an evidence-based answer to whether the format should distinguish living documents from dated ones — no, because against a living document the ordinary way a fact goes stale is that reality moves and the documentation lags. The evidential was folded into v0.1 rather than deferred, because declaring v0.1 is the invitation for a second implementation and breaking is cheap only while one exists. synthesis “As of 2026-08-26 the DKF draft has taken three further r…” claim · antithesis — DKF resolved issue #15 on 2026-08-24 (fd75a11) by generalising the existing no-cascade warning rather than adding a rule: implementations SHOULD warn when a synthesis's effective scope is wider than the effective scope of any input it cites, reported as scope_wider_than_inputs. Warning was chosen over requiring because reconciling narrowly-scoped evidence into a shareable conclusion is a legitimate reason to synthesise and no tool can judge whether prose discloses its sources. claim · thesis — DKF made provenance checkable on 2026-08-25 (7dac8dd): source.document may be a mapping carrying a reference, a hash, and a verbatim quote. The locator is a quote rather than an offset because insertion elsewhere in a document moves an offset without changing what it points at, and because a quote lets a reviewer audit a claim in a pull request with no tooling. claim · thesis — DKF reads source drift from two signals rather than one: whether the quote still appears and whether the document hash still matches. A quote present in a changed document is context drift, which catches the case a quote hash alone misses — ”In staging, the billing service listens on 443” yields a claim that a change to ”In production” falsifies without touching the quote. claim · thesis — A DKF retraction may declare a kind of defect, supersession, or provenance-failure, which are the three joints in the chain claim to source to world rather than a chosen taxonomy. It is declared and never derived from superseded-by, because the most common defect is a typo correction that carries a replacement while a decommissioned subject is an honest supersession with nothing to point at. claim · thesis — Retraction kind is what makes DKF's harness attribution computable for the first time. The format recorded source.harness from the first draft and no implementation could act on it, because nothing recorded whether a claim was sound: a defect counts against the process that produced the claim, a supersession counts against nothing, and a provenance-failure counts against the cited document. claim · thesis — DKF requires an evidential on every claim as of 2026-08-26 (fdab9f9): observed, inferred, or held, with no default. Readers accept its absence and report undeclared, which is not a fourth value and not a synonym for observed. Claims are immutable so no existing claim can be backfilled, and the distinction ages out as new claims are written rather than being migrated. claim · thesis — DKF defines confidence for the first time as the inverse probability that a claim is mistaken, and forbids it on a held claim, reported as confidence_on_held. A position is not mistaken in the way a probability describes. This is the only mechanically enforceable rule in the area — scope width, drift and retraction kind can each only warn, because judging prose is not something a machine does. claim · qualifying — A DKF synthesis declares no evidential because it is backed by argument from its inputs by construction, and carries method instead. Evidential and method are orthogonal: a synthesis is reached by argument whether the question was factual or evaluative. A positions synthesis may still take a position, since Aufhebung produces a new position rather than surveying and declining, but recording an evaluative conclusion as reconciliation is invalid. claim · antithesis — DKF removed its supersession cross-check on 2026-08-26 (9388161) as a category error rather than a miscalibration: drift is a signal about the source joint while supersession asserts the world moved, and the format cannot tell a document describing current state from one dated by design. A claim citing an architecture decision record or a commit-pinned URL cites something supposed to stay byte-identical while the world moves, so the check fired on the ordinary case. claim · thesis — The sound replacement for DKF's removed cross-check runs the other way: a defect declared against a document that has drifted is unverifiable, because the text the claim is said to have misread is no longer the text a reviewer can read. That is a statement about what can be checked rather than a guess about intent, which is the line separating every warning this format keeps from the one it removed. claim · thesis — DKF renamed document.uri to document.ref because a field holding only URIs cannot hold what a third of the format's own examples describe. The deciding case was not repository-relative paths but unfetchable sources: an unfetchable source can still carry a quote, and quoting what someone said with nothing to fetch is provenance a reviewer can weigh. Readers accept uri as a legacy alias and warn, because a file carrying it can never be rewritten. claim · qualifying — A DKF document hash is taken over the document with CRLF sequences normalised to LF and nothing else altered. The rule is to normalise what is an artefact of transport and leave every edit visible: line endings differ by platform so hashing raw bytes would report drift on every claim in a Windows checkout, while trailing whitespace differs because someone edited the file. Writers should write sha256; readers accept any algorithm and report an unrecognised one as unverified. claim · qualifying — DKF decided against distinguishing living documents from dated ones, on evidence rather than principle. A hand-written classifier over 76 real documents misread about a fifth of them, and more decisively the distinction does not rescue the removed check: against a living document the ordinary way a fact goes stale is that reality moves and the documentation lags, which is an unchanged hash under an honest supersession. claim · thesis — The evidential was folded into DKF v0.1 rather than deferred to v0.2, on the reasoning that declaring v0.1 is the invitation for a second implementation to appear and breaking the format is cheap only while one exists. What remains open before v0.1 is declared is the signed payload's serialisation basis, the .well-known crawling protocol, and registration of the urn:dkf: namespace. claim · qualifying — The verifiable-provenance round was the first DKF change to originate from a design review rather than from reported feedback, and the first applied before the reference implementation reviewed it. That ordering cost a review of already-merged text and surfaced a defect the implementation declined to ship. The correcting change was posted for review before being applied, and the ordering has been corrected since. claim · antithesis (qualifying) — This workspace triggers the checks the spec added because of it: validate reports scope_wider_than_inputs on two syntheses written here on 2026-08-22, both organisation-scoped syntheses reasoning from personal claims, which is the exact condition issue #15 was filed about. claim · antithesis (qualifying) — Every claim in this workspace is undeclared under the evidential requirement, including the claims recording that the requirement exists, because particulars-cli v0.8.0 predates it and has no --evidential flag. This is the transitional state the spec describes rather than a defect: writers must declare once tooling can, readers report undeclared, and the distinction ages out. 17 claims cited thesis synthesis — Scope by derivation is filed after all: issue #15 was opened at 05:05Z on 2026-08-22, minutes before this workspace recorded that no issue existed. That earlier statement was wrong and is corrected here rather than edited. The gap itself stands as described, and #15 frames it more precisely than the note it supersedes: scope protects assertions individually but not by derivation, and any implementation that honours per-claim scope while letting syntheses cite freely inherits the hole by default rather than by mistake. #15 proposes requiring, warning, or explicit silence, and recommends warning — specified rather than per-implementation, so scope_wider_than_inputs means the same thing in every tool. Warning is the right call over requiring, and for the reason #15 gives: reconciling private evidence into a shareable conclusion is a normal, legitimate reason to synthesise, and no tool can judge whether prose discloses its sources. Requiring would forbid the format's most useful move. What neither issue accounts for is that promotion records landed hours after the CLI check was written. The comparison must be effective scope against effective scope, or it warns when an input is personal but promoted, and stays silent when the synthesis itself is promoted past its inputs. The two rounds have produced two ways to widen exposure with very different ceremony — promotion is explicit, sourced and retractable; asserting a synthesis at a wider scope is none of those — and #15 is where that asymmetry has to be reckoned with. synthesis “Scope by derivation is filed after all: issue #15 was op…” claim · qualifying — A synthesis's scope does not inherit from its inputs, so an organisation- or public-scoped synthesis can summarise personal-scoped claims and carry their substance into a public index while the claims themselves are correctly withheld. Observed on 2026-08-22: exporting DKF Public Discovery emits the belief with claimCount 0 — the three supporting claims are personal and excluded — yet the synthesis text quotes and argues from them. Scope therefore protects assertions individually but not by derivation. claim · qualifying — The DKF no-cascade rule shipped on 2026-08-22 governs only promotion: promoting a synthesis does not widen the claims it cites. It does not address a synthesis asserted at a wider scope than its inputs in the first place, which is a separate path by which narrow claims' substance reaches a wide audience. The spec constrains derived scope in neither direction, so scope still protects assertions individually rather than by derivation. claim · antithesis — Issue #15 was filed on nodelogicau/particulars at 2026-08-22T05:05:38Z and is open: a synthesis does not inherit its inputs' scope, so an organisation or public synthesis may quote personal claims and carry their substance past the per-claim scope check. It offers three closures — require a synthesis's scope to be no wider than its narrowest input, define a warning, or state that derived disclosure is the author's responsibility — and recommends the warning, specified rather than left to implementations. particulars-cli already emits scope_wider_than_inputs (commit 5a50421). claim · antithesis — The scope_wider_than_inputs condition proposed in issue #15 must be defined over effective scope rather than asserted scope, because promotion records landed after the check was written. Comparing asserted scopes would warn spuriously when an input is personal but covered by a promotion, and would fail to clear when the synthesis itself is promoted. No one has raised this interaction on either issue. 4 claims cited thesis synthesis — As of 2026-08-22 (commit c5782e1) the DKF draft has absorbed a second round of reference-implementation feedback, closing #11-#14 and returning the spec to zero open issues. The three items recorded as open on 2026-08-22 are resolved: field order is canonical per type with writers SHOULD emit and readers MUST accept (#11), a .dkf pointer plus an explicit discovery precedence lets tools that start above a workspace find it (#12), and synthesis_create takes particular_id because cross-particular inputs make the subject underivable (#13). The round's substance is #14. Promotion is now a record: knowledge_publish writes publishes/pub_<uuidv7>.yaml, and effective scope is the widest non-retracted promotion covering an object, defaulting to its asserted context.scope. This answers the export that produced zero items from 38 personal claims — that workspace becomes publishable without re-assertion, keeping ids and lineage — and it makes defaults.scope a recoverable choice rather than a one-way door. Two rules do the safety work. Promotion may only widen, so a consumer ignoring /publishes/ withholds what was authorised instead of exposing what was restricted; under-sharing is a bug report, leaking is a breach. Promotion does not cascade to a synthesis's inputs, so widening a lineage stays deliberate. Two findings emerged from specifying rather than from the issues. ”Canonical object” in the signing paragraph had no referent, so signing was blocked on field order all along. And knowledge_publish had no source parameter, so it could not record the source the spec demanded of it; both are fixed. The baseline now carries twelve capabilities, adding scope-promotion and canonical-serialisation. Two of the four issues were contradictions the previous round introduced, which is the pattern to watch: resolving feedback in one place created it in another. synthesis “As of 2026-08-22 (commit c5782e1) the DKF draft has abso…” claim · antithesis — A synthesis's scope does not inherit from its inputs, so an organisation- or public-scoped synthesis can summarise personal-scoped claims and carry their substance into a public index while the claims themselves are correctly withheld. Observed on 2026-08-22: exporting DKF Public Discovery emits the belief with claimCount 0 — the three supporting claims are personal and excluded — yet the synthesis text quotes and argues from them. Scope therefore protects assertions individually but not by derivation. claim · thesis — DKF resolved issue #11 on 2026-08-22 by making each type's documented field order canonical: writers SHOULD emit it, readers MUST accept any order, and implementation-added fields go after all specified fields. The merge record's order was fixed to the README example (id, type, uris, reason, source, timestamp) rather than the requirement prose. claim · qualifying — Before issue #11 the DKF spec defined the signed payload as ”the canonical object minus retracted and signature” while never defining canonical order anywhere, so signing could not have been specified: two conformant writers would have produced different payloads for the same claim. Canonical order was therefore a prerequisite for signing, not a cosmetic concern. claim · thesis — DKF resolved issue #12 by blessing an optional .dkf pointer file whose first non-blank, non-comment line names the workspace root, for tools that start above a workspace. dkf.yaml wins at the same level, pointers do not chain, and the spec now also states discovery precedence for the first time: explicit workspace argument, then environment variable, then walk-up. claim · thesis — DKF resolved issue #13 by adding particular_id to synthesis_create and stating that every claim and synthesis carries exactly one caller-supplied subject which implementations MUST NOT infer from inputs. The omission was introduced by the 2026-08-21 round itself, which blessed cross-particular inputs without updating the tool signature that supplies the subject. claim · thesis — DKF resolved issue #14 by defining promotion as a record: knowledge_publish writes publishes/pub_<uuidv7>.yaml naming claims, a target scope, source and timestamp, and an object's effective scope is the widest non-retracted promotion covering it, defaulting to its asserted context.scope. Claims stay immutable and keep their ids and lineage. claim · thesis — DKF promotion may only widen an object's scope, never narrow it, so that a consumer which ignores /publishes/ and honours context.scope withholds something authorised rather than exposing something restricted. Narrowing is expressed by retracting the promotion or the object, which is visible on the file such a consumer already opens. claim · qualifying — The DKF tool table's knowledge_publish had no source parameter until 2026-08-22, so it could not record the source that ”promotion to public is an explicit act recorded with a source” required of it. The signature is now knowledge_publish(claim_ids[], scope, source, reason?). claim · antithesis — The DKF no-cascade rule shipped on 2026-08-22 governs only promotion: promoting a synthesis does not widen the claims it cites. It does not address a synthesis asserted at a wider scope than its inputs in the first place, which is a separate path by which narrow claims' substance reaches a wide audience. The spec constrains derived scope in neither direction, so scope still protects assertions individually rather than by derivation. claim · qualifying — The DKF baseline specification set grew from ten capabilities to twelve on 2026-08-22, adding scope-promotion and canonical-serialisation, with seven existing capabilities merged in place rather than appended. The change resolve-v01-blockers is archived at openspec/changes/archive/2026-08-22-resolve-v01-blockers/ and the spec repository has no open issues. 10 claims cited the subject of every claim above particular — Dialectical Knowledge Format (https://github.com/nodelogicau/particulars): the subject of every claim and synthesis in this graph. particular Dialectical Knowledge Format
Generated from the project’s own workspace with particulars export --format mermaid --subject "Dialectical Knowledge Format" --scope organisation on 29 August 2026 — full depth, ids omitted, claims drawn as clusters, the subject particular added for orientation. Hover any node — every square is a real claim, carrying its full text from the export’s tooltips · see the v0.1 release

Start in your terminal

Install the CLI, make a workspace, and teach your agent the discipline — recall before you assert, reconcile when you contradict.

$ brew install nodelogicau/tap/particulars
$ particulars init ./knowledge --author you
$ particulars skill install
$ particulars particular define --label "Billing service"
$ particulars claim assert --subject "Billing service" \
    --content "Ada took over billing from Priya on June 12." --evidential held
$ particulars recall "Billing service"

From there, your agent does the bookkeeping: the installed skill teaches it the verbs, and every session builds on what you’ve accepted.

Today: the CLI, the agent skill, and a local MCP server — one click in Claude Desktop via the .mcpb bundle, or particulars serve --mcp for any client.  ·  In design: remote MCP.