Donto: State of the Program, Novelty, and Direction Map

Date: 2026-06-04
Author: Codex audit pass over the local Donto/genes/memory workspace
Scope: canonical local reports and paper notes, rewrite PRDs, active services, live discovery endpoints, selected code paths, and primary prior-art references.

Executive Verdict

Donto is real, but it is not yet the thing its best documents describe.

The real part is substantial: there is a live Postgres/Rust substrate, a versioned HTTP contract, DontoQL/SPARQL query surfaces, policy/evidence/argument/identity/alignment overlays, active consumers, a long research trail, and roughly 39.5 million currently believed statements on the running box. This is not a slideware database idea. It is an operating substrate with migrations, services, metrics, and consumer pressure.

The unfinished part is equally central: the product core is not "a lot of triples." The product core is the lifecycle that turns abundant, messy, generated claims into ranked, evidence-aware, contradiction-preserving discoveries:

1. ingest source material;
2. emit many typed/free claims;
3. hold mutually incompatible claims without collapsing the graph;
4. generate relationship hypotheses across claims/entities/events;
5. attach evidence and counter-evidence;
6. rank claims and relationships;
7. re-rank as transaction time and valid time change;
8. explain why a claim, match, identity, or contradiction is currently believed.

Steps 1 and 2 are now quite alive. The substrate for steps 3, 5, and parts of 8 exists. Steps 4, 6, and the closed-loop version of 7 remain the main unbuilt product. That matters because Donto's novelty is not "we store statements" or "we use Postgres." Its novelty is the promise that an abundance-native system can keep the firehose instead of prematurely cleaning it, then recover precision later through evidence, argumentation, identity lenses, predicate alignment, policy, and ranking.

My rigorous opinion: Donto is novel as a composition and operating discipline, not as a single primitive. RDF-style named graphs, provenance models, bitemporal databases, paraconsistent logic, argumentation frameworks, graph memory systems, and skill taxonomies all exist. What I did not find in the local system or the primary prior-art scan is a close equivalent to Donto's exact bet: an append-only, bitemporal, paraconsistent claim substrate built specifically for LLM-era generative abundance, where free predicates are allowed at write time, alignment and identity are deferred to query time, evidence/policy are first-class, contradictions remain legal state, and consumer applications are used as substrate proof obligations.

The strongest version of the idea is this:

Donto is a persistent possibility-space for machine-generated claims. It treats extraction abundance as the scarce new primitive, stores claims before they are fully normalized, preserves contradiction instead of overwriting it, and makes later alignment, identity, evidence, policy, and ranking the place where knowledge becomes usable.

That is a good idea. It is also dangerous: if the relationship generator, ranker, evidence coverage, and query-time alignment do not become first-class, Donto becomes an expensive archive of extraction debris. The next phase should therefore be brutally focused on proving that the abundance can be converted into better decisions than a conventional pipeline.

What Donto Is

Donto is best understood as a claim substrate, not a conventional knowledge graph product.

At the storage level, the core row is a donto_statement:

• subject;
• predicate;
• object;
• context;
• transaction time;
• valid time;
• polarity and maturity;
• content hash/idempotency metadata;
• surrounding overlays for evidence, arguments, identity, alignment, policy, blobs, health, and consumer-owned state.

The running implementation is deliberately conservative infrastructure:

• Postgres 16 is the real state and logic layer.
• Rust dontosrv is a thin Axum HTTP shell over donto-client.
• donto-query parses/evaluates DontoQL and a SPARQL subset.
• SQL migrations define most semantics.
• Lean exists as an optional verification sidecar, not as the current hot path.
• Consumers can bind through HTTP, TypeScript, Python, or Rust.

That architecture is pragmatic. It does not require inventing a database engine before proving the model. It also makes Donto's claim more specific: this is not novelty at the storage-engine layer. It is novelty in the contract enforced on top of a normal database.

The contract has three unusually important ideas.

First, write-time acceptance is permissive. Claims can be minted freely. Predicates do not need pre-registration. Subjects do not need canonical identity at insertion. The system does not force one ontology or one truth at the door.

Second, claims should be evidence-backed or explicitly marked as hypotheses. The local contract says an anchorless, non-hypothesis_only claim is not rejected, but capped to candidate maturity when the invariant is enabled. This is the right abundance-compatible stance: keep the claim, lower its evidential status.

Third, contradiction is legal state. Retraction closes transaction time rather than deleting rows. Current belief is a query-time projection, not the only thing the database remembers.

Live Snapshot

I verified the live contract and health endpoint on 2026-06-04.

GET http://127.0.0.1:7879/health returned ok.

GET /discovery/contract-version returned:

GET /discovery/substrate-health returned:

The distinct_subjects = 0 value should not be read as "there are no subjects." It is more likely a disabled, estimated, or degraded metric path in the resilient health view. The count is not plausible next to 39.5 million statements. The correct engineering response is to label this health field as degraded or add a cheaper approximate subject metric.

The running systemd services also show that Donto is more than one daemon:

Small exact side-table probes were possible through DONTO_DSN without full-table scans:

Argument relations:

Identity edges:

The donto_stmt_hypothesis_only table currently contains 0 rows. That is a useful warning: the hypothesis-only contract exists in schema and HTTP request shape, but the live corpus is not exercising that overlay.

Prior Art Baseline

Donto should not claim that each primitive is new. Many of its pieces are established.

RDF and SPARQL already have triples, graphs, datasets, and named graph concepts. W3C RDF 1.1 defines RDF datasets with named graphs; SPARQL queries graph patterns over those datasets. Donto's subject/predicate/object/context shape is clearly related to that lineage.

PROV-O already provides a W3C provenance ontology for representing how data was produced, derived, attributed, and used. Donto's evidence links and source/revision/span model belong in that provenance family, though they are tailored to claim-level extraction anchors.

RO-Crate already addresses packaging research objects with data and metadata. Donto's future release/federation direction can reuse or interoperate with that world rather than inventing a release format from nothing.

Bitemporal databases already exist. XTDB is explicitly bitemporal and tracks system time plus valid time across data. Datomic stores immutable facts and supports historical "as of" database views. Donto's tx_time and valid_time are therefore not novel as database temporality.

Paraconsistent logic is a long-standing branch of logic concerned with inconsistency-tolerant reasoning. Donto's "contradictions do not explode the graph" stance is an application of that family, not an invention of paraconsistency.

Formal argumentation frameworks, especially the Dung lineage, already model arguments and attack/support relations. Donto's supports, rebuts, supersedes, and frontier concepts are aligned with this established field.

LLM-generated knowledge graph work already proves that massive machine-generated triples are plausible. GPTKB reports a 105M-triple LLM-materialized knowledge base. AutoSchemaKG/ATLAS reports a web-scale graph with hundreds of millions of nodes and billions of edges through autonomous schema induction. Microsoft GraphRAG uses LLM-derived graphs for retrieval over text corpora. These systems weaken any claim that "LLMs can generate graphs" is itself Donto's differentiator.

Agent memory systems are also converging on temporal graphs. Zep/Graphiti describes temporal context graphs with timestamps and fact invalidation; Mem0 has graph memory over nodes, edges, and embeddings. Donto-memory sits in a nearby space.

Jobs and skills are not a blank domain either. ESCO, O*NET, and Lightcast all provide occupation/skill taxonomies or labor-market skill data; TalentCLEF-style benchmarks target job title and skill intelligence. The planned jsonresume -> jobs flagship must beat or augment this landscape, not pretend it does not exist.

The important conclusion: Donto's novelty cannot be defended as "we have triples," "we have provenance," "we have bitemporality," "we have temporal memory," or "we use an LLM to make a graph." Those are weak claims.

Where Donto Is Actually Novel

Donto's stronger novelty is the way it combines the above primitives around one economic shift: generated typed claims are becoming abundant.

Most knowledge systems are designed as if extraction is scarce and cleanliness must be imposed early. They ask the extractor to fit a schema, collapse identity, remove contradiction, and output a small clean graph. That made sense when extraction cost dominated and downstream storage/compute were expensive.

Donto flips the pressure:

• generation is cheap enough to extract far more;
• the model is allowed to invent predicates;
• contradictions are expected;
• identity is a hypothesis;
• predicate alignment is a query-time expansion problem;
• evidence anchors are the upgrade path from raw abundance to trust;
• ranking is a later computation over accumulated evidence and counter-evidence.

That is the original part. It is not one feature. It is an end-to-end discipline.

1. Abundance-Native Write Contract

The write contract says: emit freely, but keep evidential maturity visible. That means the database can accept messy output without pretending all output has equal status.

This is not the same as a lax graph import. The intended invariant is stricter: a promoted claim should either have evidence or be explicitly acknowledged as a hypothesis. The claim is kept, but its maturity is controlled.

That is a good fit for LLM extraction. A model can notice an event, an implication, a paraphrase, a contradiction, a social relation, or a skill signal before the system knows what ontology should contain it.

2. Query-Time Alignment and Identity

Free predicates normally cause chaos. Donto's answer is not to prevent them. It is to build predicate descriptors, nearest-neighbour alignment, relation closure, schema lenses, and identity lenses so that consumers can ask different questions with different degrees of expansion.

That is a real design bet. It avoids the worst failure mode of early ontologies: losing signal because the schema did not have a bucket for it yet. It also avoids the worst failure mode of naive abundance: treating string variants as separate forever.

The bet only works if alignment becomes excellent. Today the local docs already recognize the problem: hundreds of thousands of predicates, high singleton rates in extraction-specific corpora, and the need for embedding fabric because lexical similarity is not enough. The alignment daemon and predicate descriptor APIs are the right direction, but this is still one of the central engineering risks.

3. Paraconsistent Possibility-Space

Donto stores contradictory claims as normal state. It does not force immediate resolution. That is especially valuable in genealogy, historical research, litigation, scientific claims, intelligence, medicine, and labor-market inference, where the question is often not "what is the fact?" but "what are the competing claims, what supports each, when did we believe each, and what changed?"

This is more than append-only history. Append-only history can still present only one truth. Donto wants contradiction to remain queryable, rankable, and explainable.

4. Evidence as a First-Class Upgrade Path

The source/revision/span/evidence-link model is the right bridge from abundant extraction to usable claims. It lets a system say:

• this claim came from this source;
• this exact span supports it;
• this other span counters it;
• this claim was derived from another claim;
• this row is still raw because it lacks support;
• this consumer can or cannot see the source or quote the anchor.

That is much stronger than a vector chunk citation pasted into an answer. It is also hard. Live anchor coverage is only 4.86 percent, so Donto's philosophy is ahead of its corpus.

5. Consumer-Driven Substrate Proof

The rewrite PRDs correctly insist that Donto is the substrate and consumers are proof obligations. Genes, memory, and the planned jobs matcher should not be demos bolted into the same repo. They should be independent consumers that bind through the contract and force the substrate to handle real contradictions, temporal shifts, policy constraints, evidence anchors, and identity ambiguity.

That is one of the most important strategic choices in the local docs. A substrate cannot be proven by unit tests alone. It needs hostile consumers.

6. The Claim Lifecycle as Product

The local claim-substrate report is right: the product is not "Donto stores claims." The product is the full claim lifecycle. That lifecycle, if implemented, would make Donto a discovery engine rather than a graph database.

This is the heart of the novelty claim:

• generate abundant claims;
• keep incompatible candidates;
• discover relationships between them;
• attach evidence and counter-evidence;
• rank and re-rank;
• explain the current belief state.

The database is a means to that lifecycle. The lifecycle is the product.

Direction Map

The local workspace shows several Donto directions. They are not all equally mature.

1. Substrate Core

This direction is the domain-neutral core:

• durable migrations;
• stable discovery surface;
• DontoQL/SPARQL;
• evidence, argument, identity, alignment, policy, blob, and health overlays;
• source/resource registration;
• consumer overlay registry;
• bitemporal history and retraction discipline.

This is the foundation, and it is the most real part today. The key next step is less feature expansion and more contract hardening:

• make /assert and /assert/batch semantics consistent;
• make error status behavior less surprising or very loudly documented;
• make WITH evidence return evidence shapes, not only parse intent;
• make health metrics clearly exact, estimated, disabled, or degraded;
• make policy behavior fast enough under real corpus sizes;
• keep domain-specific extraction code out of substrate boundaries.

2. Unified Extraction Engine

The rewrite PRDs identify extraction duplication as a major problem. The target is a separate donto-extract engine with provider abstraction, claim model, lens packs, eval harness, and clean separation from substrate code.

This is the "faucet" direction. It matters because Donto's thesis depends on extraction abundance. A weak extraction engine makes the substrate look unnecessary. A strong extraction engine without substrate discipline becomes unmanageable debris.

The recent research reports show serious progress:

• provider rotation and cap-aware lanes;
• OpenCode-driven iterative extraction;
• multi-pass gleaning until saturation;
• JSONL/compact output to avoid giant single writes;
• cross-domain tests beyond genealogy;
• post-hoc citation/anchor repair experiments;
• a shift from "count more facts" to "measure coverage and saturation."

The highest-leverage next move is to make extraction output a strict Claim object that always carries provenance state: anchored, anchor-needs-repair, or hypothesis-only. That pushes the write invariant upstream where it belongs.

3. Embedding and Alignment Fabric

The embedding fabric direction is essential, not optional. Free predicate minting only works if the system has semantic retrieval over predicates, entities, statements, spans, documents, contexts, and maybe claims-as-cards.

The local embedding report's point is correct: lexical matching cannot join killed, murdered, slew, and assassinated reliably. The system needs embeddings to cluster and rank candidates. It should not use embeddings to destructively collapse identities or predicates.

The clean rule is:

• embeddings propose;
• alignments record;
• lenses expand;
• consumers choose strictness;
• nothing is silently merged away.

That preserves the paraconsistent substrate while making abundance usable.

4. Resource Storage and Retrieval

The resource-storage direction is about making the evidence chain retrievable:

fact -> evidence_link -> span -> revision -> document/resource -> blob.

This is boring in the best way. Donto's evidence-first claim is only credible if every important claim can be walked back to source material with policy-aware access. The GCS-backed store-resource path and source retrievability SQL are therefore core substrate work, not peripheral storage plumbing.

The highest risk is partial adoption: some sources in GCS, some loose files on disk, some spans without revisions, some claims with run-level evidence only. That creates a provenance story that looks good in diagrams but fails under audit.

5. Trust, Policy, and Governance

Donto has the right instincts around policy:

• actions like read, quote, export, train, publish, share, and request deletion;
• policy capsules;
• attestations;
• fail-closed defaults;
• policy-aware recall;
• resource tombstones and deletion requests.

This direction becomes especially important for genealogy and Indigenous/native-title data. CARE principles are not decoration here. If Donto stores claims about living persons, communities, restricted cultural knowledge, or contested identity, the substrate must make authority, access, publication, and deletion/request workflows explicit.

The hard tension: append-only truth systems and right-to-erasure/data-sovereignty requirements pull against each other. Donto's answer cannot be "never delete anything" in all cases. It needs a practical legal/governance distinction between:

• preserving internal audit history;
• hiding or tombstoning source blobs;
• suppressing export;
• removing public release material;
• cryptographically or operationally proving deletion where required.

6. Genes Consumer

Genes is the hardest and most valuable current consumer because it naturally stresses:

• contradictory records;
• uncertain identity;
• source-first evidence;
• lineage/relationship claims;
• temporal ambiguity;
• governance sensitivity;
• primary-source citation.

However, genes is not yet a clean consumer in the architectural sense. Local docs show it still uses sibling direct SDK/CLI paths into Postgres and has many guarantees enforced in scripts and dossiers rather than exclusively through Donto's HTTP/SDK contract.

That is fine historically, but not acceptable as the proof of a substrate. The rewrite PRD is right: genes should become an external consumer that exercises Donto's contract without privileged internal coupling.

7. Memory Consumer

Donto-memory is cleaner as a consumer and has a sharp philosophy:

• no silent rewrite;
• read events are not belief events;
• policy-aware by default.

This puts it in productive tension with Zep/Graphiti and Mem0-style agent memory systems. The differentiator should not be "we have graph memory." Others do too. The differentiator should be:

• every memory is a claim with provenance;
• contradictions are preserved;
• invalidation is not silent deletion;
• transaction time and valid time both matter;
• a recall bundle can explain policy, evidence, identity lens, and maturity.

The local LongMemEval audit correctly identifies a fatal gap if memory claims lack valid-time signals. Long-term memory benchmarks often hinge on time. Donto-memory must port the stronger extraction/valid-time discipline from current donto-extract work.

8. Jobs Flagship

The jsonresume -> jobs direction is the best product flagship because it turns Donto's abstract strengths into a measurable marketplace problem:

• resumes contain claims;
• job posts contain claims;
• skills taxonomies exist but are incomplete and shifting;
• evidence matters;
• claim maturity matters;
• temporal skill decay matters;
• identity and synonymy matter;
• matches need explanation;
• counter-evidence matters;
• new relationships can be discovered across many workers/jobs.

The obvious baselines are not weak: ESCO, O*NET, Lightcast, embedding search, and supervised job matching all exist. That is good. It gives Donto hard opponents.

The Donto advantage, if proven, is not "better keyword matching." It is evidence-anchored, temporally aware, contradiction-tolerant career inference:

• "This resume implies Kubernetes production experience because these projects, durations, employers, and artifacts support it."
• "This job says React, but the skill cluster and company history imply Next.js, accessibility, analytics, and design-system maintenance."
• "This candidate lacks direct title match but has adjacent claim paths that historically predict success."
• "This skill is stale unless refreshed by recent evidence."
• "This match is strong under a permissive identity/predicate lens but weak under a strict lens."

That is the right flagship because it can produce falsifiable held-out matching metrics.

9. Release, Federation, and Research Objects

The future release direction points toward Donto as a packageable, citable, federated evidence substrate:

• export claims;
• export sources/anchors where allowed;
• preserve policy;
• ship RO-Crate/DataCite-style research releases;
• possibly use DIDs/verifiable credentials for attestations;
• allow third parties to query or verify without granting raw DB access.

This is strategically important for science, law, genealogy, journalism, and institutional data. It should come after the core evidence/ranking path is stronger. A beautiful release format over weak anchors will not convince anyone.

10. Lean and Verification

Lean is currently optional, and that is the right maturity. Formal verification should not be on the hot path until the claim lifecycle is sharper.

The useful role for Lean is not "prove the world." It is:

• prove shape constraints;
• prove migration invariants;
• prove policy rules;
• prove that transformations preserve statement identity/evidence links;
• prove small domain-specific obligations where the cost is justified.

Lean should certify the substrate's rules. It should not become an excuse to delay the relationship generator/ranker.

11. Product Surfaces and Observability

The web/admin/debug/Dontopedia surfaces are useful because they reveal whether the substrate can be operated by a human.

The most important UI affordances are not landing pages. They are:

• claim cards;
• evidence badges;
• contradiction frontiers;
• identity clusters;
• predicate-alignment suggestions;
• source/revision/span navigation;
• policy/debug views;
• "why is this believed now?" explanations;
• "what changed since transaction time T?" diffs.

If Donto cannot explain itself on screen, it will be hard to trust even if the storage model is correct.

Gaps and Risks

This is the most important section.

1. Relationship Generation Is Still the Product Gap

Extraction abundance alone does not create discovery. It creates material. The local docs repeatedly identify relationship generation and ranking as the critical missing middle.

The current side-table counts support that: 2,433 argument edges and 124 identity edges are tiny relative to 39.5 million believed statements. That does not mean the schema is bad. It means the discovery layer is underfed.

If Donto does not build a strong relationship generator, the system remains a substrate plus extraction engine, not a discovery product.

2. Anchor Coverage Is Far Too Low

Live anchor coverage is 4.86 percent. The evidence-link count is large in absolute terms, but small relative to the statement volume.

This is the biggest credibility gap for "evidence operating system." The fix is not to delete unanchored claims. The fix is to:

• cap maturity for unanchored claims;
• aggressively repair anchors where possible;
• make run-level evidence visibly weaker than span-level evidence;
• route extraction toward compact claims with mandatory anchor state;
• make queries default to evidence-supported floors for serious use.

3. The HTTP Write Contract Has a Mismatch

In apps/dontosrv/src/ingest.rs, AssertReq.anchor is documented as applying to /assert and /assert/batch. The single POST /assert path uses req.anchor.is_some() only for maturity normalization, then calls s.client.assert(&input) and returns the statement id. It does not materialize a donto_span or donto_evidence_link.

The anchored POST /assert/batch path does create donto_span and donto_evidence_link rows.

That means a caller using single /assert with an anchor can appear evidence-backed to the maturity gate but not actually persist the evidence link through that path. This should be fixed or the contract should explicitly say only batch anchors materialize provenance.

Related issue: hypothesis_only is used by the HTTP maturity normalization, and schema support exists in packages/sql/migrations/0089_hypothesis_only_flag.sql, but the live donto_stmt_hypothesis_only table has 0 rows and I did not see the HTTP assert path marking the overlay. Audit this before claiming the invariant is uniformly persisted.

4. DontoQL Is Good, but Evidence Shape Is Incomplete

DontoQL v2 is a serious surface. It supports scope, polarity, maturity, identity lenses, predicate expansion, modality, extraction level, transaction-time pins, policy filters, schema lenses, ordering by contradiction pressure, projection, limit, and offset.

But WITH evidence is currently parsed/recorded and does not yet attach evidence rows to the result shape. For a system whose core claim is evidence-first, this should be elevated. Consumers should not need a second manual fetch for ordinary evidence-aware result views.

5. Policy Query Scaling Needs Attention

The benchmark notes show normal inserts and point queries are plausible through the tested sizes, but policy filtering is a scaling concern. Policy-aware recall is central for memory, genes, and any future third-party/federated surface.

If policy is slow, consumers will bypass it. If consumers bypass policy, Donto's governance story fails.

6. Predicate Sprawl Is Both Feature and Liability

Free predicates are the point. But 880,703 distinct predicates in the live substrate means query-time alignment is not optional.

The danger is subtle. If Donto prematurely normalizes predicates, it destroys the abundance thesis. If it leaves predicate sprawl unaligned, it becomes hard to query. The only viable path is continuous alignment with confidence, evidence, reversibility, and lens-specific expansion.

7. Consumers Are Still Too Entangled

The rewrite PRDs are right to split repos and boundaries. Current surrounding services use Donto as an example and sometimes as a substrate, but the ecosystem still has historical coupling:

• extraction code appears in or near substrate paths;
• genes uses direct DB/SDK/script workflows rather than only clean consumer contract paths;
• memory is cleaner but still needs parity with the stronger extraction/valid-time work;
• public API/worker services are part product, part example, part extraction infrastructure.

This is normal during incubation. It becomes a problem if allowed to persist after the contract is declared stable.

8. Error Semantics Are Too Easy to Misuse

The consumer contract warns that many handlers return 200 + {"error": ...}. This is dangerous for third-party consumers and generated clients. It is acceptable for an internal prototype if documented. It is not good as a stable public API.

At minimum, generated SDKs must treat the presence of an error key as failure everywhere. Better: return proper HTTP status codes in a contract-major bump.

9. Full-Corpus Characterization Is Operationally Expensive

The local paper notes mention long-running characterization queries. I also avoided whole-table counts during this audit because exact scans can be costly at current scale. Donto needs materialized, incremental, or approximate health surfaces for:

• distinct subjects;
• predicate singleton rate;
• evidence coverage by namespace/context;
• maturity distribution;
• anchor repair queue;
• contradiction frontier by domain;
• policy coverage;
• relationship-generator coverage.

The health dashboard should be a steering wheel, not an expensive ad hoc query suite.

10. Retraction Rate Is Too Low to Prove the Lifecycle

Only 282 retracted statements are reported. That may simply reflect early usage. But Donto's story depends on no-silent-overwrite correction, supersession, and time-aware re-ranking. The corpus needs active correction workflows to prove this.

11. The Novelty Claim Can Be Oversold

The local research reports sometimes lean hard into "no prior system had this." The more defensible claim is narrower:

• prior systems have most primitives;
• prior LLM-KG systems show abundance;
• prior temporal graph memory systems show time-aware agent memory;
• Donto's novelty is the specific contract and composition around preserving abundant generated claims until query/rank/evidence time.

That narrower claim is strong enough. Overselling the primitives weakens the argument.

What Would Prove Donto

Donto should be judged by deltas against baselines, not by how many statements it stores.

Proof 1: Collapse Delta

Take an abundance-extracted corpus. Compare:

• raw exact-string matching;
• conventional schema-first extraction;
• vector search only;
• GraphRAG-style extraction/retrieval;
• Donto with query-time predicate alignment, identity lenses, evidence floor, and contradiction-aware ranking.

Metric: does Donto answer more real questions with fewer false merges and better explanations?

Proof 2: Relationship Generator Precision

Build the missing generator over claims/entities/events. Measure:

• precision@k for generated supports/rebuts/supersedes/identity hypotheses;
• recall against held-out manually found relationships;
• evidence coverage per generated relationship;
• human adjudication time saved;
• downstream ranking improvement.

If this does not work, Donto remains a storage substrate.

Proof 3: Time-Slicing and Re-Ranking

Use transaction-time and valid-time slices:

• what did the system believe on date A?
• what changed by date B?
• which claims dropped/rise in rank after new evidence?
• which matches would have been made under old knowledge but not now?

This is where Donto can beat static KGs and ordinary vector RAG.

Proof 4: Jobs Held-Out Benchmark

For jsonresume -> jobs, build a held-out benchmark:

• historical resumes;
• historical job postings;
• known applications, interviews, hires, performance, or recruiter decisions where available;
• ESCO/O*NET/Lightcast/embedding baselines;
• Donto claim extraction plus evidence-aware ranking.

Metrics:

• match precision/recall;
• calibration;
• explanation quality;
• robustness to title synonyms;
• freshness/skill-decay handling;
• fairness and policy constraints.

This is the flagship because it has real baselines and real user value.

Proof 5: Evidence Completeness Gate

Define maturity thresholds that cannot be reached without evidence:

• E0/E1: raw/candidate;
• E2: evidence-supported;
• E3: reviewed;
• E4/E5: corroborated/certified.

Then measure how many useful workflows can run at E2+ while raw abundance remains available for discovery.

Proof 6: Consumer Boundary Test

Run genes, memory, and jobs as external consumers using the versioned contract. Forbid direct DB shortcuts except controlled admin/migration tasks.

If they can still do their jobs, Donto is a substrate. If they cannot, the contract is incomplete.

My Engineering Opinion

The right next build order is not more demos. It is:

1. Fix the write contract.
2. Finish unified extraction as a separate engine.
3. Raise anchor coverage and make anchor quality visible.
4. Make WITH evidence return useful evidence bundles.
5. Build the relationship generator and ranker.
6. Prove query-time alignment on a held-out set.
7. Convert genes and memory into stricter external consumers.
8. Build the jsonresume -> jobs flagship against serious baselines.

The write contract comes first because it is the foundation for everything else. A claim that says it is anchored must actually have a persisted anchor. A hypothesis-only claim should actually mark the hypothesis overlay. Maturity should mean the same thing through every ingestion route.

Unified extraction comes second because the rest of the system depends on claim supply. But extraction should not chase raw count by itself. It should output evidence-stateful claims and stop when coverage/saturation metrics say the source is exhausted.

The relationship generator comes before more broad strategy. This is the missing engine that converts a corpus into discovery. Without it, Donto's best idea remains mostly latent.

Jobs should be the flagship because it is commercially legible and empirically falsifiable. Genealogy proves Donto's ethics and contradiction model. Memory proves temporal recall. Jobs proves the economic case.

Strongest Novelty Claim

Here is the novelty claim I would defend publicly:

Donto is a domain-neutral claim substrate for the era of generative abundance. It accepts freely minted, evidence-stateful claims into an append-only bitemporal store; preserves contradiction, identity uncertainty, and predicate plurality as legal state; and defers alignment, identity, policy, ranking, and explanation to query/review time. Its product is the claim lifecycle from abundant extraction to evidence-backed, re-rankable discovery, not merely the storage of triples.

That is defensible.

Here is the claim I would avoid:

Donto invented knowledge graphs, provenance, bitemporality, temporal memory, paraconsistency, or LLM-generated triples.

It did not. Its value is the synthesis.

Short Name for the Idea

If I had to name the technical idea in one phrase:

abundance-preserving claim computation

That phrase captures the thing Donto is trying to do:

• preserve more candidate knowledge than schema-first systems allow;
• compute over it later with lenses, evidence, time, policy, and rank;
• avoid pretending the first clean graph is the truth.

Source Map

Local sources inspected:

• /home/ajax/DONTO-ABUNDANCE.md
• /home/ajax/DONTO-CLAIM-SUBSTRATE.md
• /home/ajax/paper-notes/donto-paper.md
• /home/ajax/donto/docs/ARCHITECTURE.md
• /home/ajax/donto/docs/CONSUMER-CONTRACT.md
• /home/ajax/donto/docs/DONTOQL.md
• /home/ajax/donto/docs/BENCH-RESULTS.md
• /home/ajax/donto/docs/RESOURCE-STORAGE.md
• /home/ajax/donto-rewrite/PRD-00-master.md
• /home/ajax/donto-rewrite/prd-01-the-substrate-donto-core.md
• /home/ajax/donto-rewrite/prd-02-donto-extract-unified-engine.md
• /home/ajax/donto-rewrite/prd-06-example-consumers-genealogy-memory.md
• /home/ajax/donto-rewrite/prd-07-resource-storage-retrieval-search.md
• /home/ajax/donto-memory/README.md
• /home/ajax/genes/docs/ARCHITECTURE.md
• /home/ajax/genes/docs/CONSUMER-CONTRACT.md
• /home/ajax/SERVER-OVERVIEW.md
• /home/ajax/donto/apps/dontosrv/src/ingest.rs
• /home/ajax/donto/packages/sql/migrations/0089_hypothesis_only_flag.sql

Local live endpoints checked:

• GET http://127.0.0.1:7879/health
• GET http://127.0.0.1:7879/discovery/contract-version
• GET http://127.0.0.1:7879/discovery/substrate-health
• GET http://127.0.0.1:7900/health
• GET http://127.0.0.1:8000/health
• GET http://127.0.0.1:4001/health

External primary or near-primary references used for prior-art positioning:

• W3C RDF 1.1 Concepts: https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/
• W3C RDF 1.1 Dataset Semantics: https://www.w3.org/TR/rdf11-datasets/
• W3C PROV-O: https://www.w3.org/TR/prov-o/
• RO-Crate specification: https://www.researchobject.org/ro-crate/specification/
• CARE Principles, Global Indigenous Data Alliance: https://www.gida-global.org/careprinciples
• CARE Principles paper, Data Science Journal: https://datascience.codata.org/articles/10.5334/dsj-2020-043
• XTDB documentation: https://docs.xtdb.com/intro/what-is-xtdb.html
• Datomic documentation: https://docs.datomic.com/
• Stanford Encyclopedia of Philosophy, Paraconsistent Logic: https://plato.stanford.edu/entries/logic-paraconsistent/
• Dung argumentation paper page: https://www.sciencedirect.com/science/article/pii/000437029400041X
• Zep Graphiti: https://www.getzep.com/platform/graphiti/
• Zep Graphiti docs: https://help.getzep.com/graphiti/getting-started/welcome
• Mem0 graph memory docs: https://docs.mem0.ai/open-source/graph_memory/overview
• GPTKB paper: https://arxiv.org/abs/2411.04920
• GPTKB v1.5 paper: https://arxiv.org/abs/2507.05740
• AutoSchemaKG paper: https://arxiv.org/abs/2505.23628
• Microsoft GraphRAG project: https://www.microsoft.com/en-us/research/project/graphrag/
• ESCO official page: https://employment-social-affairs.ec.europa.eu/policies-and-activities/skills-and-qualifications/skills-jobs/european-skillscompetences-qualifications-and-occupations-esco_en
• O*NET, U.S. Department of Labor: https://www.dol.gov/agencies/eta/onet
• Lightcast Open Skills: https://lightcast.io/open-skills
• TalentCLEF overview paper: https://arxiv.org/abs/2507.13275