Foundry SQL (FSQL)

• Foundry SQL (FSQL) is a compact, typed query language that operates over maintained foundry artifacts in the ODYSSEY framework.
• It generalizes traditional SQL concepts by applying slicing, gluing checks, and TICKET certification to ensure artifact integrity.
• FSQL supports querying, evaluation, and governance by enforcing finite truth semantics and rigorous promotion, provenance, and obstruction criteria.

Foundry SQL (FSQL) is a compact, typed query language in the ODYSSEY framework for accessing, managing, and integrating maintained foundry artifacts, including models, claims, workflows, evidence, and argument tickets. Within ODYSSEY, which constructs verifiable, local truth-preserving foundation models as compositions of foundries, FSQL serves as the query surface over foundry sections, source sheaves, restriction maps, gluing checks, and promotion gates, and it uses TICKET certification to admit external or pre-built models into durable ODYSSEY state (Mahadevan, 25 Jun 2026).

1. ODYSSEY context and the object of query

ODYSSEY defines a foundry as a building-block architectural component that specifies a cover of local contexts, local representation families, restriction maps, gluing rules, obstruction policies, update obligations, and human-facing views. A foundry is also described as an organized sheaf of knowledge that carries within it an argumentation component. Concrete foundries are built from generic foundries such as evidence/argument, operational decision, institutional/financial, market meaning, scientific challenge, research-program, assistant-build, and evaluation-harness foundries (Mahadevan, 25 Jun 2026).

FSQL is designed around those foundry objects rather than around conventional relational tuples alone. Its declared purposes are to query maintained artifacts, slice artifacts and select regions of interest, verify compatibility, admit and certify external or pre-built models using TICKET certification, expose artifact status and governance, and support gluing, restriction, admission gates, provenance tracing, and failure or obstruction handling. In that sense, the language is not an auxiliary utility layered over ODYSSEY; it is part of the machinery by which foundry state is inspected, tested, and promoted.

This organization matters because the queried objects are intrinsically local and typed. A foundry artifact is not merely a record of output, but a maintained object situated in a context with explicit restrictions, gluing rules, and argumentation structure. FSQL therefore operates over a knowledge organization that is already categorical and sheaf-based, rather than translating those structures into an external metadata layer.

2. Query surface, syntax, and the SQL generalization

ODYSSEY characterizes FSQL as follows: “Standard SQL queries build typed constructions over tables; FSQL generalizes the same idea from rows and joins to foundry sections, source sheaves, restriction maps, gluing checks, and promotion gates.” The language is therefore intentionally small, but its scope includes both retrieval and certification-oriented operations (Mahadevan, 25 Jun 2026).

The SQL analogy is explicit. Tables correspond to local charts or artifact stores, rows correspond to observations, model states, claim tickets, or workflow steps, foreign keys correspond to shared identifiers, provenance links, and cross-context references, joins correspond to gluing checks, views correspond to user dashboards such as Scylla-facing dashboards, and constraints correspond to automatic audits as defined by Athena and Prometheus. The analogy is descriptive rather than literal: it preserves the intuition of selection and combination while relocating semantics to local sections and compatibility conditions.

A typical query is given as:

$T$5

In this form, FROM prometheus_runs selects artifacts output by the Prometheus engine, [SLICE](https://www.emergentmind.com/topics/strong-lensing-and-cluster-evolution-slice) BY run("tcc_44k") restricts the query to a named run, and TICKET BY target_foundry applies the TICKET admission filter to attempt admission into the specified foundry. The reported result includes certification status, admission record, diagnostics, and refresh obligations.

A more general pattern is:

$T$6

The paper also gives an FSQL-TICKET surface example:

$T$7

This returns transformer identity, target foundry, admission checks, promotion record, and refresh obligations. The canonical syntax therefore combines source selection, contextual slicing, and admission or audit in a single surface form.

3. Type system, schemas, and finite truth semantics

FSQL is typed at the level of artifacts, runs, claims, and sections. Every artifact, run, or claim is a structured record with types for fields such as provenance, domain, artifact type, and gluing status. Sections are collections of local models, arguments, or evidence, typed according to their foundry context. Artifacts also have schemas, including subobject classifiers, manifests, gluing audits, restriction maps, provenance, and promotion gates (Mahadevan, 25 Jun 2026).

Logical and epistemic predicates are assigned finite truth values rather than unrestricted confidence scores. The text specifies the partition $L$, WEAK, PLAUSIBLE, SUPPORTED, and $T$, and states that these truth values are used in restrictions, gluing, and promotion rules. This produces an interpretable semantics for certification-oriented querying: the result of a query is not only whether an artifact was found, but also how that artifact stands with respect to finite-valued compatibility and admissibility conditions.

Promotion status is likewise typed and queryable. The statuses explicitly named are admitted, quarantined, candidate, and blocked. Queries can filter by domain, run, family, status, artifact type, and provenance, and they can expose governance around integration rather than only the presence of an object. In practice, this means that a query surface over foundry artifacts also becomes a surface over procedural state: maintained, candidate, and failed objects are all part of the same auditable substrate.

A common misunderstanding is to view these statuses as merely workflow labels. In ODYSSEY, they function as outputs of typed admission and compatibility checks. The distinction is significant because the promotion vocabulary is bound to restrictions, gluing audits, provenance, and argument tickets, not to an external ticketing system detached from model semantics.

4. TICKET certification and categorical semantics

TICKET, expanded as Topos Integration using Causal Kan Extension Transformers, is the operator by which external, pre-built, or candidate models are admitted into a target foundry subject to explicit categorical and logical consistency constraints. In the presentation associated with FSQL, the source artifact is specified as a presheaf $X$, the target foundry as a presheaf $M_Y$, and a functor $F_{x,Y}$ encodes the mapping between source and target context categories. TICKET then performs a left Kan extension to roll out the source artifact as a target-side candidate, followed by a right Kan extension or pullback to apply consistency and audit checks relative to the target foundry and its maintained state (Mahadevan, 25 Jun 2026).

The text gives the admission or rollout step as

$A = \operatorname{Lan}_{F_{x,Y}} X$

and the Universal Foundry Learner as

$$UFL_{x,Y}(X) = \operatorname{Ran}_{F_{x,Y}} F_{x,Y} A.$$

For a cover $\{U_i \to U\}$ in the target, local candidate sections $a_i \in A(U_i)$ and maintained sections $m_i \in M_Y(U_i)$ glue over $T$0 when, for each declared overlap $T$1, the compatibility predicate satisfies

$T$2

Appendix B presents a monadic view in which

$T$3

so that the candidate proceeds as

$T$4

Promotion is allowed iff the monadic consistency envelope is compatible with all foundry constraints and maintained state. FSQL is the operational surface on which these constructions are invoked. The query language is therefore categorical in semantics even when its surface syntax resembles a restrained SQL dialect.

5. Foundry management loop, verification, and obstruction handling

FSQL is integrated into the ODYSSEY foundry management loop. The life cycle described in the paper proceeds through seven stages: the user expresses a model or foundry request; SCYLLA converts the request to a model brief; HOMER constructs the workflow and required audits; ATHENA assigns representation, including covers, types, truth semantics, restrictions, and gluing logic; PROMETHEUS instantiates local world models and emits artifacts; TOULMIN builds argument tickets including claims, grounds, warrants, qualifiers, and rebuttals; and TICKET uses FSQL, often through a GUI or CLI, to admit or quarantine artifacts (Mahadevan, 25 Jun 2026).

Within this loop, FSQL is not restricted to terminal inspection. It can interact with any artifact at any stage, although its canonical use is in TICKET runs and admissions. The paper emphasizes that FSQL does not simply retrieve data. Queries apply admission logic: they ask whether an object satisfies the restrictions, gluing, and promotion rules of the target foundry; where arguments break; and whether explicit obstructions exist.

The output of a query therefore includes negative structure as well as positive certification. Queries report failure slices and durable obstruction objects for debugging or review, enabling epistemic and logical scrutiny. Any artifact can be admitted if it glues and passes all checks, quarantined if useful but not fully compatible, or blocked if it fails core compatibility. Status, provenance, restriction, and failure details remain queryable and auditable.

This treatment of failure is structurally important. A failure to glue is not discarded as an implementation exception; it is preserved as an inspectable result inside the foundry management apparatus. A plausible implication is that FSQL functions simultaneously as a query language and as a governance interface for durable model state.

6. Domain instantiations and practical use

The paper presents several application scenarios for FSQL. In scientific foundries such as TCC 44K and Indus Script, a query of the form SELECT ... SLICE BY run("tcc_44k") TICKET BY causal_claims_foundry; is used to lift causal claims from an external cSQL-based atlas into a sheaf-foundry, preserving evidence structure and highlighting claims that cannot safely be transported because of polarity, method, or controversy tension. FSQL surfaces which claims glue and which are blocked or quarantined (Mahadevan, 25 Jun 2026).

In procedural PSR foundries such as MyFixIt, FSQL is used to query repair-step artifacts, their action-observation state, grounding, and failure slices. TICKET certification then admits only those repair steps or action sequences for which evidence glues, while blocked claims such as unverified image grounding are exposed as obstructions for further review. In grounded Toulmin or local-LLM argument inspection, FSQL admits or tests LLM-generated argument tickets against Prometheus-extracted substrate, with admission governed by whether the Toulmin roles—claim, grounds, warrant, qualifier, and rebuttal—glue with the sheaf predicate landscape.

The language also supports bidirectional model transport. On import, FSQL plus TICKET admits pre-existing models from external Prometheus runs, together with diagnostic feedback and status. On export, ODYSSEY foundries can be exported back into Prometheus’s GUI-compatible workbench for visual inspection, testing, and further sheaf analysis. In experimental replication and benchmarking, including Amazon Reviews and BLaIR-Bench tasks, FSQL orchestrates admission and slicing of benchmarking artifacts so that only compatible claim or task lanes are admitted and result transfer across split or encoder boundaries is not over-licensed.

These examples frame a recurring interpretive point. FSQL is not only a retrieval notation over heterogeneous artifacts; it is the mechanism by which heterogeneous artifacts become first-class, reviewable components of foundry state. The paper’s summary explicitly places querying, verification, artifact promotion, provenance handling, evidence management, grounded argumentation, and epistemic audit on top of FSQL queries and TICKET-based certification. This suggests that FSQL is best understood as the maintained interface between local truth preservation and model reuse across heterogeneous sources.