How GraveTrail works

GraveTrail keeps presentation separate from parsing, storage and investigation. The UI, CLI and MCP adapters call shared services. No imported SQL, SAS or CSV content is executed.

flowchart TB
    Sources[SQL / SAS / CSV] --> Import[Safe import and inventory]
    Import --> Parse[Static parsers]
    Parse --> Resolve[Identity and cross-file resolution]
    Resolve --> Store[(DuckDB and original blobs)]
    Store --> Graph[Lineage and direct usage]
    Graph --> UI[Streamlit / CLI / MCP]
    Graph --> Export[Reports and offline graph]
    Parse -. bounded optional context .-> AI[Validated AI assistance]
    AI -. explicit inferred merge .-> Store

Question	Reference
Where do services, UI and persistence belong?	System architecture
How are originals, operations and evidence versioned?	Data model
How are assets resolved and temporary steps collapsed?	Lineage engine
Which SQL constructs are supported?	SQL coverage
What do SAS rules resolve, and what stays uncertain?	SAS coverage
How are prompts and grounded claims validated?	Prompt engineering and LLM integration
What protects imports, secrets and destructive operations?	Security model
What has actually been measured?	Performance evidence

Keep the distinction between facts and inference

Asset identity uses stable IDs and namespace/job context, not a global table-name merge. Ambiguous names stay unresolved. Evidence pins original source hashes and exact line ranges, so a later import cannot silently replace the statement behind an earlier edge. Temporary contraction keeps its underlying logical steps and provenance.

Direct column usage reports references to the selected source. The separate transformation service follows output/value derivations with bounded traversal and coverage markers. Wildcards expand only with trustworthy schema evidence. Logical dependency order does not establish runtime execution order.

For implementation conventions and adding parsers, continue to development.