The web is not one database. It only looks like one from a search box.
Behind every dynamic source is a different way to ask for records. One system calls a concert category Music. Another divides the same intent across several taxonomies. One can filter by price before returning results. Another exposes price only after the records arrive. A third does not provide price at all.
These differences are not cosmetic. They determine whether an answer actually satisfies the request.
A frontier model can understand a question, search broadly, browse interfaces, and explain what it finds. GEFT is not an attempt to replace those abilities. Its work begins where interpretation must become repeatable execution.
The correct unit is a capability set
Consider a request for upcoming professional sports events in Chicago. More than one ticketing source may be capable of answering. A city-permit dataset or volunteer-events API is not.
Selecting only one fitting source leaves potential coverage behind. Sending the request to every available source ignores what those systems are for.
The correct unit is a capability set.
GEFT represents the request as canonical facets: event category, geography, time range, price, availability, audience, and other constraints relevant to the vertical. The router compares that contract with the declared capabilities of every authorized source. Every fitting source can proceed. Sources that do not legitimately serve the request are skipped.
The shared request is then translated separately for each selected source. A canonical category becomes the vocabulary that source actually accepts. A common time range becomes its required date format. Pagination, known limits, unsupported facets, and source-specific behavior come from a versioned grammar manifest.
The result is not one abstract query. It is a set of source-native executions generated from one inspectable contract.
Many executions, one result interface
Selected sources execute in parallel. Their native records arrive with different names, structures, identifiers, field coverage, and freshness characteristics.
GEFT maps those records into a vertical canonical schema. The current runtime then applies deterministic identity rules before it returns one result set. Every surviving record carries record-level provenance: its source, access basis, fetch time, and last-verification time.
This boundary matters because the same real-world entity can appear in more than one system. An agent should not have to treat repeated listings as separate merely because two platforms assigned different record IDs.
The current alpha does not claim that problem is solved. Independent identifiers, slight title differences, schedule changes, and conflicting venue data require stronger cross-source entity resolution and conflict policies. Preserving the evidence contributed by every matching source is also an active hardening area.
We are stating that boundary publicly because infrastructure should describe what it does not yet guarantee.
One canonical result interface does not mean one source. It means the source differences have a deliberate place to go.
Why events come first
Events are a demanding environment for this contract.
They are distributed across ticketing systems, civic datasets, cultural listings, community platforms, calendars, and organizer infrastructure. They change quickly. Time zones matter. Ticket state changes. Age and access policies may appear only in descriptive text. The same event may be syndicated several times. A result can look relevant and still fail a hard constraint.
That makes events useful as a proving ground.
The current GEFT alpha includes six real-source adapters spanning ticketing, civic and volunteer events, city permits, and cultural listings. In the dated July 14 internal benchmark, seven defined routing scenarios passed. All six non-empty scenarios recorded 1.00 constraint satisfaction under the benchmark’s checks, and the repository had 93 green tests.
Those numbers describe a narrow technical-alpha snapshot from July 2026. They are not a production SLA, an independent comparison, or a claim of complete event coverage.
The point of measuring a narrow source set is to make failure legible before attempting scale.
The architecture is broader than the first dataset
Events are the first vertical implementation, not the boundary of the underlying idea.
GEFT separates source grammar from vertical meaning. Each source can change its parameters and behavior while the vertical contract remains stable for the calling agent. A future vertical would require its own canonical semantics, authorized source set, certification process, and benchmark. It should not inherit a vague universal schema or an unearned claim of completeness.
The larger possibility is straightforward to state and difficult to earn: give agents a stable way to query fragmented live systems without erasing the differences that make those systems trustworthy.
We are beginning with one vertical, one execution contract, and evidence narrow enough to inspect.
What is true now
- A canonical event query can route to several capability-matched sources.
- Selected sources execute in parallel through their own grammar manifests.
- Native records are normalized into one canonical event shape.
- The runtime applies deterministic identity rules and returns one result set.
- Every returned record carries record-level provenance.
- Six real sources have been exercised in a defined event benchmark.
What remains open
- Strong cross-source identity for records with independent IDs.
- Conflict handling when sources disagree about the same entity.
- Preserving multi-source and field-level provenance through reconciliation.
- Machine-readable coverage certificates for every constraint.
- Source certification and drift operations beyond the current alpha gates.
- A measured natural-language-to-canonical-query layer.
What comes next
The immediate work is not to add a larger promise. It is to strengthen the proof:
- Certify each source against explicit acceptance gates.
- Improve cross-source entity identity and conflict handling.
- Preserve richer provenance through reconciliation.
- Keep failed and unsupported cases inside the benchmark.
- Measure whether new source grammars can be added with decreasing manual effort.
The Journal will record those steps as they happen.
Evidence note: This field note describes a system direction alongside a dated technical-alpha snapshot. Current metrics refer to the defined internal real-source benchmark recorded on July 14, 2026. They are not a production SLA or a completeness guarantee.