Module knowledge 

Agent-facing type & multi-model knowledge reference — generated from the engine’s own type-system authorities (ADR 0061, “Agent-Facing Knowledge & MCP Surface”).

Where crate::knowledge’s sibling in reddb-io-rql emits the RQL grammar surface, this module emits the value-type catalog and the multi-model map. The volatile facts come straight from the source of truth so the reference cannot drift from the engine:

• the value types come from the three type-system authorities in this crate — [function_catalog::FUNCTION_CATALOG], [operator_catalog::OPERATOR_CATALOG], and [cast_catalog::CAST_CATALOG] (every concrete type they reference), and
• the operators and casts are likewise read live from those tables.

Layered over that per-model type catalog is the multi-model map: the paradigms RedDB stores (documents, key-value, queues, graph nodes/edges, vault secrets, config, and RQL-tabular collections). The map is the conceptual narrative — hand-authored because it is judgment, not extractable — but it points into the generated type catalog by TypeCategory, so the two layers stay coupled.

Nothing here hand-maintains which value types exist — that is read from the catalogs above. The same generated content is served two ways from this one source: as the reddb://knowledge/types MCP resource and as the type section of the generated docs/llms.txt. The anti-drift tests at the bottom pin the “generated, exhaustive, in-sync” contract.

Structs

ModelParadigm

One paradigm in RedDB’s multi-model surface. The narrative (summary) is hand-authored judgment; categories points into the generated value-type catalog so the map is layered over — not duplicated from — the type system.

Constants

LLMS_BEGIN_MARKER

Markers delimiting the generated type block inside docs/llms.txt. The docs/llms.txt sync test reads the text between these markers and asserts it equals type_reference_markdown, so the file is generated, not hand-maintained.

LLMS_END_MARKER

Closing marker for the generated type block in docs/llms.txt.

MULTI_MODEL_MAP

The multi-model map: the paradigms RedDB stores, layered over the value-type catalog. Hand-authored narrative (ADR 0061 §3), but each entry references the generated TypeCategory families it predominantly holds.

RESOURCE_DESCRIPTION

One-line description of the type knowledge resource.

RESOURCE_TITLE

Short human title for the type knowledge resource.

RESOURCE_URI

Canonical URI for the type & multi-model knowledge resource served over MCP.

Functions

casts_from

Every cast out of ty registered in CAST_CATALOG, in catalog order. Each tuple is (target, context, lossy) read straight from the catalog row.

catalogued_value_types

Every concrete value type referenced by the type-system authorities (function / operator / cast catalogs), sorted by discriminant and deduplicated.

implicit_casts

The implicit (always-allowed, lossless) casts the engine inserts silently, sorted by (src, target) discriminant. These are the widenings an agent can rely on without writing CAST(...).

infer_literal_type

Infer the DataType of a bare JSON literal as the engine would type it on the wire: null → NULLABLE, booleans → BOOLEAN, integral numbers → INTEGER, fractional numbers → FLOAT, strings → TEXT, arrays → ARRAY, objects → JSON.

operator_symbols

Distinct operator symbols, sorted, taken from the engine’s static OPERATOR_CATALOG. The catalog carries one row per overload, so a symbol (e.g. -, which is both infix and prefix) can appear several times — this collapses them.

operators_for

Every operator overload in OPERATOR_CATALOG that accepts ty as one of its operands, in catalog order. The Nullable left-operand marker on prefix operators is treated as “no left operand”, so a prefix - matches only when ty is its (right) operand, never via the marker.

resolve_type_name

Resolve a type name (canonical reddb spelling or a common SQL alias, both case-insensitive — e.g. INTEGER, int, string) to its DataType.

type_facts_json

Build the structured reddb_type_of answer for a resolved DataType: its canonical name + category, the casts available out of it, and the operator overloads that accept it — all read live from the catalogs.

type_llms_section

The type block as embedded in docs/llms.txt: the generated reference fenced by the begin/end markers. Emitting the markers here keeps docs/llms.txt and the MCP resource fed by one source.

type_of_json

Answer a reddb_type_of query. Exactly one of type_name or value should carry the lookup subject: a type name (resolved with resolve_type_name) or a JSON literal whose structural type is inferred with infer_literal_type. Returns the structured facts from type_facts_json wrapped with the resolved canonical type, or None when a supplied type name is unknown to the engine.

type_reference_markdown

Generate the canonical type & multi-model reference as Markdown, sourced entirely from the engine’s type-system authorities (for the type catalog) plus the hand-authored multi-model narrative. This single string is what the MCP reddb://knowledge/types resource serves and what docs/llms.txt embeds.