Orquestra Infrastructure PreviewRead Product Model
Manual · Architect

The Architect Page

Architect is where you compose your deployed workflows into a coherent ERP domain structure and compile it into a versioned, production-ready API. Think of it as the layer above individual workflows — the place where you design how your institution's systems connect.

Where Architect Fits

The Orquestra product flow is linear:

1. Build Workflows → 2. Design in Architect → 3. Compile → 4. Call Runtime API
  • Workflows define individual processes (admissions, payroll, HR onboarding).
  • Architect groups those workflows into domains and describes how they relate.
  • Compiling produces a versioned API key and webhook secret that grant access to the Runtime API.
  • The Runtime API is what your application actually calls to submit and track applications.

Getting to the Architect Page

Navigate to Architect in the Console left sidebar, or click Deploy & Continueon the Workflow Canvas — that button deploys your workflow and takes you straight to Architect. You will always land on the same architecture for your current project; Orquestra auto-creates one if it doesn't exist yet.

Page Layout

Domain Cards Grid

The main body of the page. Each card represents an ERP domain (e.g., Admissions, Finance, Human Resources). Domains are generated by the AI when you describe your institution in the NLP prompt bar. Each card shows the domain name, linked workflow (if any), and a button to link a deployed workflow to that domain.

NLP Prompt Bar

The text input at the top of the page. Type a natural language description of what you want to add or change in your ERP structure. The AI interprets your intent and applies the corresponding operation to the domain graph — adding domains, renaming them, removing them, or restructuring how they relate. Each prompt is versioned in the history panel.

Compile Panel

The right-side or bottom panel that appears when you are ready to compile. You select which deployed workflows to include, give the API key a name, and click Compile. The result is a versioned architecture snapshot with a one-time-visible API key and webhook secret.

Version History

Every compile creates a new architecture version (v1, v2, v3…). The version history panel shows all past compilations with their timestamps. Old versions remain valid — their API keys continue to work until you explicitly revoke them in the API Keys section.

Using the NLP Prompt Bar

The prompt bar is the primary way to build your domain graph. Type a description of the change you want, press Apply, and the AI updates the architecture graph accordingly. You do not need to know any specific syntax — plain English works.

Example Prompts

Add admissions and financial aid domains
Include HR onboarding and payroll processing sections
Remove the procurement domain
Rename 'student_affairs' to 'student_success'
Add a research grants domain with a compliance link to admissions

Each prompt result records:

  • The operation applied (add_domain, remove_domain, rename, etc.)
  • The AI's rationale — the reasoning behind the structural decision
  • A diff summary describing what changed relative to the previous version
  • The intent classification (the AI's interpretation of your instruction)
Redirect intent: If your prompt sounds more like a workflow creation request (e.g., "add a scholarship review process"), the AI will classify it as a redirect and suggest you build a workflow first. Follow the suggestion link to return to the Workflow Canvas, then come back to Architect after deploying.

Domain Cards

Each domain card represents a functional area of your institution's ERP. Domains are structural labels — they have no logic of their own. Their purpose is to:

  • Organise deployed workflows into meaningful categories
  • Define the scope of what gets compiled into a given architecture version
  • Appear in the architecture visualisation so stakeholders can understand the system at a glance

Linking a Workflow to a Domain

Each domain card has a Link Workflow button. Click it to open a dropdown of all deployed workflows in your project. Select the workflow that belongs to this domain. A domain can be linked to one workflow; one workflow can be linked to multiple domains if needed (e.g., a shared review process used by Admissions and Financial Aid).

Only deployed workflows appear in the list. If a workflow you built does not appear, go back to Workflows and deploy it first.

Compiling an Architecture Version

When you are satisfied with your domain structure and have linked all the workflows you want to expose, click Compile. This action:

Creates an Architecture Version snapshot

The current state of the domain graph is frozen into an immutable version record (v1, v2, etc.).

Links workflows at their current version

Each selected workflow is pinned at its current deployed version. If you later update a workflow (creating v2), the architecture version still points at v1 until you recompile.

Generates a versioned API key

A unique key in the format sk_erp_v{n}_{random} is generated. It is shown once — copy it immediately and store it securely. Only the SHA-256 hash is stored in the database.

Generates a webhook secret

A webhook signing secret in the format whsec_erp_{random} is also generated once. Used to verify event payloads sent to your endpoints.

Emits an architecture.compiled event

Recorded in the event stream so you have an audit trail of every compile.

API key and webhook secret are shown exactly once. After you close or navigate away from the compile result, neither the raw key nor the raw secret can be retrieved again. If you lose them, compile again to generate a new version with fresh credentials.

Using the API Key

The compiled API key authenticates calls to the Runtime API at /api/v1/. Pass it as a Bearer token:

POST /api/v1/applications
Authorization: Bearer sk_erp_v1_abc123...
Content-Type: application/json
{
"workflow_id": "wf_xyz...",
"applicant_data": { "score": 85, "name": "Alice" }
}

The key grants access to all workflows linked in the architecture version it was compiled from. Attempting to submit to a workflow not included in that version returns a 403 Forbidden.

The key has no expiry by default. You can revoke it at any time from the API Keys section in the Console sidebar.

Version History

Every compile produces a new architecture version. Versions are additive — they do not invalidate previous ones. This means:

  • v1 keys continue to work after you compile v2.
  • Applications submitted through v1 workflows remain on v1 definitions.
  • You can roll back by reverting to the credentials from an older version.
  • Each version shows a graph snapshot of the domain structure at compile time.

To deprecate old versions, revoke their API keys from the API Keys management page. Once a key is revoked, any call using it returns 401 Unauthorized.

Architect vs Workflows — Key Differences

AspectWorkflowsArchitect
What it definesIndividual process logic (states, transitions, conditions)How processes relate as an institutional ERP system
AI modeMode A — Blueprint GeneratorMode B — ERP Domain Composer
OutputVersioned workflow definition JSONArchitecture version + API key + webhook secret
ImmutabilityDeployed workflows are immutableEach compile creates a new immutable version
Runtime impactDirect — execution engine runs workflow statesIndirect — determines which workflows the API key can access
Who edits itDeveloper / process designerSystem architect / technical lead

Common Patterns

Starting fresh with a new project

  1. Open Architect → type a prompt like "I need admissions, financial aid, and HR domains"
  2. Three domain cards appear. Go build a workflow for each.
  3. Return to Architect, link each workflow to its domain.
  4. Compile → copy credentials → start calling the Runtime API.

Adding a new workflow to an existing architecture

  1. Build and deploy the new workflow on the Workflow Canvas.
  2. Return to Architect → add a domain card for the new process.
  3. Link the new workflow to the new domain.
  4. Compile → a new version (e.g., v3) is created with all previous workflows plus the new one.
  5. Update your application to use the new API key for v3.

Updating a workflow (new version)

  1. Make a new workflow with the same name → it gets version 2.
  2. In Architect, unlink the domain from v1 and link it to v2.
  3. Compile → the new architecture version pins workflows at their current version.
  4. Applications running on v1 continue unaffected; new applications use v2.

Best Practices

  • Build at least one workflow before opening Architect — the page shows available workflows when linking domains, and an empty list means nothing is available to compile.
  • Name domains with consistent terminology that matches your institution's language — these names appear in the API and event payloads.
  • Compile only when workflows are stable. Each compile uses a credential slot, and while old keys keep working, accumulating many versions adds management overhead.
  • Store API keys in environment variables or a secrets manager immediately after copying. Never commit them to source control.
  • Use the version history to understand your architecture's evolution. If something breaks after a compile, the previous version's credentials will still work as a rollback.
  • Check the Console Event Stream after compiling — the architecture.compiled event confirms the operation was recorded successfully.