/**
 * What the knowledge index can store — the read-path rule for YAML documents.
 *
 * `loadAll` admits any document with a string `id` and `type`, and the index is the
 * first thing that cares about the rest. A `description:` holding a map used to throw
 * "Provided value cannot be bound to SQLite parameter 4." out of the rebuild, and so
 * out of `aidlc update`, `aidlc init` and `aidlc gate`, naming neither the file nor the
 * field. The rule here lets the read path leave that one document out, and say which
 * one, instead (knowledge-block-vanishes-silently/AC-7, AC-8, AC-14).
 *
 * The rule is what `SqliteIndex.upsertEntity` / `upsertRelationship` / `syncFts`
 * actually refuse — measured by driving the real index with every field and shape —
 * and deliberately not `KnowledgeWriter.validateEntity`, which is stricter (id slug,
 * confidence range, strings only). Applying the write-path rule on read would refuse
 * documents that index today, a numeric `name` or a `confidence: high`; this one can
 * only turn a crash into a named skip (AC-13, design DD3). A field added to
 * `upsertEntity` needs a line here.
 *
 * No import of the index: `yaml-source.ts` uses this, and must not pull `node:sqlite`
 * onto the paths that only read YAML (stale-graph-entries/AC-17).
 *
 * @module
 */
/**
 * Why an entity document cannot be stored, or null when it can.
 *
 * @param doc - A parsed document with a string `id` and `type`.
 * @returns e.g. `'description' is a map`.
 */
export declare function unstorableEntityReason(doc: Record<string, unknown>): string | null;
/**
 * Why a relationship document cannot be stored, or null when it can. `from`, `to`
 * and `type` are already strings — `loadAll` classifies a document by them.
 *
 * @param doc - A parsed document with string `from`, `to` and `type`.
 */
export declare function unstorableRelationshipReason(doc: Record<string, unknown>): string | null;
//# sourceMappingURL=storable.d.ts.map