knowledge_navigate
Navigate this world's indexed knowledge. Start from exactly one anchor and then take typed steps through the graph. Everything comes back keyed by canonical node id, so a semantic hit, a table row and a graph node are the same identities and need no join. THE ANCHOR IS EXACTLY ONE OF THREE. `query`, a text search: a query naming a billing code is answered by the code index, keyed on the procedure and MS-DRG nodes of the graph, and comes back anchored on those nodes with a ROLLUP of every edge the graph holds for each; a query naming no code is a search over the indexed prose chunks, optionally narrowed by `within` to chunks of the documents a table selector picks out. `node`, a canonical node id you already have. `select`, a table selector: `{"table": "documents", "where": {"state": "Alabama"}}`, which resolves to the node ids of the matching rows and comes back with those rows' columns, so a selector that lands on the rows you want is also how you read their values. Naming none of the three, or more than one, is refused rather than guessed. STEPS ARE TYPED AND DIRECTED. Each step names a `relation`, a `direction` and a `hops` count, and starts from what the previous step reached. Direction matters, because every edge is stored one way and the two directions are opposite questions. THE RELATIONS THIS WORLD CARRIES, each with the way its edge is stored: carried_in: register entry → data compartment. register entry to the data compartment its bytes are carried in read_by: data compartment → tool. data compartment to a tool that reads it declares: register entry → column name. register entry to a field name it declares. Taken `out` and then `in`, it is every other entry that declares the same field, which is what could be joined to it refuses: tool → refusal. tool to one reason it can refuse names: refusal → data compartment. refusal to a data compartment its own wording names. A refusal that reaches one is about data that is not here; a refusal that reaches none is a rule gated_by: register entry → access class. register entry to the access class that keeps it out addresses: article → procedure or DRG. policy article to a code it names issued_by: article → contractor. policy article to the contractor that issued it bundled_with: procedure (NCCI column 1) → procedure (column 2, the code denied). procedure code to the code it is bundled with, in the direction the NCCI edit is written priced_by: procedure → pricing class. procedure code to the schedule class that prices it rate_observed: payer → procedure or DRG. payer to a code it published a rate for: the `procedure` node for a CPT or HCPCS code, the `drg` node for one of the union_all MS-DRGs, which is the same node the hospitals' `filed_charge` reaches raises_risk_of: condition → outcome. condition to a later outcome, in one cited effect size, and never composable evidenced_by: effect-size edge → citation. effect-size edge to the published study it rests on co_occurs_with: condition → condition. condition to a condition it co-occurs with, as a proportion of cases and never an effect measure covers: register entry → jurisdiction. register entry to a jurisdiction its rules bind, as declared in the registry serves: contractor → jurisdiction. contractor to a jurisdiction it serves computed_by: tool → estimator. tool to the estimator it is member_of: procedure or DRG → code set. code to a declared code set, which is curatorial and never clinical refuses_composition: relation → corpus refusal. relation to a refusal the corpus states about composing it asserts: document → claim. document to a span-validated claim extracted from it about_code: claim → procedure or DRG. claim to the code it is about co_priced: procedure or DRG → procedure or DRG, stored both ways. code to a code some payer filed a rate for at the same facility in the same month, per the compacted rate lake, either end a `procedure` or a `drg` node. Stored in both directions, so `out` and `in` reach the same codes; a co-occurrence count with its n beside it, never a billing rule, which is `bundled_with` and the NCCI edit file manual_names: claim → procedure or DRG. payer-manual claim to the code its extracted `code` field names. Names and does not claim: what the claim says, which program's manual it came out of, what Vertex classified it as and whether one reader or both produced it travel beside the claim in the rollup, never on the edge manual_issued_by: manual → program or payer. payer manual to the program that issued it: a `program` node for CMS's Internet-Only Manuals (cms-iom) or a state Medicaid agency (medicaid-<state>), or the `payer` node itself for a commercial payer, under the slug its rates are keyed by, so a manual and a rate meet at one node manual_asserts: manual → claim. payer manual to a span-validated claim the extraction tier read out of it; the manual is keyed by the digest of its bytes, so a re-issued edition is a second node filed_charge: hospital → procedure or DRG. hospital to a code it filed a negotiated standard charge for under 45 CFR 180: the `procedure` node for a CPT or HCPCS code, a `drg` node for an MS-DRG. Stored hospital to code, so from a code it is taken `in`. The edge says a filing exists; the amount and its methodology stay in the hospital tier, and the rows, filings and payer strings behind the edge travel beside it, never on it files: hospital → payer. hospital to a payer whose name some payer_name string it filed under maps to, through the one string table in coverage-mrf; a bare `BCBS` names no state plan and reaches nothing. Stored hospital to payer, so from a payer it is taken `in`. It says the hospital filed a charge under the payer's name, as the regulation requires whether or not a contract is live, and never that it is in network A relation not on that list is refused by name against the ones that are. It is the list this world's own graph carries and not a list of what the software knows how to store, so a relation another world has is as unavailable here as one nobody has ever built. WHAT COMES BACK. The anchor as you gave it, every node visited with its kind and its key, the indexed text of every visited chunk cut to 600 characters with the byte offsets of the whole span, the columns of every row a `select` anchor matched up to 100 rows, the relation and direction each was reached over, the source documents with their digests where the index knows them, the numbering digest, and the semantic manifest fingerprint when a text query was used. Name the numbering digest in any claim you write about a node id: a rebuild that renumbers makes every id in an older answer a different node while the sentence still parses. A SEMANTIC HIT LICENSES A CLAIM ABOUT RETRIEVAL AND NEVER ABOUT CONTENT. That this chunk was the nearest hit for this query under this manifest is reproducible and assertable. That the chunk is about your query, or supports your sentence, is not, at any score and under any threshold, because a cosine measures proximity in an embedding space and nothing else. An empty result is evidence about the index and never about the corpus. The chunk's text comes back so you can read and quote the span at the byte offsets given; reading it is not evidence that the ranking was right, and a paragraph you find convincing was still returned by a cosine. WHEN A WORLD BLENDS, THE ORDER IS AN ASSUMPTION AND THE ANSWER SAYS SO. A world that declares a rank fusion returns hits ordered by a blend of the embedding cosine, the ranker's relevance where it ran, and a structural signal read off the graph, under weights that world declares. The `fusion` block carries each signal's own rank and own score for every hit, so you can decompose the ordering rather than trust it; a component that is missing for a hit means that signal did not rank it, which is NOT a score of zero and NOT a last place. The blended order is an assumption-basis ordering because the weights are a declared choice, so name those weights in any claim about the order. The structural signal's own sentence, naming which declared columns your query matched and how many sources share each, is the one part of the ordering you can check against the register yourself. A CODE IS AN IDENTIFIER, NOT A MEANING, AND IS LOOKED UP EXACTLY. Every text query passes a gate before anything is retrieved: each token carrying a digit and four or more characters, and each token of any length that is exactly a code the code index holds (an MS-DRG is three digits), is checked against the code index and the prose index, and a token that appears in no document of either is refused by name, before any embedding, because a term with document frequency zero cannot be in what was indexed and the nearest prose would be a match on the words around it. A token one document holds is never refused. The `lexical` block on every text answer says which index answered and which identifiers each index holds. THE ROLLUP IS THE UNIT TO READ FOR A CODE. An anchor that lands on a procedure or MS-DRG node, by a code in a `query` or by its `node` id, comes back with `rollups`: one hop over every relation in both directions, each with the sentence that says what the direction means. For `bundled_with` that sentence names which side of the NCCI edit the code is on, and the column 2 side is the code denied; read it rather than the relation name, because the edge is stored one way and a symmetric reading loses exactly that. The rollup records that a payer published a rate and never the amount; the amount is a quantity and lives in the table the `rate_position` tool serves. For `manual_names` taken in, each claim listed carries `program` (whose manual: cms-iom, medicaid-<state>, or a commercial payer under the slug its rates are keyed by), `vertex_ontology` (the extraction model's classification of the claim, a claim about the claim) and `confidence` (inter-reader agreement, never accuracy); a manual claim is what a document said on the day it was fetched, as a model read it, and never a payer's current policy. This is navigation and not a query shell. There is no SQL and no graph expression on this interface, and a table or a column nobody built is refused by name against the ones that exist. A QUESTION NAMING A CODE EXACTLY IS ANSWERED BY THE TOOL THAT SERVES THAT TABLE, and this tool's answer for a code is the graph's rollup rather than the table's row. The tools of this world that take a `code` or `codes` argument, each with what it holds: `rate_position`: The rate record: what one payer published it pays for one billing code, read from the payer machine-readable-file extract, positioned against the public fee schedule that anchors it, with `n` and the two thinness figures beside every cell. A what-does-payer-X-pay-for-code-Y question is this tool, `rate_position`, and a bundling question is `stack_check`. `rate_comparison`: The rate records for two to four codes under ONE receipt, from the same payer machine-readable-file extract `rate_position` reads, each code's own cells kept apart so a claim about them can be checked against a single receipt by `claim_check`. No ratio and no difference is served; `rate_position` is the one-code form. `stack_check`: The Medicaid NCCI procedure-to-procedure edit row for a pair of codes, read off the quarterly edit file: `pairs` with `column1`, `column2` and the modifier indicator, the MUE `limits`, and the `quarter` the file carries. A can-we-bill-X-with-Y question is this tool, `stack_check`. What a payer pays either code is `rate_position`. `interpretation_requirement`: The Medicare Local Coverage Article record for a code: `requirements` naming who the article says may furnish and interpret it, quoted from the article, or `not_in_corpus`. A who-may-bill-or-read-this-code question is this tool, `interpretation_requirement`. Whether a payer pays it is `rate_position`. `fee_components`: The Medicare fee schedule row for a code: its short `description`, `status_code`, `pctc_indicator` and the `work_rvu`, `nonfac_total_rvu` and `fac_total_rvu` split, from the MPFS and CLFS files this build carries. A how-is-this-code-priced-on-the-schedule question is this tool, `fee_components`; what a payer pays it is `rate_position`. `filed_charge`: What a hospital filed as its own standard charge for an inpatient admission under 45 CFR 180, per DRG and per counterparty, with the methodology that decides what the figure even is. Optionally split by facility. Read from the hospital price transparency filings by `filer`, `code_type` and `code`; the groupers and codes a filer carries are `filer_inventory`, and what a payer pays for a procedure is `rate_position`. Call the one that holds the record you want; an empty or gated answer here is a fact about the index and not about their tables. THIS WORLD'S SCHEMA, read from its knowledge compartment. NODE KINDS, which is what a `node` anchor and every visited node is one of: document, compartment, tool, refusal, column, access_class, jurisdiction, estimator, code_set, procedure, article, contractor, pricing_class, payer, drg, condition, outcome, citation, corpus_refusal, claim, manual, program, hospital. TABLES a `select` anchor may name, with their columns. Column 0 of every one is `node_id`, the canonical identity a selector resolves to. documents(node_id bigint, source varchar, state varchar, table_state varchar, gavel_vintage varchar, note varchar, columns varchar, n_columns bigint, gavel_row_count bigint, upstream_files varchar, upstream_file_count bigint, carried_in varchar, why_not_shipped varchar, never_a_figure varchar) VOCABULARIES. Every value a low-cardinality column takes, so a selector can match one rather than guess at its spelling. documents.state is one of: absent, available, shipped documents.table_state is one of: converted, not_a_table, not_in_gavel, other_layout, raw_only, unpacked documents.carried_in is one of: , data/cohort_figures, data/comorbidity, data/hypertension, data/policy, data/psps_realization HOW TO READ THIS CORPUS, which the column names do not tell you. The semantic index reaches only the documents the extractor could read. Everything in a format it cannot open is in the corpus and NOT in the index. So a retrieval that returns nothing is evidence about the index and never about the corpus, and "this world has no document about X" is not a sentence a retrieval can support.
Use this form for new arguments. Follow concrete links for known values. Fetch-only readers may be unable to submit new URLs.
Exact input contract
{
"properties": {
"limit": {
"description": "How many hits a `query` anchor takes, defaulting to 5; and how many neighbours one hop of a step over a weighted relation (`co_priced`, which carries `n_facilities` and `n_payer_months` beside its edges) keeps, most weight first, defaulting to 25, the rollup's own cut. A step over an unweighted relation keeps every neighbour and refuses past 2000 visited nodes; a step over a weighted one is cut instead and says `nodes_cut` with the `total` on its `relations` entry.",
"type": "integer"
},
"node": {
"description": "A canonical node id, from an earlier answer. One of the three anchors.",
"type": "integer"
},
"query": {
"description": "A text query. One naming a billing code is answered by the code index and anchors on that code's procedure or MS-DRG node with its rollup; one naming no code is embedded through this world's pinned model and matched against the indexed chunks. A code no index holds is refused by name before anything is retrieved. One of the three anchors.",
"type": "string"
},
"rerank": {
"description": "Whether a `query` anchor's shortlist is reordered by this world's declared ranking model before it is returned. `auto`, the default, decides by the size of the index against the world's threshold and says in the answer which side it fell on. `always` reorders whatever the size; `never` says the ordering is the embedding cosine's by your choice. Either way the answer names the ranker and carries both orderings, and a relevance score is NEVER comparable to a cosine.",
"enum": [
"auto",
"always",
"never"
],
"type": "string"
},
"select": {
"description": "A declared table selector, resolving to the node ids of the matching rows. One of the three anchors.",
"properties": {
"table": {
"description": "A declared table.",
"type": "string"
},
"where": {
"description": "Column to value, compared for equality. Strings and integers only.",
"type": "object"
}
},
"required": [
"table"
],
"type": "object"
},
"steps": {
"description": "Typed graph transitions, in order. Each starts from what the previous one reached.",
"items": {
"properties": {
"direction": {
"description": "`out` follows the edge as stored, `in` follows it backwards. Required: an edge is stored one way and the two directions are opposite questions.",
"enum": [
"out",
"in"
],
"type": "string"
},
"hops": {
"description": "How many times to follow it. Defaults to 1.",
"type": "integer"
},
"relation": {
"description": "The relation to follow. These are the relations THIS world's graph carries; the tool description says what each runs between.",
"enum": [
"carried_in",
"read_by",
"declares",
"refuses",
"names",
"gated_by",
"addresses",
"issued_by",
"bundled_with",
"priced_by",
"rate_observed",
"raises_risk_of",
"evidenced_by",
"co_occurs_with",
"covers",
"serves",
"computed_by",
"member_of",
"refuses_composition",
"asserts",
"about_code",
"co_priced",
"manual_names",
"manual_issued_by",
"manual_asserts",
"filed_charge",
"files"
],
"type": "string"
}
},
"required": [
"relation",
"direction"
],
"type": "object"
},
"type": "array"
},
"within": {
"description": "Narrows a `query` anchor to chunks whose source document this selector picks out.",
"properties": {
"table": {
"description": "A declared table.",
"type": "string"
},
"where": {
"description": "Column to value, compared for equality. Strings and integers only.",
"type": "object"
}
},
"required": [
"table"
],
"type": "object"
}
},
"type": "object"
}