Enterprise Automation Use Cases

Seven enterprise automation use cases for EKOS with an orchestrator such as Dagster or LangGraph: what EKOS does today, what the orchestrator adds, and what is not built yet.

EKOS compiles code, schemas, SQL, documents and Git history into evidence-backed knowledge. It serves that knowledge read-only over MCP. Many enterprise automations need exactly this, but EKOS is one part of them, not all of them. An orchestrator runs the workflow. Dagster suits asset-centric data pipelines. LangGraph suits iterative agent loops: write a change, check it against EKOS, fix, retry. People approve what is risky.

 [ code · SQL · schemas · documents · Git · binaries ]
                        │  observe, compile (deterministic)
                        ▼
              [ EKOS knowledge ledger ]  ── every fact cites file:line
                        │  read-only MCP / CLI
                        ▼
      [ your orchestrator: Dagster, LangGraph, CI ]  ── proposes changes as pull requests
                        │
                        ▼
              [ a person reviews and merges ]

Each use case below says three things: what EKOS does today, what the orchestrator or an agent adds, and what is not built. EKOS checks a proposed change against the compiled graph. That check finds broken references and missed dependents. It does not prove a change correct, and the review step stays.

1. Personal-data audit

Problem. Personal data reaches places it should not, such as plain-text logs, caches or third-party analytics. Nobody can say which code paths carry it.

• EKOS today: builds call graphs for Rust, Python, JavaScript/TypeScript, Elixir and Perl, plus which code reads and writes which table and column-level SQL lineage. A reviewer or agent can follow a column from the table to the code that uses it, with path:line on every step. EKOS's own store holds no secrets or personal data: redaction runs before anything is stored, and it cannot be switched off.
• Orchestrator adds: an agent loop that walks those paths from the columns you mark as personal and proposes masking changes as pull requests.
• Not built: variable-level taint analysis inside a function, and automatic classification of personal-data columns.

2. Legacy modernization and database migration

Problem. Old systems hide undocumented dependencies, and these are what break during a rewrite or a database move.

• EKOS today:
• Recovers stored procedures, views and triggers from source. On LedgerSMB that was all 212 PL/pgSQL routines.
• Explains legacy ETL step by step (ekos_transformation_explain, for Pentaho, SQL and procedures) and renders Pentaho jobs as dbt models.
• Answers "what breaks if this changes" several hops out (ekos_impact).
• Scores architecture completeness.
• EKOS Migrate moves PostgreSQL to ClickHouse with an evidence-backed design, approval gated by computed risk (human-only), and validation against the source: see Migrating a Database.
• Compiled .NET and JVM binaries are recovered by a separately licensed extension.
• Orchestrator adds: an agent that rewrites a module, then re-runs the pipeline on the result and checks ekos_impact and the dependents for anything left dangling, before a person reviews it.
• Not built: COBOL and C++ recovery, automatic service-boundary proposals, and gRPC/OpenAPI generation.

3. Pipelines that notice upstream changes

Problem. An application change, such as a renamed column, silently breaks dbt models and dashboards downstream.

• EKOS today:
• Compiles dbt projects (models, ref()/source(), schema tests) and SQL into one graph with the application code.
• ekos_impact lists the models and tables that read a changed column.
• ekos freshness reports which source files changed since the last compile, and which objects cite them.
• Where sources disagree, EKOS records a conflict instead of picking a side.
• Orchestrator adds: a CI job or Dagster sensor that re-compiles on each pull request, asks ekos_impact about the changed objects, and comments with the blast radius. An agent can draft the matching dbt change as a separate pull request. See Automation.
• Not built: automatic fixes merged without review. EKOS never merges anything.

4. Living architecture documentation and audit evidence

Problem. Architecture documents go stale the day they are written, and gathering audit evidence (SOC 2, ISO 27001, NIS2) is manual.

• EKOS today:
• ekos docs generate renders curated architecture, API and sequence-diagram pages from the ledger, with no LLM. Its solution-architect layout adds a dependency risk report, an onboarding guide and a findings memo.
• ekos diff and AS OF queries show what changed between two dates.
• ekos ledger audit shows which run wrote each fact.
• Architecture drift and diff tools compare one run with the next.
• Orchestrator adds:
• regenerating the documents on every merge;
• a writer agent that turns the diff into changelogs or decision-record drafts for a person to edit;
• EKL queries that check a rule you state, such as "nothing in payments calls analytics", and fail the job when it breaks.
• Not built: ready-made compliance packages, and a library of built-in architecture rules.

5. Finding unused code and tables

Problem. Unused tables, abandoned services and dead code cost money, and teams are afraid to delete them.

• EKOS today: ekos_dependents and EKL queries find objects that nothing compiled depends on. Each answer cites its evidence, so a person can check why EKOS thinks an object is unused.
• Orchestrator adds: a periodic job that lists candidates and opens deprecation pull requests for review.
• Not built: parsing Terraform or Kubernetes manifests, and usage from live traffic. EKOS sees only the sources it compiles, so "nothing depends on it" covers only those sources. A table read by an unindexed system will look unused.

6. Replacing a library or SDK across many repositories

Problem. A license change or a deprecated SDK forces a migration across hundreds of repositories on a deadline.

• EKOS today: compiles declared dependencies from package manifests, and imports and calls from code, across every indexed repository into one ledger. One EKL query lists every repository and file that uses the library.
• Orchestrator adds: batch agent workers that write the patches, re-compile each repository to check for broken references, and open a pull request per repository.
• Not built: automatic patching. EKOS does not check that a patch type-checks; your compiler and tests do that.

7. Technical due diligence and onboarding

Problem. After an acquisition, or when a new team inherits a system, it takes months to learn what the system is and where its risks are.

• EKOS today:
• Compiles the source, SQL and documents. Compiled binaries go through the extension.
• ekos identity scan proposes matches between objects in different systems, as unconfirmed claims for review.
• Objects with many dependents become recorded concentration risks.
• The solution-architect documents give a team its first map.
• ekos ask and MCP give the new team a cited question-and-answer interface.
• Orchestrator adds: a review workflow that walks the candidate matches and risks with the people who know the systems.
• Not built: automatic classification of modules into business domains.

Get started

Index one system first and connect an agent: Quickstart, then Connect Your AI Agent. Everything above that EKOS does today runs on a single machine from the open-source release.

Quickstart → Documentation → GitHub →