Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.trueparser.com/llms.txt

Use this file to discover all available pages before exploring further.

SQL

Use this contract for SQL statement results. It is designed for database review and automation workflows where teams need statement parsing, lineage analysis, migration assessment, governance checks, and schema-aware documentation from a stable public contract.

Top-level envelope

{
  "schema_version": "1.0",
  "document": {},
  "warnings": [],
  "content": []
}

Document fields

FieldNotes
source_file, document_nameSource file and display name.
formatAlways sql.
format_familyAlways sql_script.
document_id, content_hashOptional stable identifiers.
mime_typeMIME type when available.
title, author, subject, companyCross-engine document metadata fields.
created_at, modified_atTimestamps when available.
is_partialPublic completeness flag.
metadataAdditive document metadata.
record_count, statement_count, successful_statement_count, failed_statement_count, read_statement_count, write_statement_count, define_statement_count, admin_statement_count, unknown_statement_count, relationship_count, lineage_edge_count, diagnostic_count, object_countSummary counts when available.
confidence, complexity_score, sensitivity_hit_countPublic summary values when available.
status, completeness, dialectPublic extraction state.
dialect_signals, object_registry, optionsFamily-specific public metadata.

Universal content/block shape

Every public content record uses the same base shape.
FieldNotes
idStable record id.
typePublic record type.
orderDeterministic order.
pathPublic structural path.
parent_idParent record id.
depthStructural depth.
page_numberAlways null for SQL.
source_refProvenance object.
is_inferredInference marker.
warningsRecord-local notes.
content_hashOptional hash.
textSearchable text projection.
attributesSQL-specific structured data.
Common record types include statement, entity, relationship, lineage_edge, and diagnostic.

Warnings

  • warnings is always present.
  • Use plain strings.
  • Keep warnings human-readable.
  • Preserve recoverable parsing notes without hiding them.

What clients can rely on

  • Statement order stays stable.
  • Entity, relationship, and lineage records stay distinct.
  • dialect and other summary values stay explicit.
  • attributes carries SQL-specific details.
  • The public contract does not expose internal transport or worker details.

Example

{
  "schema_version": "1.0",
  "document": {
    "format": "sql",
    "format_family": "sql_script",
    "source_file": "script.sql",
    "dialect": "PostgreSQL",
    "statement_count": 1,
    "record_count": 3,
    "metadata": {}
  },
  "warnings": [],
  "content": [
    {
      "id": "stmt_0001",
      "type": "statement",
      "order": 1,
      "path": ["statement:1"],
      "parent_id": null,
      "depth": 0,
      "page_number": null,
      "source_ref": {
        "statement_id": "stmt-1",
        "statement_index": 1,
        "source_file": "script.sql",
        "dialect": "PostgreSQL"
      },
      "is_inferred": false,
      "warnings": [],
      "text": "SELECT 1;",
      "attributes": {}
    }
  ]
}
Last modified on April 28, 2026