reconcile

reconcile is the verb that makes ClariLayer a trust product instead of a notepad. A hand-written definition — yours or one imported by bootstrap — has the same trust problem as the original numbers: it is just asserted text. reconcile is different. It checks a saved definition against your real warehouse result, so you and your agent know whether the definition still holds.

This is the acute moment most analysts feel first: "why don't these two numbers match?" reconcile is how ClariLayer answers it honestly.

How it works

You identify one saved entry (by id, or by name plus an optional type) and supply an actual_sample — the result shape your agent obtained by running the entry's stored SQL with its own warehouse access. ClariLayer then:

1. extracts the declared signals from the entry's stored SQL (the columns, groupings, and shape the query says it should produce);
2. compares them against the actual result your agent reported;
3. records the outcome on the entry.

Crucially, ClariLayer never holds your warehouse credentials and never executes SQL server-side; your agent sends result metadata and may include optional preview rows it chooses to include — omit or redact preview rows that contain sensitive values. Your agent is the connector: it runs the SQL itself and sends back only the result shape — the columns, an optional small preview of rows, and an optional row count.

The two outcomes

reconcile has exactly two outcomes today:

• caveat — the entry's declared signals and the actual result mismatch. The entry is flagged so you and your agent know to treat it with care. This is the valuable signal: ClariLayer caught a definition that no longer matches the data.
• asserted — nothing contradicted the entry. Either you omitted the actual_sample (nothing was checked), the SQL yielded no applicable checks (nothing checkable), or every applicable check passed. In all of these the entry stays asserted.

Those are the only two results. reconcile records a caveat or leaves the definition asserted; it does not upgrade an entry to a stronger status.

reconcile does not stamp "verified" yet

This is the most important honesty point in ClariLayer, so it is worth stating plainly: a clean reconcile pass does not mark an entry verified today. A would-be-verified match is deliberately recorded as asserted in v1.

Why? The strong verified mark is gated off because the part of ClariLayer that would back it — extracting the declared signals from arbitrary SQL — currently uses a heuristic, and a heuristic cannot be made sound against the long tail of SQL dialect edge cases. A single false verified is the one failure a trust product cannot ship. So ClariLayer caps the result at caveat or asserted until a real SQL-parser replaces the heuristic. verified is the documented fast-follow, not today's behavior.

The practical takeaway: over-flagging is safe (a caveat just tells you to look), but a false all-clear is not — so ClariLayer biases hard toward not over-claiming. Read Verified vs Asserted for the full status model.

How to run it

Reconcile is something your agent does on your behalf, because it is the one holding the warehouse access. A natural prompt:

Reconcile our Active Customer definition: run its stored SQL and check the result against what ClariLayer has.

Your agent runs the SQL, captures the result shape, and calls reconcile with that actual_sample. If the shape disagrees with what the definition declared, the entry comes back flagged as a caveat; otherwise it stays asserted.

When to reconcile

• When two reports disagree and you want to know which definition drifted.
• After a schema change, to catch definitions whose SQL no longer produces what it claims.
• Before you rely on a definition for something that matters, to surface a caveat early rather than in a board deck.

See also

• remember — capture the definition that reconcile then checks.
• recall — recalled entries carry their asserted or caveat status.
• Verified vs Asserted — the full trust-status model and the verified roadmap.