The orchestration engine
for IT operations.
Deterministic runbook engine. LLM confined to intent classification, air-gapped from execution. 13 production runbooks ship Day 1; the custom layer is yours to extend.
The differentiator is the architecture, not the AI.
13
Production runbooks live
Verify →9
Enterprise systems integrated
Verify →5+
Systems orchestrated per workflow
100%
Human-approval gated
Verify →01 · Architecture
Not an LLM wrapper. An orchestration engine.
Most enterprise-AI products in our category are sophisticated chat interfaces over a language model. We're built the other way around: deterministic runbooks are the product, and the LLM is one bounded layer of the interface.
Chat → model → response
- 01User asks a question in chat
- 02LLM produces a response
- 03If lucky, the response is correct
The moat is the prompt and which foundation model you pay for. When the model gets better, every competitor catches up the same week.
Chat → classified intent → deterministic runbook → audit chain
- 01User submits request in Slack or Teams
- 02LLM classifies intent into a runbook ID: no execution access, no credentials, no PII beyond routing
- 03Deterministic TypeScript runbook proposes the action against your systems
- 04Admin approves via interactive card (Slack Block Kit / Teams Adaptive Card)
- 05Runbook executes; result appended to SHA-256 tamper-evident audit chain
The moat is the runbook library and the governance architecture.Even if every foundation model became equivalent tomorrow, the depth (13 purpose-built runbooks orchestrating 9 enterprise systems with full audit chain) doesn't commoditize.
02 · Execution pipeline
Every action runs through a three-stage safety pipeline.
Simulate → Validate → Execute. No runbook reaches a production system without passing all three.
Simulate Stage
Every runbook executes against a sandbox layer first. Real customer integrations (Okta, Entra, Jira, M365) route through process-scoped sandbox stubs that return realistic responses without touching production. Verified in `src/lib/automation/sandbox-context.ts`.
03 · Out of the box
13 production runbooks. Live today.
Each runbook is hand-built TypeScript orchestrating real customer integrations: not generated, not templated, not "coming soon." Status verifiable at /runbooks.
Identity & authentication
Access & membership
Lifecycle
Workspace provisioning
04 · Orchestration depth
One approval. Multiple systems. Audit-chained end to end.
The difference between "more integrations" and "deeper integrations". A single AscendCore runbook sequences across 4-5 enterprise systems with continue-on-failure semantics and structured outcome capture per step.
RB-008 · Access Role Change
Promote a Tier-1 engineer to Tier-2 across 4 systems in one approval.
- 1Okta · remove `support-tier-1` group · add `support-tier-2` group
- 2Entra · remove tier-1 group · add tier-2 group (JIT-eligible)
- 3Jira · transition project-role from `support-tier-1` to `support-tier-2`
- 4M365 · transition license tier where applicable
One approval card. One audit-chained execution. Four systems sequenced with continue-on-failure semantics and structured outcome capture per step.
RB-011 · Employee Offboarding
Sequenced de-provisioning across 5 systems with a single approval.
- 1Entra · revoke active sessions (immediate sign-out across M365)
- 2M365 · revoke assigned license
- 3Entra · remove from all role-based groups (full enumeration)
- 4Okta · deprovision SSO assignment
- 5Optional Jira / Confluence · remove project-role and space access
Workforce changes that take an L1 engineer 20+ minutes of click-through happen in one approval card with the full audit chain attached.
RB-003 · New Hire Provisioning
Spin up a new employee across 5 systems with optional Day-1 access bundles.
- 1Entra · create user with role-based group memberships
- 2Okta · SSO provisioning
- 3M365 · license assignment (E3 / E5 selectable)
- 4Optional Jira · project-role grant
- 5Optional Confluence · space access grant
What a generalist tool calls "a new-hire integration" we ship as one orchestrated runbook. The depth comes from purpose-built sequencing, not from "more connectors."
05 · Customization
Day-1 your 80%. Custom-built your remaining 20%.
Every IT environment has organization-specific workflows the 13 shipped runbooks don't cover. The custom runbook layer is how we close that gap: three paths to a production-grade custom runbook, all sharing the same governance and audit primitives.
White-gloveWe build it.
Onboarding-tier professional services engagement. Our team writes custom runbooks against your environment: your specific group naming conventions, your specific approval workflows, your specific integration permissions. Production-ready typically within onboarding window.
Self-serveYour team builds it.
TypeScript orchestrator pattern with HITL gates, retry semantics, rollback steps, and audit-chain primitives all available out of the box. Deploy via PR to your forked AscendCore repo. Same engineering pipeline as our shipped runbooks, with no separate "low-code" abstraction layer and its own quirks to learn.
On the roadmapNo-code canvas.
YAML-defined runbook DSL for non-engineering authors: same governance, same audit chain, lower authoring bar. Targeting Q4 2026 release. We're building it carefully so the no-code path inherits the safety primitives of the code path, not vice versa.
Customer-authored runbooks remain tenant-scoped: never published, never shared across customers, never used to train any model. The runbook layer is your operational IP. We treat it that way.
06 · Programmable surface
Customer API v1. Live.
Every runbook is API-callable. Every execution is webhook-emittable. Plug AscendCore into your existing ITSM, your alerting pipeline, your custom workflow tooling.
Bearer-token authenticated REST API
Stripe-style `ak_live_*` keys (256-bit entropy, hashed at rest, show-once on creation). Self-serve key management at /dashboard/api with per-key rotation and revocation.
OpenAPI 3.1 spec at /api-docs
Redoc-rendered interactive documentation; download `openapi.yaml` for codegen against your preferred SDK. Endpoints: GET /v1/runbooks, POST /v1/runbooks/:id/execute, POST /v1/tickets/ingest (ServiceNow incident intake), GET /v1/runs/:id, GET /v1/audit/events.
HMAC-SHA256 signed outbound webhooks
Stripe-format signatures (`t=<unix>,v1=<hex>`) with replay-window enforcement; auto-disable on consecutive delivery failures.
Plan-tier rate limits
Free 60 req/min · Pro 600 req/min · Enterprise 6,000 req/min. Higher caps available on request; admin-set per-key overrides honored regardless of plan tier.
07 · Governance
Governance baked in. Not bolted on.
Four architectural decisions that make AscendCore deployable in environments where compliance review torpedoes horizontal-AI sales cycles. Full posture at /security/overview.
Approval-first architecture
Every automation requires explicit human approval before execution. The LLM classifies intent; it has no execution access. Runbooks are the load-bearing primitive; chat is the interface that triggers them.
SHA-256 tamper-evident audit chain
Every approve, deny, and execution event appends to a Postgres-backed SHA-256 hash chain. A single altered row breaks chain verification. Customers export the full chain and re-run our verification routine independently.
Per-organization credential isolation
Integration secrets (Okta API keys, Entra client secrets, M365 credentials, Slack tokens) are scoped per organization and managed via Doppler vaults. Each org's credentials resolve only for that org's traffic.
Mandatory IdP-mediated MFA
Admin authentication runs through your identity provider (Microsoft Entra or Okta) via OIDC SSO. MFA is enforced at the IdP, so your conditional access policies, device trust, FIDO2, and hardware tokens apply unchanged.
RAG-based knowledge answers, with the same approval gate as runbook execution.
Today: RB-012 ships deterministic Confluence space provisioning with full audit chain. Knowledge integrations (Confluence, SharePoint, Notion, Guru) are wired for runbook execution but not yet for question-answering.
Q4 2026 roadmap:surface answers from your indexed knowledge corpus with the same governance posture: citations, confidence scoring, approval-gated escalation when confidence drops below threshold. We're building it carefully so the knowledge layer inherits the safety primitives of the execution layer.
Every action is logged.
Every log is exportable.
AscendCore maintains a Postgres-backed SHA-256 hash chain of every runbook approval and execution. Each row cryptographically links to the prior row's hash; a single altered row breaks chain verification. Customer-exportable for independent verification. See /security/overview.
- SHA-256 tamper-evident chain, verified live in production
- CSV export today · SIEM connectors (Splunk HEC, Sentinel) on roadmap
- SOC-2 Type I planned: Vanta enrollment begins once budgeted, then a ~90-day audit window
- Configurable retention (90d → 7yr), enterprise tier roadmap
Ready to Reclaim 200+ Hours a Month?
Join forward-thinking IT teams piloting AscendCore in private beta. Onboarding takes days, not months, with human-in-the-loop approval on every action.
No credit card required. 30-day pilot. Cancel anytime.
