| # CARTO User Guide | |
| ## What CARTO Is | |
| CARTO is the SnapKitty law engine. It combines: | |
| - a `Prolog` reasoning kernel | |
| - a `COBOL` procedure kernel | |
| - a `REXX` glue kernel | |
| - a reasoning fabric for engine attach and meta-lawyer spawn | |
| - a trust deed layer for governance and authority control | |
| It is a legal operations and reasoning system. It is not a filing bot and it is not autonomous legal advice. | |
| ## Core Surfaces | |
| ### 1. Corpus | |
| The corpus holds the legal terrain: | |
| - credit repair | |
| - sovereign trust architecture | |
| - ACH dispute protocol | |
| - FCRA / Metro 2 / zombie debt | |
| - fiduciary and agent law | |
| - bankruptcy | |
| - trust account scan | |
| - Moorish trust framework | |
| - IRS CatCode defense | |
| ### 2. Kernel Team | |
| - `CARTO / Prolog` handles standing, doctrine, breach, and terrain | |
| - `COBOL` handles corporate chunks, notices, ledgers, and records packets | |
| - `REXX` handles workflow movement, summons routing, and operator glue | |
| ### 3. Reasoning Fabric | |
| The reasoning fabric controls: | |
| 1. engine attach | |
| 2. audit gate | |
| 3. summon route | |
| 4. meta-lawyer spawn | |
| 5. WORM seal | |
| ### 4. Trust Deed Layer | |
| The trust deed layer controls: | |
| - deed generation | |
| - action scope | |
| - escalation authority | |
| - trustee and restriction rules | |
| ## How To Think About Routing | |
| Use `Prolog` when the work is about: | |
| - standing | |
| - breach | |
| - doctrine | |
| - legal classification | |
| Use `COBOL` when the work is about: | |
| - claim packets | |
| - trust-account routines | |
| - notices | |
| - corporate formation procedure | |
| - institution-shaped exports | |
| Use `REXX` when the work is about: | |
| - workflow movement | |
| - records routing | |
| - net-bound query handoff | |
| - repeated office actions | |
| ## Typical Flow | |
| 1. operator identifies the matter | |
| 2. `CARTO` audits and classifies the matter | |
| 3. the kernel lane is selected | |
| 4. if outside reasoning is needed, the reasoning fabric attaches an external engine | |
| 5. if action authority is needed, a trust deed is generated or attached | |
| 6. output is sealed into WORM when the path is complete | |
| ## What Is Live Versus Scaffolded | |
| ### Live In Repo | |
| - corpus layout | |
| - kernel definitions | |
| - reasoning-fabric definitions | |
| - trust deed runtime scaffolding | |
| - GitHub Pages frontend scaffold | |
| ### Still Scaffolded | |
| - live external engine calls | |
| - live deed form submission | |
| - live WORM persistence target | |
| - runtime tests | |
| ## Operator Rules | |
| - do not treat output as self-executing legal advice | |
| - do not bypass the deed layer for spawn or escalation | |
| - do not treat a scenario description as a court-ready filing | |
| - do not treat scaffolded runtime modules as production bindings | |