Orquestra - A Headless-API-ERP platform (AI-native)

Orquestra is a headless, API-first admissions ERP that treats workflows as programmable infrastructure which provides an AI-native solution, compliance compatibility, versioned workflows, etc.

Comment

Inspiration

Every institution, that is, a university, a hospital, an EdTech platform and all others eventually face the same problem: they need an operational system to run their processes, and the solutions available to them are built for the wrong era.

Legacy ERP platforms such as SAP, Oracle, and Ellucian dominate the institutional software market. They are expensive to license, years-long to implement, and structurally hostile to customization. Workflows are hardcoded into the product. Changing a single approval step in an admissions process can require a paid consultant engagement lasting months. Migrating away from these systems is even worse institutions are locked into codebases so large and tangled that the switching cost becomes existential. A mid-sized university looking to replace its ERP system faces migrations measured in crore-rupee investments, multi-year timelines, and significant institutional risk.

The deeper issue is structural. Traditional ERPs were designed as monolithic products, which is a model where a single vendor builds the UI, the workflow logic, the data model, and the integration layer all together, all tightly coupled. This was reasonable in 1995. In 2025, it means institutions cannot customize the system to match their actual processes. They have to modify their processes to match the system. This is backwards.

The market gap that Orquestra is built to fill is not "a better ERP." It is the absence of a programmable runtime layer beneath institutional operations, which is an infrastructure layer that institutions and their developers can build on top of, rather than a finished product they are forced to adopt wholesale. No funded company occupies this specific cell. General-purpose workflow orchestration platforms like Temporal and n8n are horizontal and developer-focused, with no institutional compliance layer. Vertical ERP platforms like Tailor ERP are headless but built for retail and manufacturing, with architectures incompatible with regulated institutional environments. The institutional verticals such as universities, hospitals, EdTech platforms operating under FERPA, GDPR, and India's DPDP Act are entirely unaddressed at the infrastructure layer.

The inspiration for Orquestra's long-term vision came partly from Figma's model. Figma did not build a better version of Photoshop. It built a design infrastructure layer that is, collaborative, programmable, extensible on top of which the entire design ecosystem rebuilt itself. The analogy for institutions is direct: rather than building a better university ERP, Orquestra builds the runtime infrastructure on top of which any institution can build their own ERP, customized to their exact processes, without starting from scratch. The scaling vision follows this logic beginning with EdTech and university workflows, then extending the same headless runtime to CRMs, Learning Management Systems, hospital patient flow systems, and government administrative workflows, creating a comprehensive institutional operating infrastructure. One programmable runtime. Every institutional domain.

What it does

Orquestra is a headless, API-first ERP runtime. It does not ship a user interface. It ships the programmable infrastructure layer beneath the interface which is the workflow engine, the event system, the compliance enforcer, and the AI compiler. The institutions and their developers build on top of.

The core interaction is this: a developer or institutional administrator describes a process in natural language. Orquestra's AI Structural Compiler, running across three distinct modes, takes that description and produces a validated, deployable workflow blueprint.

Mode A (Blueprint Generator) generates a structured state machine from a plain English description of a process: an admissions workflow, a procurement cycle, a patient onboarding sequence. The output is a typed JSON state machine with nodes, transitions, conditions, and compliance tags.

Mode B (ERP Architect) performs domain graph extraction with a given description of an institution and its operational domains. It produces a structured entity-relationship model that maps the institution's data architecture. This is the design layer before the workflow layer.

Mode C (Template Customizer) takes an existing workflow template and adapts it to a new institution's specific constraints and requirements.

Before any AI-generated blueprint can be deployed, it passes through a 4-stage validation pipeline:

$$\text{Schema Validation} \rightarrow \text{Graph Integrity (BFS + cycle detection)} \rightarrow \text{Permission Analysis} \rightarrow \text{Compliance Tagging}$$

Stage 1, validates structural correctness of the JSON output. Stage 2 runs a breadth-first traversal of the state machine graph to verify it is a valid directed acyclic graph in such a way that no circular dependencies, no unreachable states, no missing terminal nodes exist. Stage 3 analyses every workflow step against the requesting user's RBAC permissions. Stage 4 verifies that all fields touching regulated data (student records, health data, financial data) are correctly tagged under FERPA, GDPR, or DPDP as appropriate. A blueprint that fails any stage does not deploy. The failure message identifies the exact stage, the exact node, and the exact rule violated.

Transition conditions within deployed workflows are evaluated by a hand-written recursive descent parser not a general-purpose expression evaluator. The parser accepts only scalar comparisons and a single level of logical composition (AND/OR). eval() is never called. No arbitrary code executes against institutional data at any point. This is a deliberate, non-negotiable architectural constraint.

Deployed workflows are immutable. Changes do not modify an existing workflow rather they create a new versioned instance. Every state transition is written simultaneously to three systems in a triple-write event engine: PostgreSQL for durable persistence, Redis Streams for real-time processing, and WebSocket for live client broadcast. Redis failure never rolls back the Postgres write. Every transition in the system's history is permanently auditable.

The versioned API key system binds each key (sk_erp_v{n}) to a specific ArchitectureVersion snapshot. An institution's integration does not break when internal architecture changes, the key pins the exact version of the compiled domain graph against which the API was written.

Multi-tenant isolation is enforced at four independent layers: JWT claims scoping, HTTP header scoping, SQLAlchemy query scoping, and PostgreSQL Row-Level Security. A query from Institution A cannot access Institution B's data even if authentication is compromised at a higher layer.

How we built it

Backend - FastAPI + PostgreSQL + Redis

The entire server layer is built on FastAPI (Python), chosen for its async-first design, automatic OpenAPI schema generation, and dependency injection model that made multi-tenant middleware straightforward to implement. Every endpoint is scoped through a middleware chain that extracts institution_id and project_id from JWT claims and HTTP headers before any database query executes.

PostgreSQL is the system of record. The schema is designed around the multi-tenant isolation requirement and every table that contains institution-scoped data has institution_id as a non-nullable indexed column, and PostgreSQL Row-Level Security policies enforce this at the database layer, independent of application-level checks. This means even a compromised application query cannot return cross-tenant data.

Redis serves two distinct roles. As a Pub/Sub and Streams backend, it carries real-time state transition events from the WorkflowEngine to connected WebSocket clients. As a cache, it stores AI provider outputs with a 24-hour TTL, thereby preventing redundant LLM calls for identical workflow generation requests across institutions.

The WorkflowEngine

The WorkflowEngine is a deterministic state machine executor. A deployed workflow is a JSON-encoded directed graph: nodes are states, edges are transitions, edges carry typed conditions. On receiving a transition trigger, the engine:

  1. Loads the current workflow state from PostgreSQL
  2. Evaluates the transition condition via the safe condition parser
  3. If the condition passes, writes the new state to Postgres, publishes the transition event to Redis Streams, and broadcasts it over WebSocket — the triple write
  4. If any write fails, the engine retries with exponential backoff; Redis failure is logged but does not roll back the Postgres write The engine includes deadlock detection: if a workflow reaches a state with no valid outgoing transitions and no terminal designation, it flags the workflow as stuck and raises an alert event.

The Safe Condition Parser

The condition parser is a hand-written recursive descent parser implemented entirely in Python without using eval(), exec(), or any dynamic code execution mechanism. The grammar it accepts is deliberately constrained:

$$\text{expr} ::= \text{comparison} \mid \text{expr} \; \texttt{AND} \; \text{expr} \mid \text{expr} \; \texttt{OR} \; \text{expr}$$

$$\text{comparison} ::= \text{field} \; \text{op} \; \text{value}$$

$$\text{op} ::= \texttt{==} \mid \texttt{!=} \mid \texttt{>} \mid \texttt{<} \mid \texttt{>=} \mid \texttt{<=}$$

Fields are resolved against the workflow's current data context at evaluation time. Function calls are not in the grammar. Nested logical expressions beyond one level are not in the grammar. This is enforced at the parser level, not by runtime validation, but a condition that attempts to call a function or reference an undeclared field fails at parse time, before the workflow is deployed.

The three AI modes (Blueprint Generator, ERP Architect, Template Customizer) use distinct system prompts, output schemas, and validation strategies. Mode A output must conform to the workflow blueprint JSON schema. Mode B output must conform to the domain graph schema. Both are validated by the 4-stage pipeline before storage.

The 4-Stage Validation Pipeline

Each stage is a Python class implementing a validate(blueprint) -> ValidationResult interface:

  • SchemaValidator: Pydantic model validation against the workflow JSON schema
  • GraphIntegrityValidator: BFS traversal from the designated initial state, cycle detection via visited-set tracking, reachability check for all declared states
  • PermissionAnalyzer: Cross-references each workflow step's required permissions against the deploying user's RBAC role assignments
  • ComplianceTagVerifier: Checks every field in the workflow's data context against a registry of compliance-tagged field names (FERPA, GDPR, DPDP); untagged fields touching regulated data fail this stage Stages run sequentially. The first failure short-circuits the pipeline and returns a structured error with the failing stage, the failing node or field, and the specific rule violated.

Versioned API Keys and Architecture Compilation

When an institution finalises their domain architecture in Mode B, the system compiles it: a snapshot of the ArchitectureVersion is frozen and a versioned API key (sk_erp_v{n}) is issued and cryptographically bound to that snapshot. Subsequent API calls authenticated with that key are evaluated against the frozen schema and not the current live schema. This means breaking architecture changes never silently invalidate existing integrations. A developer can migrate to sk_erp_v2 on their schedule, with full knowledge of what changed between versions.

Frontend — Next.js Launch Console

The launch console is built in Next.js with TypeScript. It exposes the full Orquestra runtime to non-developer institutional users through four primary interfaces: the Workflow Builder (visual state machine editor backed by the AI compiler), the Architect Page (domain graph visualisation from Mode B output), the UI Mockup layer (a preview environment for the institution's eventual interface), and the Templates Library (pre-built workflow blueprints across institutional domains). The launch console is openly accessible, and also with Demo booking options. A developer can build and deploy a workflow without speaking to anyone, but to deploy it they would need to purchase the API key.

Challenges we ran into

Scoping to survive

The single hardest challenge was not technical, rather it was deciding what to build first. Orquestra's full vision spans every institutional domain: universities, hospitals, EdTech platforms, government agencies, NGOs. Building for all of them simultaneously would have produced nothing deployable. The decision, early and difficult, was to constrain the initial prototype to a single module: EdTech and educational ERP workflows with specifically admissions, course lifecycle management, and academic grievance processes in consideration.

This constraint was imposed by resources, not by vision. A single developer, working with API credits, a hosted PostgreSQL instance, and a Redis tier, cannot validate multi-domain compliance logic simultaneously. Limiting to the EdTech domain meant the compliance tag registry could be built around FERPA and DPDP specifically, the workflow templates could be seeded with real institutional use cases, and the AI mode prompts could be optimised for educational process vocabulary. The prototype worked. A more ambitious scope would not have.

The constraint also produced an unexpected benefit: building deeply for one domain before scaling to others enforced architectural discipline. Every design decision had to be made in a way that would survive generalisation. The multi-tenant isolation model had to work for hospitals as well as universities, even though hospitals weren't in scope yet. The compliance tag system had to be extensible to HIPAA, not just FERPA. Scoping the prototype didn't mean scoping the architecture.

The safe condition parser - correctness over convenience

The decision to write a hand-built recursive descent parser instead of using Python's eval() took considerably longer than the alternative and produced more complex code. The correctness argument is unambiguous and eval() near institutional data in a regulated environment is indefensible, but the implementation challenge was real. The parser had to handle edge cases in field resolution (dotted path notation, null-safe access), type coercion in comparisons (string vs numeric, date handling), and meaningful error messages that a non-developer institutional user could interpret. A generic syntax error at position 14 is not a useful message. "Field applicant.age is not declared in this workflow's data context" is.

The parser went through four complete rewrites before it was correct, well-tested, and produced errors that the UI could surface intelligibly.

The triple-write event engine and Redis failure tolerance

Designing the event engine to treat Redis as non-critical, meaning a Redis failure should not roll back a committed Postgres write. This required careful thinking about the downstream consequences. If a state transition commits to Postgres but fails to publish to Redis Streams, connected WebSocket clients do not receive the live update. The workflow state is correct; the real-time broadcast is missing. The solution was a reconciliation layer: on reconnect, the WebSocket client requests a diff of all events since its last known event ID, and Postgres replays the missing transitions. This meant the event log schema had to be append-only with monotonic event IDs from the start, a constraint that shaped the entire data model.

Horizontal scaling: the WebSocket bottleneck

The current WebSocket Hub is in-process. In a horizontally scaled deployment, multiple FastAPI instances behind a load balancer and a transition event published by Instance A, cannot reach a WebSocket client connected to Instance B. This is a known architectural gap. The solution requires replacing the in-process hub with a Redis Pub/Sub broadcast layer, where every instance subscribes to the same Redis channel and relays relevant events to its local WebSocket connections. This is on the roadmap but was not implemented in the prototype. This is a constraint of scope, not of understanding.

Accomplishments that we're proud of

The safe condition parser exists and works. There is no open-source reference implementation of a safe, no-eval, grammar-constrained condition evaluator for institutional workflow engines. The one in Orquestra was built from first principles and handles the full range of institutional workflow conditions in production. Any developer building a system where AI-generated logic might execute against regulated data can take this pattern and use it.

The 4-stage validation pipeline is the gate that AI-native ERP has needed and nobody has built. Rillet's Aura Flows generates AI workflows that reach the general ledger. Tailor ERP allows serverless JavaScript inside workflow pipelines. Neither has a formal, multi-stage pre-deployment safety gate equivalent to Orquestra's. The pipeline — schema integrity, graph correctness, permission analysis, compliance tagging — runs before a human can even choose to deploy. It is infrastructure-level safety, not a UI warning.

Immutable versioned workflows with the versioned API key system mean Orquestra is the first ERP runtime where a breaking architecture change cannot silently invalidate an integration. The sk_erp_v{n} binding to a frozen ArchitectureVersion snapshot is an idea borrowed from the best practices of API versioning in payments infrastructure (Stripe's versioned API keys are the reference) and applied to the ERP domain where it has never existed.

The AI provider cascade with Redis caching means Orquestra is not brittle against single-provider API failures, rate limits, or pricing changes. The fallback chain ensures availability. The Redis cache ensures cost efficiency enabling identical generation requests across institutions share cached outputs. No other ERP platform has this architecture.

The launch console is openly accessible. No demo booking, although demo booking provided as an option for firms, institutions for formal processing. No enterprise sales cycle before a developer can build a workflow. This is the right distribution model for infrastructure software, and it was a deliberate choice against the industry norm.

Multi-tenant isolation at four independent layers. JWT → header → query → PostgreSQL RLS. Each layer is independently sufficient to prevent cross-tenant data access. The defence-in-depth model means a compromise at any single layer does not breach isolation. This is the architecture a hospital ERP or university admissions system requires, and it was built into Orquestra from the first migration.

What we learned

Constraints sharpen design

Constraining the prototype to a single module was not just a resource decision but also it was a design methodology. Every generalisation that looked obvious at the architecture level had to be proven necessary by a concrete use case in the EdTech domain before it was built. The compliance tag system exists because EdTech workflows touch FERPA-regulated student data. The graph integrity validator exists because a real admissions workflow submitted during testing had a circular dependency between the document verification and eligibility check states. The parser's null-safe field resolution exists because real workflow conditions reference fields that may not be present in all context objects. Constraints produce features.

The headless model changes the distribution question

A change from the traditional monolith ERP model for such a large scale is difficult. A developer who integrates Orquestra's API into their institution's existing portal does not need to sell their institution on adopting a new interface. They adopt the runtime invisibly, beneath a surface the institution already owns. This makes adoption frictionless in a way that no traditional ERP can match. The learning is that the right model for institutional infrastructure software is closer to Stripe than to Salesforce: the API is the product, and the developer champion who builds on top of it is the distribution channel.

What's next for Orquestra - A Headless-API-ERP platform (AI-native)

he prototype proves the core thesis: an AI-native, headless, compliance-aware workflow runtime can be built, deployed, and used by real institutions. The next phase is expansion across three axes simultaneously.

MCP Server - making Orquestra AI-agent-accessible

The most immediate next step is publishing Orquestra as a Model Context Protocol (MCP) server , thereby exposing the core runtime operations (deploy workflow, trigger transition, query event log, list templates, get workflow state) as structured tools that AI agents like Claude Code, GitHub Copilot, and Cursor can invoke programmatically. This transforms Orquestra from a platform developers build on top of into a platform that AI agents can operate on behalf of institutions. A CFO asking Claude to "show me all stuck admissions workflows from this week" should receive a live answer directly from the Orquestra runtime, without a developer writing a query. The MCP server is the distribution channel that puts Orquestra in front of every institution already using AI development tools.

RAFT-powered generation quality

The ComplianceGraph and WorkflowRAG projects currently in development - LangGraph multi-agent systems with pgvector backends are the first step toward the RAFT model described above. ComplianceGraph embeds institutional policy documents (FERPA, GDPR, DPDP, UGC guidelines) into a vector store and validates workflow blueprints against retrieved compliance rules, replacing Orquestra's static tag registry with a live, queryable compliance knowledge base. WorkflowRAG retrieves semantically relevant workflow templates from a community-maintained vector store, enabling institutions to find and adapt existing blueprints rather than generating from scratch. Together, these form the retrieval half of RAFT. The fine-tuning half follows as the blueprint dataset grows.

The productivity target is explicit: the same order-of-magnitude improvement that Figma brought to design tooling and that Coderabbit brought to code review, applied to institutional workflow design. An institutional administrator who currently spends weeks describing their process to a consultant, who then spends months configuring a legacy ERP, should be able to describe their process in natural language, review a generated blueprint in hours, and deploy a running workflow by the end of the day.

Domain expansion - CRM, LMS, hospital workflows

The EdTech module is the proof of concept. The architecture was designed from the beginning to be domain-agnostic. The next modules in development:

  • Institutional CRM — alumni relations, donor management, student engagement workflows for universities and EdTech platforms
  • Learning Management System integration — course lifecycle management, assessment workflows, certification issuance, connecting Orquestra's workflow runtime to existing LMS platforms via API
  • Hospital patient flow — patient intake, triage, department assignment, discharge workflows with HIPAA compliance tagging
  • Government administrative workflows — grant disbursement, permit processing, public grievance redressal for municipal and state government bodies Each domain module adds to the template library, expands the compliance tag registry, and contributes to the RAFT training dataset. The flywheel is compounding: more institutional domains → more workflow data → better RAFT model → better generation quality → faster institutional adoption → more institutional domains.

SDK generation and open-source community

The roadmap includes auto-generated SDKs , typed client libraries in Python, TypeScript, and Java generated from the compiled ArchitectureVersion schema. An institution's developers get a type-safe client that matches their specific domain model, auto-updated when they migrate to a new architecture version. Alongside this, the erp-ai-primitives open-source repository publishing the pattern library, prompt library, MCP server toolkit, and reference implementations as standalone reusable modules creates the community contribution layer. Developers building institutional software anywhere can adopt Orquestra's patterns without adopting Orquestra itself. Every contribution back to the pattern library makes the hosted platform more capable.

The vision is a platform where the open-source community builds the breadth, the hosted runtime provides the depth, and the RAFT model makes the whole system progressively more intelligent with every workflow that passes through it. Infrastructure for every institution. Open by design.

It's important to note that i have used Stitch API of google to generate better UI mockup designs of the ERP that the user desires to generate

Built With

Share this project:

Updates