Catalyst Release Notes

Catalyst v0.1 — July 31, 2026

Product: Catalyst — Enterprise AI Operating System · Version: 0.1 · Release type: Initial release

---

1. Summary

Catalyst v0.1 is the first release of Polyrific's enterprise AI operating system. It provides a per-tenant runtime that sits between an enterprise's data estate and the lightweight inference applications its people use. Applications declare what they need; the Catalyst Runtime decides how to satisfy it — which data source to read, which model to route to, which policies to apply, and what to record. Applications never access enterprise data directly.

This release delivers the Catalyst Runtime and its five subsystems, the Catalyst Studio authoring environment, the Inference Interface and Admin Portal, an external integration API for applications built outside Studio, and the multi-tenant deployment pipeline.

Every operation flows through a Work Order, which is persisted, policy-checked, cost-attributed, and reconstructable from its audit trail.

---

2. Scope

Included

• Catalyst Runtime — Institutional Memory Manager, Agent Manager, Model Intelligence Manager, Governance & Trust, and Observability.
• Catalyst Studio, Inference Interface, and Admin Portal.
• Runtime Gateway — authentication, authorisation, rate limiting, and streaming.
• Central services — model intelligence, application catalogue, component library, tenant management.
• External integration API and the client component library.
• Container build, deployment automation, and tenant provisioning.

Not included

• Compatibility guarantees for internal interfaces between releases prior to v1.0.

---

3. Capabilities delivered

Work Order execution

The Work Order is the single interface between applications and the Runtime. Each is persisted with a defined state machine and emits an event on every transition. Five execution modes are available: single-agent execution, multi-agent workflow, data source query, data mutation, and custom business logic in a sandbox.

Supporting capabilities include natural-language intent classification to select the execution mode, request deduplication, asynchronous submission with event streaming and a polling fallback, reusable versioned templates, execution-plan caching, pagination, scheduled recurring operations, and webhook delivery on completion.

Model intelligence

Provider-agnostic model routing with automatic failover across major commercial providers for text, image, and speech generation. Capability scoring routes each request to an appropriate model; fallback chains retry across providers on error or unavailability; a circuit breaker tracks provider health. Cost is tracked per tenant, per application, and per user. Tenants may supply their own provider keys.

Customers do not manage models. Model evaluation and health monitoring are performed centrally on their behalf.

Agent orchestration

Agents are defined as versioned blueprints with lifecycle stages from draft through production. Three multi-agent execution strategies are supported: sequential, parallel, and orchestrated through a shared blackboard. A central tool registry governs which tools an agent may invoke, enforced as a strict per-blueprint allowlist. Agents hold no state of their own — shared state lives on the blackboard.

Institutional memory

Per-tenant memory and knowledge layer providing a hybrid vector and relational knowledge store, an entity graph with deduplication and community detection, conversation-scoped working memory, and unified retrieval with source citation, provenance, and chain-of-custody evidence.

An observation agent captures instructions, corrections, vocabulary, and methods from completed work and writes provenance-tagged insights back into the knowledge layer. Insight curation, confidence scoring, and lifecycle status are administrator-controlled. The memory layer can be disabled per tenant.

Governance and trust

A policy engine evaluated at three checkpoints — before execution, during execution, and before a response returns to the user. Policies support allow, deny, redaction, escalation, and alert outcomes over caller roles, groups, resources, and data references. Content rules provide personally-identifiable-information detection by category and content filtering.

Human-in-the-loop escalation uses a durable queue with timeout handling, checkpoint snapshots for pause and resume across all orchestration strategies, resumption with modifications, withdrawal, and outcome notification. Administrators have an assisted policy builder, a policy test harness, a decision log showing which policy fired and why, deduplicated alerts with resolution tracking, and a tenant-wide kill switch.

Observability

An event layer captures work order state changes, agent reasoning and tool calls, connector operations, governance decisions, knowledge operations, and system health, with real-time streaming to operator surfaces. The platform records model usage and billed cost attributed to the responsible user and application, provides spend reporting and cost controls, monitors long-running operations, and detects and cleans up orphaned executions.

Data access

All data access is mediated by a central gateway; applications and agents never hold credentials or issue queries directly. Connectors are available for major relational databases, document databases, cloud data platforms, object storage, generic REST services, common SaaS business systems, and Model Context Protocol tool sources.

Supporting capabilities include data contracts with field validation, row-level security and transformation; file upload with schema inference and chunking; document intelligence with optical character recognition; streaming ingest for large files; computed and derived data with refresh schedules; query pushdown; and autonomous source discovery under budget control with an audit log.

Catalyst Studio

The AI-first authoring environment for inference applications. A living specification captures the problem, the application design, the component blueprint, supporting documents, and a decision log, with a readiness checklist gating the build. Uploaded documents are classified automatically and requirements extracted from them.

The build pipeline uses coordinated agents for scaffolding, screen construction, review, and repair, with quality gates covering compilation, semantic consistency, and automated testing, and bounded review cycles. Progress is tracked on a kanban board that agents advance as work completes.

Additional capabilities: natural-language work order creation with schema traversal, an application wiring map projecting the user interface against backend operations and data sources, live preview, a source editor, version control integration, export and import, version history, application sharing, and a conversational assistant available across surfaces.

Inference Interface and Admin Portal

The user-facing portal hosts published applications under the tenant's own branding. The Admin Portal, which lives inside it, provides configuration and operations for data sources and connectors, agents, workflows, policies and the escalation queue, models and provider keys, the knowledge layer, access control and user management, monitoring, spend reporting, notifications, and channels.

External integration

Applications built outside Studio integrate through a documented, versioned API with a published OpenAPI specification, covering application registration, the data model, the full work order lifecycle, and deliverable retrieval, together with administration of API clients and keys.

An API key is validated at the perimeter and exchanged for the same identity a user session produces, so governance, tenant scoping, cost attribution, and observability are identical on both paths. Keys are never forwarded beyond the perimeter. A versioned client component library is provided for application developers, alongside a protocol guide, worked examples, and a quick-start guide.

---

4. Security and access control

Control	Implementation
Authentication	Enterprise identity provider integration using OIDC with asymmetric token signing.
Authorisation	Role-based access control over a fixed role set, enforced at the gateway on every request.
Resource scoping	User groups, resource groups, and administrator-defined access tags scope data sources, connectors, and knowledge. Work order execution honours these assignments.
Tenant isolation	Each tenant is a dedicated deployment with its own database and its own memory layer. Tenant identity is verified on every operation.
Data residency	Customer data remains within the customer's environment. Connectors are managed by the Runtime and read in place.
API credentials	Scoped keys for external clients, with disable, revoke, and rotate operations.
Code execution	Custom business logic and generated code run in an isolated sandbox with resource limits and static pre-analysis.
Sensitive data	Personally identifiable information is detected by category and redacted before content reaches model context.
Secrets	Managed through a secret manager; no credentials are held in source. Provider keys are stored per tenant.
Audit logging	Data access is recorded with user attribution. Work order execution is reconstructable from the event record.
Transport	Encrypted transport only, with enforced security header policies.
Dependency monitoring	Automated vulnerability alerting is enabled on the codebase, with alerts triaged and remediated on a defined cadence.

---

5. Verification performed

Activity	Detail
Automated testing	A unit and integration test suite runs on every proposed change.
End-to-end testing	Browser-driven tests cover authentication, work order execution and streaming, connector connection flows, governance enforcement, application build and publish, and application sharing.
Build verification	A full build of the platform runs on every proposed change and must pass before merge.
Database verification	The full schema migration set is applied against the production database version on every proposed change, to catch version-incompatible changes before merge.
Coverage measurement	Per-component coverage minimums are recorded and evaluated on demand. Reporting is advisory.
Automated code review	An automated reviewer inspects every proposed change when it is opened for review.
Manual verification	Changes affecting the user interface require visual evidence attached to the change record. Governance enforcement is additionally verified through a scripted demonstration against a live environment.
Security validation	The execution sandbox has been tested against adversarial input, including injection and prototype pollution.

---

6. Change control

All changes reaching the release branch pass through an enforced review workflow.

Control	Configuration
Protected release branch	Enforced by repository policy since January 2026.
Review requirement	Peer approval required before merge.
Required automated checks	Build and test verification must pass before merge.
History protection	Branch deletion and non-fast-forward (force) pushes are blocked.
Direct commits	Prohibited. All work is branched and merged through a reviewed change request.
Change request template	Requires a summary, acceptance criteria, and where applicable a test plan and a risk and security assessment.
Traceability	Every change is linked to a tracked issue, referenced in the branch, commit history, and change request.
Attribution	Changes are attributed to the individual engineer responsible.

---

7. Deployment and rollback

Build. Application code merged to the release branch produces an immutable container image, identified by a build number and by the specific revision it was built from. That revision-pinned identifier is what deployment and rollback reference.

Deploy. Deployment runs through an automated pipeline gated on an authorisation check, applying a versioned deployment configuration held separately from application source. Tenant provisioning, including per-tenant credential generation, is automated. Self-hosted installation is supported. Secrets are supplied at deployment time and are never held in source.

Database. Schema migrations are applied as part of the release procedure, before the new version serves traffic.

Rollback. The application layer is rolled back by redeploying the previously released image. Because images are immutable and revision-pinned, the prior version is always recoverable.

Schema migrations are applied forward as part of a release. Each declares a reverse path, but rolling the application back across a release that changed the schema requires that reversal to be performed deliberately as a separate, reviewed step — application rollback alone does not revert schema changes. Releases containing destructive schema changes are treated as forward-only and remediated by a follow-up release.