Repository & Language Support
What LegacySafe AI can ingest today, and what's roadmap-only. This page is deliberately honest: no code parser or static analysis engine is wired up in this hackathon build.
Working today
Any text content — regardless of source language or format — can be stored as a
SourceDocument, tagged with a document_type and an
access_level, and chunked into permission-aware memory. Retrieval is plain
keyword overlap; there is no code-aware parsing yet.
| Document type | Seeded in this demo project? |
|---|---|
| ESG Report | yes |
| Solar & Battery Feasibility | yes |
| Heat Pump & Boiler Replacement | yes |
| Insulation & Heat Loss Reduction | yes |
| Smart Meters & IoT Sensors | yes |
| Grid & Load Optimisation | yes |
| Investment Budget | yes |
| Equipment Procurement | yes |
| CAPEX/OPEX & ROI | yes |
| Strategy Memo | yes |
| Worker & Community Transition | yes |
| Justice & Maqasid Review | yes |
| Other | yes |
Roadmap: language-aware code scanning
Not implemented in this hackathon build. Listed here as the concrete integration seam for real repository support (GitHub/GitLab, per the Model + Enterprise Integration Readiness page), using Tree-sitter for parsing and Semgrep for pattern-based legacy-risk rules.
| Language / format | Planned tooling |
|---|---|
| Python | Tree-sitter grammar available |
| JavaScript / TypeScript | Tree-sitter grammar available |
| Java | Tree-sitter grammar available |
| COBOL | Common in legacy ERP/mainframe systems — Tree-sitter grammar available |
| C / C++ | Tree-sitter grammar available |
| SQL / stored procedures | Semgrep rule support available |
| ABAP (SAP) | Niche grammar support — evaluate on integration |
Security note
When repository ingestion ships, a code file's access_level would gate its
visibility exactly like any report or memo does today — the same deterministic
can_access() check, no separate code-specific permission path.