Skip to content

Discrepancies & provenance

ContextCake returns one primary answer per concept and is honest about dissent. Where layers disagree on a section, the higher layer’s value is primary and the dissenting layers ride along as conflicts — each tagged with its layer and its last-updated date. The structural discrepancy is surfaced, not hidden. ContextCake does not infer semantic contradictions between unrelated entities or prose.

A read_file response resolves the whole concept and attaches provenance at three levels:

  • contributors — every layer that defines this concept, each as { layer, level, updated }.
  • frontmatterProvenance — for each frontmatter field, which layer the final value came from.
  • sections[] — each section carries { key, heading, content, sourceLayer, sourceUpdated }, plus an optional conflicts[], optional additive discrepancy disposition metadata, and an optional suppressed: true.

sourceLayer tells an agent which layer won a section; frontmatterProvenance does the same per field. Together they let an agent weight facts by trust level — knowing a section came from the Company layer versus a Personal draft.

When another contributor defines a section with content that differs from the winner, that dissent is attached as:

"conflicts": [
{ "layer": "company", "updated": "2026-05-01", "content": "..." }
]

Sections where layers agree, or that only one layer defines, resolve silently — no conflicts array. That is the common, non-contentious case. Suppressed (tombstoned) sections emit no conflicts either: the suppression is the answer.

The updated date on each conflict is the staleness signal. If a lower layer’s dissenting version is newer than the winning section, you simply see it and judge — there is no separate drift-detection subsystem to consult.

In the bundled demo, the Personal layer wins the Choice section, but the Company layer disagrees. The resolved section looks like this:

{
"key": "choice",
"heading": "## Choice {#choice}",
"content": "Postgres in every shared environment. Locally I run SQLite for the test suite so I\ncan reset state per-run without a container. Never commit SQLite-only assumptions.",
"sourceLayer": "personal",
"sourceUpdated": "2026-06-28",
"conflicts": [
{
"layer": "company",
"updated": "2026-05-01",
"content": "Postgres (org standard). All services provision managed RDS through the platform\ncatalog. No other primary datastore is approved for production."
}
]
}

The primary answer is Personal’s nuanced take — Postgres in shared environments, SQLite locally for the test suite. But the Company layer’s stricter line — Postgres via managed RDS only, no other primary datastore approved for production — is not discarded. It rides along with its date (2026-05-01), so an agent reading this knows the personal note diverges from org standard and can weight accordingly.

The concept’s contributors and frontmatterProvenance for this resolution:

"contributors": [
{ "layer": "personal", "level": 3, "updated": "2026-06-28" },
{ "layer": "team", "level": 2, "updated": "2026-06-20" },
{ "layer": "company", "level": 0, "updated": "2026-05-01" }
],
"frontmatterProvenance": {
"type": "personal", "title": "personal", "updated": "personal",
"owner": "personal", "tags": "personal"
}

This is the core philosophy. ContextCake never silently picks a winner and drops the rest. It gives a clean primary answer up top and puts the dissent, its source, and its date underneath. Nothing is hidden; you always see what the other layers said and when they last said it.

The Discrepancy Center adds governed decisions without changing that resolver contract. It detects section content, authored frontmatter values, settled broken links, and changes after a decision. An acknowledged scoped difference remains in the resolved/MCP output with optional disposition metadata; existing consumers may ignore that additive field.