← All projects

Project 01 · Agentic AI · Data Intelligence · Application Generation · AI Engineering

SKatalyst AI

Turn organizational data into context, and context into software.

Organizations already have enormous amounts of useful data, but it is fragmented across files, databases, cloud storage, documents, reports and internal systems. SKatalyst AI is an attempt to build the layer between that raw organizational data and the software people actually need.

Instead of beginning with an application and manually wiring data into it, SKatalyst begins with the organization’s existing information. It ingests it. Understands it. Structures it. Builds context around it. Then uses that structured understanding to generate useful applications.

Status
Private beta, Sep 2026
Role
Founder, product, architecture, engineering
Since
2025
SKatalyst AI recommending a SQL + Blob architecture at 95% confidence from a detected inventory of three tables, with a data transformation preview.

01 · The problem

The problem isn’t missing data.
It’s missing context.

Most organizations already hold the information they need. It just exists as separate files and rows, spread across drives, mailboxes, databases and tools that were never designed to explain each other.

A person understands the relationships implicitly: this spreadsheet belongs to that project, this report describes that test, that table holds the measurements, this document defines the process. Software normally sees none of it. SKatalyst attempts to reconstruct that missing organizational context, and to keep it.

  • “This spreadsheet belongs to this project.”
  • “This report describes this test.”
  • “This database table contains the measurements.”
  • “This document defines the process.”
Excel filesPDFsWord documentsSharePointGoogle DriveOneDriveDatabasesCloud storageDatabricksReportsImagesInternal toolsAPIsCSV exports
One structured layerOrganizational contextentities · relationships · lineage · definitions

02 · The idea

DataContextStructureApplication

The whole company in one line: the value is not the model. It is the persistent, validated understanding that sits between an organization’s data and the software built on it.

  1. 01Connect

    Bring organizational data in from where it already lives: uploads, drives, buckets and databases.

  2. 02Understand

    Scan read-only. Extract text and tables, OCR images, read schemas, metadata and relationships.

  3. 03Organize

    Propose a structure: entities, a schema, a folder taxonomy, quality findings and a recommended architecture.

  4. 04Store

    Persist the result in PostgreSQL so the understanding outlives any single AI conversation.

  5. 05Design

    Discover KPIs the data can actually compute and decide which modules expose them.

  6. 06Generate

    Build working application components: dashboard, CRUD, report, RAG chat, plus a database and API.

  7. 07Validate

    Compile a test oracle from the data model and compare generated behaviour against reference values.

  8. 08Operate

    Preview in an ephemeral runtime, export a Docker package the customer owns, verify, roll back if needed.

03 · How it works

From files to organizational context

SKatalyst is not built to upload files to a language model and ask questions. Each run turns input data, progressively and inspectably, into persistent structured context.

A read-only scan produces an inventory the user approves. A structuring plan proposes entities, a schema and a folder taxonomy. An architecture recommendation explains its confidence and what was excluded from the estimate. KPI discovery only offers metrics the data can compute. Every step is stored in PostgreSQL with lineage back to the source files, and the context a run used is frozen and hashed at start so it can be reconstructed later.

The LLM should not be the database.

The model interprets. The resulting understanding lives in structured, persistent tables, so organizational knowledge is not rebuilt from scratch on every prompt.
  1. 01Raw sources
  2. 02Ingestion
  3. 03Extraction
  4. 04Metadata
  5. 05Relationships
  6. 06Context analysis
  7. 07Structured entities
  8. 08Database
  9. 09Reusable organizational context
  10. 10Applications and AI
Structuring plan: recommended destinations with confidence, and a database schema proposal for customers, orders and products.
Visual preview of the proposed SQL + Blob architecture: an ER diagram for customers, orders and products, a folder structure and sample data.

04 · The intelligence layer

AI is part of the pipeline, not the whole pipeline.

SKatalyst combines deterministic software with AI reasoning, and keeps the boundary visible. The default platform provider is a deterministic heuristic; a model is added when a key is configured, and features that need one degrade to a non-AI path instead of failing.

Deterministic layer

Guaranteed by code, tests and the database.

  • Source connectors
  • OAuth and sessions
  • File handling and extraction
  • Schema inspection
  • Metadata extraction
  • Database operations
  • Tenant isolation
  • Roles and permissions
  • Migrations
  • Application runtime
  • Validation rules
  • Audit logging

AI reasoning layer

Where interpretation is genuinely required.

  • Classifying ambiguous documents
  • Finding semantic relationships
  • Proposing organization and context
  • Interpreting document content
  • Recommending an architecture
  • Proposing KPIs and modules
  • Generating application code
  • Explaining validation results

Software guarantees what can be guaranteed. AI handles what requires interpretation. Neither is assumed correct: proposals carry confidence, unavailable metrics are marked unavailable, and a human confirms before anything is built.

05 · System architecture

Seven layers, one direction of travel.

Verified against the platform’s source. Each layer only depends on the ones above it; validation sits between generation and delivery on purpose.

  1. 01

    Source layer

    • Local upload
    • Local folder agent (Go)
    • Google Drive
    • OneDrive
    • SharePoint
    • Dropbox
    • Amazon S3
    • Azure Blob
    • Databricks
    • PostgreSQL
    • MySQL
    • SQL Server

    12 source types. Cloud and database connectors read metadata today; execution stays Preview until proven against a real account.

  2. 02

    Ingestion and understanding

    • Read-only scan with timeouts and cancellation
    • 7 extractors: PDF, DOCX, XLSX, CSV, JSON, Markdown, text
    • OCR: Tesseract or Google Vision
    • Budgeted visual understanding for images
    • Inventory and data-quality findings
    • Context taxonomy scoring

    Every run starts with an inventory the user approves.

  3. 03

    Context and data layer

    • Reusable context library
    • Frozen context snapshots with SHA-256 hashes
    • Structuring plans and inventories
    • KPI discoveries with confidence scores
    • Lineage mappings from file to output
    • PostgreSQL 16, 51 migrations, about 80 tables

    The understanding is stored, versioned and traceable, not re-derived per prompt.

  4. 04

    Intelligence and orchestration

    • Run orchestrator: scan, merge, approve, plan
    • Architecture recommendation
    • KPI discovery
    • Design negotiation
    • Code generation
    • Claude provider plus a deterministic heuristic fallback

    Every AI step has a non-AI path or a BYOK gate; the platform never silently guesses.

  5. 05

    Application generation

    • Dashboard
    • CRUD application
    • Report
    • Chat / RAG (customer-keyed at runtime)
    • React + Express + Docker output
    • Schema provisioning and sample seeding

    4 generators shipping; 10 module types declared.

  6. 06

    Validation

    • Test oracle compiler
    • Reference executor
    • Behavioural probe runner
    • Tolerance-aware comparator
    • Validation report with provenance
    • Ephemeral, TTL-bounded runtime

    The oracle never reads generated code, so a generator error cannot hide itself.

  7. 07

    Delivery

    • Architecture, implementation and execution previews
    • Ephemeral preview runtime
    • Docker export with documentation and ownership files
    • Deployment verification and guided rollback
    • Managed hosting built, flag-off

    Export is blocked while validation is failed. That block is intentional.

Alongside the platform: a read-only local server agent written in Go (about 1,600 lines) for on-premise folders, with path allowlisting, pattern exclusions, a kill switch and a heartbeat. No writes, no telemetry.

Connectors

Meet the organization where its data already lives.

SKatalyst doesn’t require the organization to move everything into a new ecosystem before it can begin understanding the data.

Twelve source types are implemented, from local upload to Databricks. The labels below are the product’s own: a connector may not leave Preview until a real byte-read against a real external account has been proven and recorded. Connecting and browsing already work; local upload runs the full pipeline today.

  • Local UploadProduction
  • Local Folder AgentBeta
  • OneDrivePreview
  • SharePointPreview
  • Google DrivePreview
  • DropboxPreview
  • Amazon S3Preview
  • Azure Blob StoragePreview
  • DatabricksPreview
  • PostgreSQLPreview
  • MySQLPreview
  • SQL ServerPreview
Add Data: four connector families in the product, Upload Files, Cloud Storage (OneDrive, SharePoint, Google Drive), Databases (PostgreSQL, MySQL, SQL Server) and Servers & Data Lakes (Amazon S3, Azure Blob, Databricks), with a note that all processing happens locally and is logged.

06 · What it can build

Context becomes something people can use.

CRUD applications

Structured operational interfaces over the detected entities, with generated API endpoints for each.

Shipping

Dashboards

KPI cards and charts built only from metrics the data can compute; unavailable metrics are marked, never faked.

Shipping

Chat / RAG

Natural-language access grounded in the organizational context. Runtime keys stay with the customer.

Shipping

Reports

Structured reporting from the same context, exported with the application package.

Shipping

Prediction and analytics

Data-oriented analytical modules where the underlying data supports them.

Roadmap

API, automation, agent, workflow

Declared module types waiting for generators.

Roadmap
Suggested modules in the design step: Dashboard and CRUD App recommended with the evidence behind each recommendation, confidence, business value and detected KPIs or entities.
KPI discovery: the assistant proposes KPIs from three tables and five measurable columns, with a data summary and confidence score.

07 · Trust and validation

Generated isn’t the same as correct.

If AI is going to generate software from organizational data, generation cannot be the final step. SKatalyst treats validation as part of the architecture: expectations are compiled from the data understanding, never from the generated code, so a generator’s mistake cannot vouch for itself.

  1. Build
  2. Test
  3. Compare
  4. Explain
  5. Repair / Review

Compile the expectations

TestOracleCompiler

Turns the confirmed KPIs, entities, schema and business context into behavioural assertions. Pure and deterministic: no database, no network, no model, and never a line of generated code.

Compute what the answer should be

ReferenceExecutor

Evaluates each assertion against the ingestion-time sample snapshot: sums, counts, averages, minimums and maximums. Read-only; never opens a live connector.

Exercise the generated app

BehavioralProbeRunner

Boots the app in an isolated runtime seeded with the same sample and probes its endpoints, including negative tests that must be rejected.

Compare with tolerance

Comparator

Exact or relative comparison of observed versus reference values, so a rounding difference is not a failure and a wrong KPI is.

Explain the result

ValidationReportService

Every assertion carries provenance: which KPI, which table, which formula. The report is the evidence a human approves against.

Orchestrate and degrade safely

ValidationOrchestrator

Runs compile, reference, probe and persist; falls back to a reference-only report when the runtime is unavailable; always tears the runtime down.

5 assertion typesKPI value · entity CRUD · relationship integrity · schema shape · domain range
Negative testsAn orphan foreign key or a domain-violating write must be rejected by the generated app.
Anomalies before generationReference execution doubles as a check on the understanding itself: a broken expectation surfaces before any code exists.
Repair stays humanBounded auto-repair is designed but deliberately not built. Failures return to a person with the evidence, and export stays blocked while validation is failed.
Validation report: test oracle compiled from the data understanding, 100% KPI coverage (15 of 15), 100% entity coverage (3 of 3), behavioural validation panel.
Validation report detail: oracle provenance showing 15 KPIs and 3 tables consumed and generated code accessed: no, followed by the compiled KPI-value assertions with their expected formulas.

Human approval

Agentic doesn’t mean uncontrolled.

The system proposes; a person decides at the moments that matter. Two gates are distinct by design: approving a specification before anything is built, and accepting a preview after it is built.

  • Inventory approval before a structuring plan is generated.
  • Plan and architecture confirmation before KPIs are discovered.
  • Design approval before a build starts.
  • Preview acceptance, revision or rejection after the build, with a revision loop back to design.
  • Validation report as the evidence for that decision; export blocked while it fails.
  • Audit trail: every transition writes an event and an append-only audit row in the same transaction, or the transition rolls back.
  1. AI proposes
  2. Human reviews
  3. System builds
  4. System validates
  5. Human accepts

Solution lifecycle · 12 states

  1. draft
  2. designing
  3. awaiting approval
  4. approved
  5. building
  6. preview
  7. accepted
  8. revision requested
  9. rejected
  10. deployed
  11. operating
  12. archived

Highlighted states are the human gates. Transitions are an explicit table; illegal ones are refused, repeated ones are idempotent, and unarchiving never restarts a runtime.

08 · Product experience

One guided journey per run.

The in-app stepper tracks eight steps on every run page. Each step explains what the system knows, why it matters and the next best action, in the product’s own voice.

  1. 01Connect
  2. 02Context
  3. 03Understand
  4. 04Recommend
  5. 05Design
  6. 06Build
  7. 07Validate
  8. 08Deploy
Design step with the eight-step journey stepper at the top and the SKatalyst Architect panel: what I discovered, my recommendation, why this matters.
Data Sources page: current project selector, project overview counts for sources, runs, context items, destinations, blueprints and metrics.
Build summary: 6 data sources, 15 KPIs, 4 dashboard pages, 12 API endpoints, and a quality validation panel that blocks export while validation is failed, listing blocking issues, warnings and recommendations.
Data lineage and source evidence: stored mappings showing which files and datasets powered each generated table, KPI and widget, with confidence.
Deployment choice: deploy myself with full control, downloadable schemas and step-by-step instructions, or deploy with SKatalyst AI managed hosting.
Project Home with a getting-started checklist: create your project, connect your data, run AI analysis, review what the AI found, generate your blueprint.

09 · Engineering

Under the hood

Verified from the repository, organized by purpose. The platform is a Node and PostgreSQL system with a small, explicit AI surface.

Frontend

  • React 18
  • React Router 6
  • Tailwind CSS
  • i18next
  • react-dropzone
  • Mermaid diagrams
  • Jest + Testing Library (45 suites)

Backend

  • Node.js (ESM)
  • Express 4 with Helmet, rate limiting, CORS
  • Knex query builder + pg
  • Zod validation
  • BullMQ + Redis job queue
  • Multer, pdf-parse, mammoth, xlsx, sharp, ffmpeg

Data

  • PostgreSQL 16
  • 51 additive migrations, about 80 tables
  • Append-only audit log enforced by trigger
  • Context snapshots with SHA-256 integrity
  • Lineage mappings and run findings

Cloud

  • Google Cloud Run (europe-west1)
  • Cloud Build with git-SHA images
  • Firebase Hosting for the app
  • Cloud SQL for PostgreSQL
  • Docker export for customer self-hosting

Authentication

  • Google, Microsoft and GitHub OAuth
  • JWT access and refresh sessions
  • Verified-email account linking
  • 4 roles: owner, admin, member, viewer
  • Beta access gate

Integrations

  • Microsoft Graph (OneDrive, SharePoint)
  • Google Drive API, read-only scopes
  • Dropbox API
  • Databricks API
  • AWS S3 and Azure Blob SDKs
  • MySQL, SQL Server and PostgreSQL drivers

AI

  • Anthropic SDK (platform)
  • BYOK: Claude, OpenAI, Gemini
  • Deterministic heuristic provider as the default fallback
  • 8 runtime-AI options for generated chat apps
  • Tesseract and Google Vision OCR
  • Feature gating with fail-fast alternatives

Validation

  • Test oracle compiler
  • Reference executor
  • Behavioural probes with negative tests
  • Tolerance-aware comparator
  • Validation report with provenance
  • About 600 automated tests across 100+ files

Multi-tenant and security architecture

  • Tenant isolation at the database. A composite foreign key ties every solution to its project and tenant; a cross-tenant row is uninsertable, not merely filtered. A run from another tenant behaves exactly like a missing run, so the API cannot leak that an id exists.
  • Roles. Owner, admin, member and viewer, deny-by-default, with an explicit allowlist for read-only operations.
  • Append-only audit log. A database trigger rejects updates and deletes; services may never write credentials, tokens or file contents into it.
  • Encrypted credentials. Connector secrets and BYOK keys are AES-256-GCM encrypted with a required master key; the frontend only ever sees a fingerprint.
  • Hardening. Helmet, rate limiting backed by the database, schema validation, sanitized input, GDPR data-rights flows and a written retention policy.

The model is a component, not the product.

SKatalyst is not tied to one model provider. Tenants bring their own keys for Claude, OpenAI or Gemini; keys are encrypted at rest, decrypted only at execution, and one active key per provider is enforced. Generated chat applications use the customer’s own runtime provider, chosen at deploy time, never requested during design.

The value sits around the models: the context, the workflows, the structured data, the application architecture and the validation system.

Settings, LLM API keys: bring your own key for Anthropic Claude, OpenAI GPT and Google Gemini.
12
source types
10
solution module types
4
generators shipping
12
lifecycle states
2
human approval gates
5
assertion types
3
OAuth providers
4
tenant roles
3
BYOK model providers
51
database migrations
390+
API endpoints
~600
automated tests

All figures counted from the repository on 28 August 2026: 180 commits since June 2025. Endpoint count is a floor (391 in the main router plus 11 route modules).

10 · Evolution

From prototype to platform

  1. Seed

    Initial project structure.

  2. Data ingestion

    Document ingestion pipeline, LLM-assisted classification with a heuristic fallback and a vendor-neutral provider registry.

  3. Context understanding to generation

    Metrics model, blueprint generation and the first artifact export: from organizing data to generating software within days.

  4. Structured storage, tenancy, connectors

    Multi-tenant schema, OAuth, encrypted vault and BYOK, OCR and visual understanding, ten connector backends, immutable context snapshots, orchestrated runs and KPI discovery.

  5. Production-readiness audit

    A self-critical audit listed the gaps: beta gate, rate limiting, headers, validation library, unproven isolation. Most were closed in the following weeks.

  6. Behavioural validation

    The agentic validation loop was disclosed and built in increments: oracle compiler, reference execution with anomaly detection, behavioural probes. Patent package filed.

  7. Approval lifecycle

    The Solution entity with its 12-state machine, two distinct human gates and transactional audit events.

  8. Operational beta

    Landing admin, rate-limit counters, deploy and verify runbooks, onboarding, and the frozen authenticated app for the September 2026 beta.

Next

Two projects, one practice.