◈ Root-LD Living Document

The Lexicon

The shared vocabulary of the federation — law, business, AI, economics, and everything between

Spec Version
1.0
Document Type
◉ Living
Terms Defined
Domains Covered
5
§ 1

What Is The Lexicon

#what-is-lexicon

The Lexicon is the shared vocabulary of the Root-LD federation. It is the bridge that makes lexical edge-building possible across domains that would otherwise have no common language. A statute about procurement fraud and a business entity profile and an AI methodology definition all live in different domains, serve different purposes, and were created by different processes. The Lexicon is what connects them.

Every domain in the federation contributes terms. Every term is reviewed before inclusion. Every approved term becomes available immediately for cross-domain edge-building against every entity in the full corpus — past, present, and future. When two entities in different domains share a Lexicon term, that shared term is a candidate for a LEXICALLY-RELATED edge. When enough shared terms accumulate, the edge is confirmed.

The Lexicon is itself a Root-LD entity — a DEFINITION class object with its own federationId, its own edges, and its own version history. It does not sit outside the graph. It is part of the graph.

◈ Scope — Not Just Law
The federation spans law and procurement, but also local businesses, AI concepts, search methodology, economic indicators, and anything else that can be expressed as a structured, provenance-backed entity. The Lexicon reflects that full breadth. A bar in Los Angeles, the Sherman Antitrust Act, a definition of semantic search, and a CPI indicator are all entities in the same graph. The Lexicon is the vocabulary they share.
§ 2

How It Works In The Graph

#how-it-works
Terms Defined
5
Source Domains
Pass 2
Used In
Grows Over Time

During Pass Two of the Federation Passes — the Lexical Pass — every entity's bodyText and summary fields are run against the full Lexicon. The system counts shared term density between entity pairs. High density creates a LEXICALLY-RELATED edge at proportional confidence. That edge then feeds into Pass Three for semantic confirmation.

A procurement bid on oakmorel.com that contains "prevailing wage," "scope of work," and "invoice reconciliation" shares three Lexicon terms with a forensic methodology definition on recursiveengineoptimization.com. Those shared terms create a candidate edge. The LLM confirms it. The confirmed edge makes both entities more discoverable, more connected, and more valuable to any system — human or AI — that queries the graph.

This is why the Lexicon matters. Every term added increases the intelligence of the entire graph retroactively — because the pass runs against the full corpus every time.

§ 3

Term Registry

#terms

The current federation lexicon. Organized by domain of origin. Terms marked CROSS appear across multiple domains and are the highest-value edge candidates in the graph. Click any term to expand its full definition, federation metadata, and edge candidates.

Filter:
No terms match your search. Try different keywords or clear the filter.
Procurement
STATUTE · BID oakmorel.com
The process by which a government entity acquires goods, services, or construction through a competitive solicitation process governed by public law.
The formal acquisition of goods, services, or construction by a government agency through a regulated solicitation process. In the Root-LD federation, procurement is the primary bridge between the law domain (statutes, regulations) and the bid domain (solicitations, contracts). Every bid entity has a governing statute. Every contract has an issuing agency. Procurement is the concept that links them.
Domain Originoakmorel.com
Entity ClassesSTATUTE, REGULATION, BID, CONTRACT, ENTITY
FederationId PatternOM-BID-{hash} · OM-CONTRACT-{hash}
Cross-Domain UseAppears in franklinsledger.com (spending data) and rankwithme.ai (business profiles of contractors)
Edge Candidates
BID GOVERNS → STATUTE CONTRACT ISSUED-BY → ENTITY STATUTE ENFORCED-BY → ENTITY
Prevailing Wage
STATUTE · REGULATION oakmorel.com
The minimum hourly wage required to be paid to workers on publicly funded construction projects, determined by locality and trade classification.
A legally mandated minimum wage rate for workers employed on government-funded construction, alteration, or repair projects. Governed federally by the Davis-Bacon Act and by equivalent statutes in most states. In the federation, prevailing wage terms appear in bid solicitations, contract compliance requirements, and the statutes that establish the rates. A bid that contains "prevailing wage" inherits a lexical edge to every Davis-Bacon statute in the corpus.
Domain Originoakmorel.com
Entity ClassesSTATUTE, REGULATION, BID, CONTRACT
Key Statute40 U.S.C. §§ 3141–3148 (Davis-Bacon Act)
Cross-Domain Usefranklinsledger.com (labor cost economic data), rankwithme.ai (contractor business profiles)
Edge Candidates
BID GOVERNS-INVERSE → STATUTE REGULATION ENFORCED-BY → ENTITY
Solicitation Number
BID · CONTRACT oakmorel.com
The official identifier assigned to a public procurement solicitation by the issuing agency. The primary deduplication key for bid entities across systems.
A unique alphanumeric identifier assigned by a contracting agency to a specific procurement action — RFP, RFQ, IFB, or other solicitation type. The solicitation number is the cross-system identifier that allows a bid on SAM.gov, the same bid on a state portal, and the same bid as a Root-LD entity to be recognized as the same procurement. It is the primary key in the identifiers array of every BID entity.
Domain Originoakmorel.com
Entity ClassesBID, CONTRACT
Anchor Fieldidentifiers[] → solicitationNumber
Edge Candidates
BID ISSUED-BY → ENTITY BID SUPERSEDES → BID
Invoice Reconciliation
FORENSIC · BID oakmorel.com
The systematic comparison of invoiced charges against quoted rates, contracted terms, and delivered goods or services to identify discrepancies, substitutions, or overcharges.
A forensic methodology for verifying that invoiced amounts match agreed-upon rates, that delivered items match ordered items, and that billing patterns do not indicate systematic fraud or rate drift. In the federation, invoice reconciliation methodology terms appear in OakMorel research entities, forensic case studies, and procurement fraud statutes. A statute governing procurement fraud and an OakMorel forensic methodology entity share this term — and that shared term creates a LEXICALLY-RELATED edge between them.
Domain Originoakmorel.com
Entity ClassesRESEARCH, CASE, STATUTE
Cross-Domain Userecursiveengineoptimization.com (extraction methodology), franklinsledger.com (financial audit concepts)
Edge Candidates
RESEARCH FORENSICALLY-RELEVANT → STATUTE CASE CITES → STATUTE
Regulatory Authority
STATUTE · ENTITY oakmorel.com
The government agency or body designated by statute to administer and enforce a specific body of law or regulation.
The entity — typically a federal or state agency — with statutory authority to enforce a specific law or regulation. In Root-LD, regulatory authority is both a STATUTE body field (regulatoryAuthority) and the conceptual bridge that creates ENFORCED-BY and ENFORCES edges between statute entities and government entity entities. Every statute in the graph that names a regulatory authority inherits a deterministic edge to that authority's ENTITY record. These are Pass One edges — confidence 1.0, no LLM required.
Domain Originoakmorel.com
Entity ClassesSTATUTE, REGULATION, ENTITY
Anchor Fieldbody.regulatoryAuthority → federationId
Edge Candidates
STATUTE ENFORCED-BY → ENTITY ENTITY ENFORCES → STATUTE
Entity
ORGANIZATION · WEBPAGE rankwithme.ai
A distinct, uniquely identifiable thing — a business, a person, a place, a concept — that can be represented as a structured record with persistent identity across systems.
In the federation, an entity is any real-world thing that can be given a federationId, a primarySource, and a structured body. A bar in Los Angeles is an entity. The EPA is an entity. The Sherman Antitrust Act is an entity. A definition of semantic search is an entity. The Root-LD architecture treats all of these with identical anchor structure because identity, provenance, and verifiability are universal requirements regardless of what the entity is. On rankwithme.ai specifically, "entity" refers to the business or organization profile that gets indexed and made machine-readable.
Domain Originrankwithme.ai
Entity ClassesORGANIZATION, WEBPAGE, PERSON, ENTITY
Cross-Domain UseAll domains — every Root-LD record is an entity by definition
Edge Candidates
ORGANIZATION JURISDICTIONALLY-RELATED → ENTITY ORGANIZATION TOPICALLY-RELATED → RESEARCH
Business Profile
ORGANIZATION rankwithme.ai
A structured, machine-readable record of a local or regional business containing verified identity data, contact information, service areas, and operational metadata.
The primary entity type on rankwithme.ai. A business profile is an ORGANIZATION class Root-LD entity with a verified primarySource (the business's official website or Google Business Profile), a consistent NAP (Name, Address, Phone), and structured body fields describing what the business does, where it operates, and how to engage with it. A landscaping company, a law office, a bar, a general contractor — all are business profiles, all carry identical anchor structure, all are immediately available for edge-building against every other entity in the federation.
Domain Originrankwithme.ai
Entity ClassesORGANIZATION
Key IdentifiersEIN · business license · UEI · DUNS
Cross-Domain Useoakmorel.com (contractor bid history), franklinsledger.com (spend data)
Edge Candidates
ORGANIZATION JURISDICTIONALLY-RELATED → BID ORGANIZATION REFERENCED-BY → CONTRACT
Structured Data
WEBPAGE · DEFINITION rankwithme.ai
Machine-readable metadata embedded in or associated with a web document that allows automated systems to understand and process the document's content without human interpretation.
In the context of the federation, structured data is both the goal and the method. Every Root-LD entity is structured data — it is organized according to a schema, carries machine-readable fields, and is designed to be consumed by automated systems including search engines, AI models, and federation crawlers. On rankwithme.ai, structured data refers specifically to schema.org markup and Root-LD entity records that make a business's identity legible to the post-search internet. The Root-LD spec is itself a structured data specification.
Domain Originrankwithme.ai
Entity ClassesWEBPAGE, DEFINITION, RESEARCH
Cross-Domain UseAll domains — structured data is the foundation of the Root-LD architecture
Edge Candidates
WEBPAGE TOPICALLY-RELATED → DEFINITION DEFINITION REFERENCES → RESEARCH
Semantic Search
DEFINITION · RESEARCH recursiveengineoptimization.com
A search methodology that understands the meaning and intent behind a query rather than matching exact keywords, enabling retrieval of conceptually relevant results regardless of literal term overlap.
Search that operates on meaning rather than character strings. A semantic search for "who governs contractor wages on federal jobs" retrieves the Davis-Bacon Act even if that document never contains the word "governs." In the Root-LD federation, semantic search is what Pass Three and Pass Four enable — the LLM and fine-tuned model understand conceptual relationships that no keyword match can find. The entire federation pass architecture is a form of semantic indexing applied to structured entities.
Domain Originrecursiveengineoptimization.com
Entity ClassesDEFINITION, RESEARCH, WEBPAGE
Cross-Domain Userankwithme.ai (search methodology), root-ld.org (Pass Three / Pass Four definition)
Edge Candidates
DEFINITION TOPICALLY-RELATED → RESEARCH RESEARCH REFERENCES → DEFINITION
Knowledge Graph
DEFINITION · RESEARCH recursiveengineoptimization.com
A structured representation of knowledge as a network of entities and the relationships between them, enabling both machine and human traversal of complex information landscapes.
A graph data structure where nodes are entities and edges are relationships. The Root-LD federation is a knowledge graph — entities are nodes, Recursive-LD edges are the relationships, and the federation passes are the mechanism by which new edges are discovered and confirmed. Unlike traditional knowledge graphs, the Root-LD federation is federated across independently operated domains that conform to a shared specification. The graph does not live in one place. It is assembled from the anchor layers of every entity across every registered domain.
Domain Originrecursiveengineoptimization.com
Entity ClassesDEFINITION, RESEARCH
Cross-Domain UseAll domains — the federation is itself a knowledge graph
Edge Candidates
DEFINITION REFERENCES → RESEARCH RESEARCH TOPICALLY-RELATED → DEFINITION
Fine-Tuning
RESEARCH · DEFINITION recursiveengineoptimization.com
The process of further training a pre-trained language model on a specific dataset to improve its performance on a targeted domain or task.
Adapting a general-purpose model to a specific domain by training it on curated examples from that domain. In the Root-LD federation, fine-tuning is the mechanism behind Pass Four — the Semantic-Finetuned pass. The confirmed edge rationales from Passes One, Two, and Three become the training dataset. The resulting model — The Lexicon Model — understands the federation's specific vocabulary and conceptual relationships in a way that no general-purpose model can replicate. This is the moat. Fine-tuning on proprietary edge data produces proprietary reasoning.
Domain Originrecursiveengineoptimization.com
Entity ClassesRESEARCH, DEFINITION, DATASET
Federation UsePass Four — Semantic-Finetuned. The Lexicon Model.
Edge Candidates
RESEARCH REFERENCES → DATASET DEFINITION TOPICALLY-RELATED → RESEARCH
Provenance
DEFINITION · RESEARCH recursiveengineoptimization.com
The documented chain of origin, custody, and transformation history of a piece of data or content — the verifiable record of where something came from and how it got here.
The complete, verifiable record of a data artifact's origin and transformation history. In Root-LD, provenance is enforced by the anchor layer — specifically the immutable fields: primarySource, dateIngested, contentHash, and generationMethod. These four fields together constitute the provenance record for every entity. An entity without a verifiable primarySource cannot be minted. Provenance is not optional. It is the precondition for existence in the graph.
Domain Originrecursiveengineoptimization.com
Entity ClassesAll classes — provenance is universal
Anchor FieldsprimarySource · dateIngested · contentHash · generationMethod
Cross-Domain UseAll domains — the anchor layer is the provenance record
Edge Candidates
RESEARCH REFERENCES → DEFINITION DEFINITION CITED-IN → RESEARCH
Economic Indicator
ECONOMIC · DATASET franklinsledger.com
A quantitative measure published by an authoritative government agency to represent the state or trajectory of an economic condition over a defined reporting period.
A statistic published by a government agency — BLS, Census Bureau, Federal Reserve, BEA — that measures some aspect of economic activity. CPI, unemployment rate, GDP growth rate, construction cost indices. In the Root-LD federation, economic indicators are ECONOMIC class entities with their own federationIds, primarySources (official agency URLs), and structured body fields. An economic indicator that shows construction cost inflation is LEXICALLY-RELATED to procurement bids in the same period and FUNDS-related to the government budgets that cover those contracts.
Domain Originfranklinsledger.com
Entity ClassesECONOMIC, DATASET
Key FieldsindicatorCode · reportingPeriod · value · unit · methodology
Cross-Domain Useoakmorel.com (procurement cost analysis), rankwithme.ai (market context for business profiles)
Edge Candidates
ECONOMIC FUNDS → ENTITY ECONOMIC LEXICALLY-RELATED → BID
Budget Authority
ECONOMIC · ENTITY franklinsledger.com
The amount of money that a government entity is legally authorized to spend or commit in a given fiscal period, as appropriated by the relevant legislative body.
The legal authority to obligate funds, granted by a legislature through appropriation. Budget authority is a field in the ENTITY class body (budgetAuthority) and a concept that creates FUNDS edges between ECONOMIC entities and ENTITY records. A school district with $50M in annual budget authority is connected to every bid it issues and every economic indicator that measures education funding in its jurisdiction. Budget authority is the money that makes procurement possible — the financial upstream of every contract in the graph.
Domain Originfranklinsledger.com
Entity ClassesECONOMIC, ENTITY, DATASET
Anchor Fieldbody.budgetAuthority (ENTITY class)
Edge Candidates
ECONOMIC FUNDS → ENTITY ENTITY FUNDED-BY → ECONOMIC
Jurisdiction
ALL CLASSES Cross-Domain
The defined geographic or legal boundary within which a law applies, an agency operates, a business serves, or a contract is enforceable.
The most universal cross-domain term in the federation. Jurisdiction is a universal body field — present in every entity regardless of class or domain. It is the normalization layer that allows a bid from Los Angeles County, a statute from California, a federal regulation from the EPA, and a business profile from Burbank to all share a JURISDICTIONALLY-RELATED edge without custom mapping. Jurisdiction is the geographic anchor of the graph. It is how a local business becomes connected to the law that governs it, the agency that regulates it, and the contracts it can compete for.
Domain OriginAll domains — universal field
Entity ClassesAll classes
Anchor Fieldbody.jurisdiction — hierarchical: Federal > State > County > Municipal
Cross-Domain UseEvery entity in every domain carries a jurisdiction value
Edge Candidates
ANY JURISDICTIONALLY-RELATED → ANY
Primary Source
ALL CLASSES Cross-Domain
The original, authoritative document or record from which an entity's content was derived — the upstream source that gives the entity its right to exist in the graph.
The canonical URL of the original source document. For a statute: the official government URL. For a business: the verified business website or Google Business Profile. For an economic indicator: the official agency data release. For a research paper: the canonical DOI or institutional URL. An entity without a verifiable primarySource cannot be minted. This is the absolute rule. Primary source is the prerequisite for existence in the graph — it is what separates the federation from a content farm, from a directory, from an LLM hallucination.
Domain OriginAll domains — universal requirement
Entity ClassesAll classes
Anchor Fieldanchor.primarySource — immutable after minting
GovernanceImmutable. Cannot be changed. Changing the source requires minting a new entity.
FederationId
ALL CLASSES Cross-Domain
The globally unique, permanent, immutable identifier for an entity across the entire Root-LD federation. The entity's permanent identity in the graph.
The most fundamental identifier in the federation. Format: {domainCode}-{entityClass}-{deterministicHash}. Generated at ingestion from the entity's primarySource and class. Never changes. When an external system records a federationId it can always resolve it — even if the entity is deprecated, the deprecated record will point to the current version. The federationId is what makes the graph trustworthy. A system that knows a federationId knows it will always resolve to the same entity, forever, regardless of what else changes around it.
Domain Originroot-ld.org — specification-level definition
Entity ClassesAll classes — universal
FormatOM-STATUTE-7x9k2m · RW-ORGANIZATION-9c2d4e · FL-ECONOMIC-2b7e9a
GovernanceImmutable. Never changes after minting.
Edge
RECURSIVE-LD Cross-Domain
A confirmed semantic relationship between two entities in the federation, with a type drawn from the edge taxonomy, a confidence score, and the method by which it was established.
The fundamental unit of intelligence in the Recursive-LD layer. An edge is not a link — it is a confirmed relationship with a type, a confidence score, a confirmation method, and a date. Edges are discovered by the federation passes: deterministic matching (confidence 1.0), lexical density scoring, LLM semantic confirmation, and fine-tuned model reasoning. The edges are what make the federation more than a collection of documents. Every edge is a fact the graph knows about the relationship between two entities — a fact that no single entity contains on its own.
Domain Originroot-ld.org — specification-level definition
StructuretargetId · edgeType · confidence · confirmationMethod · weight
Types20 defined in the edge taxonomy. See Spec §Edge Taxonomy.
Cross-Domain UseAll domains — edges cross domain boundaries by design
Compound Reasoning
DEFINITION Cross-Domain
The emergent property of a mature Root-LD federation whereby each new entity added to any domain immediately increases the intelligence of the entire graph.
The network effect of the federation at scale. When a new entity is added to rankwithme.ai, it is immediately available for edge-building against every entity in every other domain. The new entity does not just add a node — it adds potential edges to thousands of existing nodes, retroactively enriching the graph. When the lexicon grows by one term, every existing entity is re-evaluated against that term. When the fine-tuned model improves, its improvement applies to the entire corpus. Compound Reasoning is why the federation becomes more valuable as it grows — not just proportionally, but exponentially. Each addition multiplies the intelligence of what was already there.
Domain Originroot-ld.org — specification-level definition
Entity ClassesDEFINITION — canonical federation vocabulary
Cross-Domain UseThe defining property of the federation at maturity
§ 4

Contributing Terms

#contributing

Every registered federation domain contributes terms to the Lexicon. A term contribution is not a suggestion — it is a formal submission that, once approved, becomes part of the shared vocabulary against which every entity in the full corpus is evaluated during Pass Two. Contributions must meet the requirements below before review.

Term Submission Requirements Before Review
01
The term must be domain-specific vocabulary — it must appear naturally in content within the submitting domain and must not be a generic English word without technical meaning in that domain context. "Invoice" is generic. "Invoice reconciliation" is domain-specific.
02
The term must have cross-domain edge potential — it must plausibly appear in at least one other federation domain's entity content. A term that only appears in one domain creates no cross-domain edges and adds no value to the Lexicon.
03
The term must include a canonical definition — plain language, specific, written for the federation context. Not a Wikipedia summary. Not a dictionary entry. A definition that explains why this term matters in the graph.
04
The term must identify at least two entity classes where it is likely to appear and at least one edge type that the term's presence in two entities would trigger as a candidate.
05
The term must not duplicate an existing Lexicon entry. If the concept exists under a different name, the submission should propose an alias to the existing term rather than a new entry. Synonyms pollute the Lexicon and reduce edge precision.
§ 5

Lexicon Governance

#governance

The Lexicon is a living document but it is not an open document. Terms are added by registered federation domains and reviewed before inclusion. Terms are never removed — only deprecated, with a deprecation note explaining which current term supersedes them. The Lexicon's version history is preserved in full.

◈ Living Document
This page will grow continuously as the federation grows. Every new domain that registers contributes terms. Every new entity class that gets defined adds vocabulary. Every pass run produces rationales that surface new candidate terms. The Lexicon is never finished. It is a reflection of how much the federation understands about the world it is mapping.

The Lexicon is itself a Root-LD entity. Its own federationId is RLD-DEFINITION-lexicon-v1. Its primarySource is this page. Its contentHash is updated on every term addition. It has edges to every domain that contributes terms to it. It participates in the graph the same way every other entity does — it is not above the graph, it is part of it.