Welcome to the Thrasoz Intelligence Platform

Thrasoz is the enterprise-grade AI operating system that turns business signals into governed execution across software development and knowledge work.

Signals reads your organization in real time. Harbor (SIGHT) tracks requirements and project work as the ground truth for what gets built. Maestro gives leaders a single command center to orchestrate and govern the AI fleet. Shipyard executes with production-grade discipline and complete auditability. One closed loop. Full control. No information gaps.

Why We Built the Thrasoz Platform

The Problem

Most organizations are deploying AI in fragments. Developer tools improve code velocity but leave governance, cross-function context, and business operations behind. The result is shadow spend, compliance exposure, lost tribal knowledge, and automation that optimizes one area while creating friction everywhere else.

The Solution

Thrasoz replaces fragmented tools and tribal knowledge with a single, coordinated operating system. Signals creates a unified intelligence layer across engineering, finance, labor, and operations. Maestro gives leaders a governed workspace to set policy and orchestrate agents. Shipyard delivers disciplined execution through the full AI Software Factory — with mandatory review gates and complete audit trails.

The platform is built for organizations that need more than point solutions. They need a true control plane for AI across the entire enterprise.

Architecture Overview

Thrasoz is built on four tightly integrated layers that form one closed loop:

• Signals — Real-time intelligence across engineering, finance, labor, and operations. Ingests data from the systems you already use and surfaces what matters before it becomes a problem or missed opportunity.
• Maestro — The AI control plane. Leaders set policy, orchestrate agent fleets, and maintain full visibility and authorization over every action.
• Shipyard — The AI Software Factory and execution engine. Converts approved specifications into production-ready code and agents with mandatory review gates, full versioning, and self-healing pipelines.
• Harbor — Project management and knowledge base: tickets, wiki, billable time tracking, and the SIGHT spec workspace. The ground truth for what gets built.

Business intelligence feeds the control plane. The control plane governs the fleet. The fleet executes and reports back. Harbor is the shared record of what was decided, what is in flight, and what shipped. Nothing operates outside the loop.

Core Concepts

• Harmony AI — The natural language interface to your organization's live intelligence. Ask questions across engineering, finance, labor, and operations and get grounded answers in seconds.
• Work Orders & Agent Fleets — Structured, policy-governed tasks that flow through Maestro with human oversight where required.
• Authorization Policy & Governance Auditor — Define what agents can do and when human approval is mandatory. Every action is logged with full context.
• Execution Pipelines & Review Gates — Mandatory automated gates (Code Review, Security Review, Customer-Replica QA) before any change reaches production.
• Closed-Loop Telemetry — Runtime feedback flows back into Signals so the system continuously learns, improves, and self-corrects.

Architecture

Thrasoz operates as a three-layer closed loop. Each layer is independently useful; together they eliminate the gap between business signal and governed AI execution.

Quickstart Guide

Get up and running with the Thrasoz Intelligence Platform in under 15 minutes. This guide walks you through connecting your environment and seeing your first governed intelligence and automation.

Prerequisites

• A Thrasoz workspace (sign up at thrasoz.com or request access from your administrator)
• Admin or Owner permissions in your workspace
• Access to at least one system you want to connect (GitHub, Jira, AWS, finance system, etc.)

Step 1 — Install the CLI and Authenticate

npm install -g @thrasoz/cli
thrasoz login

This creates a secure connection between your local environment and your Thrasoz workspace.

Step 2 — Connect Your First Data Source

Connect the systems that matter most to your teams. Signals will begin normalizing data across engineering, finance, labor, and operations immediately.

thrasoz connect github --org your-org
thrasoz connect jira --site your-site.atlassian.net
thrasoz connect aws --profile production

Step 3 — Explore Live Intelligence in Harmony AI

Open Harmony AI (in the web interface or via Slack) and try a question:

What is our current open high-severity Jira backlog by team?
Show me cloud spend trends over the last 30 days by service.
Which repositories have the highest change failure rate this month?

You'll see answers grounded in live data from the sources you connected.

Step 4 — Set Up Basic Governance

Create your first authorization policy so agents operate safely from day one.

# policy/basic-governance.yaml
version: 1
default_action: require_approval
rules:
  - action: "shipyard.deploy"
    risk: high
    requires: ["human_approval"]
  - action: "signals.query"
    risk: low
    requires: []

thrasoz policy apply policy/basic-governance.yaml

Step 5 — Enable Slack Alerts

thrasoz slack connect
thrasoz alerts enable --channel #ai-operations

You'll now receive governed alerts and can approve or reject Work Orders directly in Slack.

What's Next?

• Explore the full Architecture section to understand how Signals, Maestro, and Shipyard work together.
• Dive into Maestro to start building your first governed agent fleets.
• Visit Shipyard to see how the AI Software Factory handles complex multi-repository work with full auditability.
• Join the community workspace for examples and implementation patterns.

You now have live intelligence and the foundation for governed automation. Everything you do from this point forward flows through the Thrasoz control plane.

Core Concepts

The Information Gap

Every organization loses value every month because the people who need to act don't know what's happening until it's too late. Revenue dips aren't visible until the monthly close. Engineering productivity collapses silently. Headcount costs drift against plan without anyone surfacing it in real time.

Thrasoz is built to eliminate this gap. Signals is always reading. Harmony AI is always answering. Nothing waits for a report cycle.

The Closed Loop

A traditional AI tool gives you a capability but doesn't close the loop between output and the business. Thrasoz is designed differently: every Shipyard execution generates telemetry that feeds back into Signals. Signals updates Maestro's context. Maestro's next decision is better informed. The loop compounds.

Governance by Default

Authorization policy is not optional or bolted on. Every Thrasoz deployment ships with a default policy that requires human approval for high-impact action classes. You can tighten or relax the policy, but you cannot disable the audit log. Every AI action taken inside Thrasoz is logged, attributed to the authorizing human, and exportable.

Agents and Fleets

An agent in Thrasoz is a bounded, purposeful AI process: it has a defined input type, a specific capability, and a configured output action. Agents are registered in the Maestro agent registry, assigned capability tags, and governed by the authorization policy. A fleet is a collection of agents managed by Maestro to accomplish a coordinated objective — for example, a Software Factory fleet might include a requirements agent, a spec agent, a code generation agent, a review agent, and a deployment agent, all orchestrated by Maestro.

Signals — Intelligence Layer

Signals is the data ingestion, normalization, and intelligence layer. It connects to every business system you operate, normalizes data into a unified schema, and makes it queryable through Harmony AI and the Signals dashboard.

Data model

Signals organizes all ingested data into four domains:

• Engineering — commits, PRs, deployments, incidents, sprint velocity, review latency, test coverage, bug rates
• Finance — revenue, EBITDA, payroll, cost centers, invoices, payments, cash position
• Labor — headcount, attrition, hiring pipeline, compensation, capacity, utilization
• Operations — SLAs, customer signals, vendor performance, system uptime, support load

Every data point is tagged with source, entity (business unit or portfolio company), timestamp, and confidence score. Cross-domain queries — "show me the correlation between engineering incident rate and customer churn this quarter" — work natively.

Harmony AI

Harmony is the natural language query interface to Signals data. It works across all four domains and understands business context — it knows what "this quarter" means, what a "healthy PR latency" is for your industry, and how to interpret a 5% EBITDA delta relative to your plan.

# Example Harmony queries (via CLI or Slack /harmony command)

"What's our engineering headcount cost trend vs Q1?"
"Which portfolio companies have EBITDA declining more than 3% MoM?"
"Summarize the top 5 risks I should know about this week."
"Who are the top contributors by PR merge rate in the last 30 days?"

Maestro — Control Plane

Maestro is the AI control plane. It governs what agents can do, maintains the authorization policy, and provides the human-in-the-loop interface your organization needs to trust AI at scale.

Authorization policy

Maestro ships with a default policy that classifies actions into three tiers:

• Auto-approved — read-only operations, analysis, draft generation, internal notifications
• Requires approval — code commits, external communications, data mutations, deployment triggers
• Always blocked — production database writes, financial transactions, user account changes

Every organization configures their own policy on top of this baseline. Policy is version-controlled and changes are logged.

Work Orders

Work Orders are the atomic unit of Maestro's Software Factory. A Work Order contains a natural-language requirement, a structured spec generated by the requirements agent, authorization status, and an execution trace. Work Orders move through states: draft → spec_review → approved → in_progress → review → complete. Every state transition is logged with the human actor.

Shipyard — Execution Engine

Shipyard executes what Maestro approves. It handles multi-repository orchestration, pipeline management, and self-healing — and feeds runtime telemetry back into Signals to close the loop.

Multi-repo orchestration

A single Work Order may require changes across multiple repositories — a backend service, a frontend application, an infrastructure-as-code repo, and a shared library. Shipyard coordinates all of these as a single atomic unit: either all changes succeed together, or none are promoted. Partial deployments are not possible.

Self-healing pipelines

Shipyard monitors runtime telemetry after every deployment. If a service regresses against defined SLIs within a configurable window, Shipyard triggers an automatic rollback and opens a Maestro Work Order to investigate the root cause. No human needs to notice the alert — the system reacts before the on-call page fires.

Audit trail

Every file change, every pipeline run, every deployment is recorded with the Work Order ID, the authorizing human, the agent that generated the change, and the test results that gated promotion. The full trace exports to your SIEM or compliance tooling in JSON or OCSF format.

Harbor — Project Management & Knowledge Base

Harbor is the self-hosted project management and knowledge platform that anchors the Thrasoz loop. It replaces Jira + Confluence with a single, tenant-isolated system: tickets, kanban, wiki, billable time tracking, and the SIGHT spec workspace — all backed by a shared PostgreSQL instance alongside the rest of the Thrasoz suite.

Tickets

Tickets are the atomic unit of work in Harbor. Each ticket carries a project-scoped key (e.g. SY-42), a markdown description, priority, status, assignee, reporter, and optional tags, linked repo, and branch.

• Status flow: open → in_progress → review → done → validated → archived
• Priority: P0 (blocking) → P1 (next session) → P2 (backlog) → P3 (nice-to-have)
• Links: blocks / blocked_by / relates_to / duplicates — bidirectional, queryable
• Time tracking: per-ticket log entries (date, hours, billable flag, org); exported to QuickBooks-compatible CSV via GET /api/v1/time/export?format=csv
• Comments: markdown, with source tagging (user / shipyard / slack / api)
• Shipyard integration: pipeline webhooks create and update tickets automatically on CI events

Board & List

Tickets are worked from two parity views. Board is a kanban layout with saved per-user views, swimlanes, quick-edit on card, bulk operations across a selection, and soft WIP-limit hints per column (workflowConfig.wipLimits - advisory, not blocking). List is a dense sortable/filterable table over the same tickets, sharing the same saved-view persistence as Board.

SIGHT — Spec Workspace

SIGHT (/sight) is Harbor's three-pane spec and requirements workspace. It surfaces the underlying hierarchical wiki of markdown pages and tickets through a layout optimized for specification work rather than task execution. Pages carry automatic revision history and are scoped to a project, with optional public visibility for tenant-external sharing. Full-text search across all pages is powered by PostgreSQL ts_vector / ts_rank.

• Left pane: hierarchical wiki tree for the active project - specs, blueprints, ADRs, and any other structured doc pages, nested to any depth
• Center pane: selected page content in a rich WYSIWYG editor, plus the list of open and in-progress tickets that represent buildable work. A Map view renders the page tree as a force-directed graph for large spec sets.
• Right pane: the Assistant - an AI chat panel scoped to the project context, with a chip showing the current page in scope. Draft specs, answer questions about the codebase, suggest next steps.

Every spec page opens in one of three toggleable views over the same underlying content: Document (the WYSIWYG editor above), Map (the force-directed graph of what implements the page, what built it, and where it lives in the product), and Ledger (a sortable, filterable table of linked tickets, comments, and revisions - exception-first ordering so what needs attention surfaces first). Tickets can be dispatched to Shipyard directly from SIGHT's center pane. In-place change requests on a spec page go through a review/approval gate before the page body is updated. ADR headings receive permanent fragment anchors for deep-linking.

Artifacts

The Artifacts view (/artifacts) is a unified read surface over what has been fed into and produced by the AI panel: source documents attached to a project (ArtifactSource) and content the Assistant has generated from them (GeneratedArtifact) - specs, summaries, and other structured output, versioned at generation time so a reviewer can trace a document back to the exact source snapshot the agent used.

Feedback

A dedicated Feedback view (/feedback) captures raw, unstructured input - end-user requests and observations that haven't yet been shaped into a ticket - kept separate from ticket and wiki comments so intake stays distinct from tracked work.

Automations & rollback

Each dispatched ticket's per-task Anthropic usage and cost is joined against the pipeline that built it, giving a per-ticket cost view alongside status. A merged pipeline can be rolled back from the ticket directly, reverting the exact merge commit captured at merge time. Tickets blocked by Shipyard's acceptance-criteria gate can be force-merged by an admin as an explicit override, recorded in the pipeline's audit trail.

Settings & multi-tenancy

Every Harbor resource is scoped to a tenant. Project.keyPrefix and Ticket.key uniqueness is per-tenant, so multiple organizations can use the same prefixes without collision. Tenant provisioning is admin-only; there is no self-serve signup. The Shipyard CI/CD integration routes exclusively to the default tenant.

Per-project settings control which pages are visible (pageVisibility), locale, and default nav state. Tenants can restrict invite-time signup to an allowed set of email domains (domainAllowlist). White-label branding presents Harbor under a product-specific name and hides Harbor-internal navigation based on the hostname a tenant is accessed from - presentation-layer only.

API surface

POST   /api/v1/auth/login
GET    /api/v1/auth/me
GET    /api/v1/projects
POST   /api/v1/projects
GET    /api/v1/tickets?project=&status=&priority=&assignee=
POST   /api/v1/tickets
GET    /api/v1/tickets/:key         # full detail + comments + time + activities
PUT    /api/v1/tickets/:key
POST   /api/v1/tickets/:key/transition
POST   /api/v1/tickets/:key/comments
POST   /api/v1/tickets/:key/time
POST   /api/v1/tickets/:key/rollback        # revert the merge commit captured at dispatch
POST   /api/v1/tickets/:key/override-merge  # admin bypass of a blocked AC-gate
GET    /api/v1/wiki                 # project-scoped page list
POST   /api/v1/wiki
GET    /api/v1/wiki/:id
PUT    /api/v1/wiki/:id
GET    /api/v1/wiki/:id/revisions
GET    /api/v1/time/summary
GET    /api/v1/time/export?format=csv
GET    /api/v1/automations?project=  # per-ticket dispatch cost + pipeline status
GET    /api/v1/feedback
POST   /api/v1/feedback
GET    /api/v1/attachments           # unified artifacts list
GET    /api/v1/search?q=            # unified tickets + wiki
GET    /api/v1/events?token=        # SSE stream for real-time updates
POST   /api/v1/webhooks/github      # auto-link/transition tickets on merged PRs
POST   /api/v1/shipyard/pipeline-complete   # pipeline webhook (service token)
POST   /api/v1/shipyard/create-ticket

Integrations

• Shipyard - bidirectional: Harbor creates tickets from pipeline events; Shipyard reads ticket status to gate deployments; a merged, AC-gated PR can be rolled back from the ticket
• GitHub - a webhook auto-links, comments on, and transitions the matching ticket when a PR referencing its key merges, independent of whether the work was dispatched through Shipyard
• Notifications - SMTP (email) and Twilio (SMS) config stored per tenant; review-state transitions trigger email to the reporter; per-project Slack incoming webhooks post status-change updates
• Maestro — SIGHT's chat pane dispatches to Shipyard via the Maestro agent fabric
• AI triage - new tickets get an automatic suggested priority, tags, and one-line summary posted as a comment; it never mutates ticket fields directly

Write Requirements

A well-formed requirement is the foundation of every Work Order. Requirements that are vague or metric-free are flagged by the ambiguity scorer before they can be approved.

Anatomy of a requirement

Every requirement should contain four elements:

• Actor — Who initiates or is affected by this change.
• Action — What the system must do differently.
• Acceptance criterion — The observable condition that proves the action is complete.
• Success metric — A measurable outcome within a defined window (e.g., latency, error rate, conversion).

Weak vs. strong examples

Common pitfalls

• Using "faster", "better", or "more reliable" without a numeric baseline.
• Conflating multiple features in a single requirement — split them.
• Missing the actor: if you cannot name who triggers or benefits, the scope is undefined.
• No acceptance criterion: the requirement will score above the ambiguity threshold (0.6) and be blocked from approval.

Attaching Signals context

Requirement statements submitted via Slack or the API can include a Signals context reference to ground the requirement in observed data:

POST /v1/requirements
{
  "statement": "...",
  "signals_context": {
    "metric": "checkout_latency_p95",
    "window": "7d",
    "current_value": 2.4,
    "target_value": 1.2
  }
}

Signals context is surfaced to the agent during spec generation and prepended to the acceptance criteria automatically.

Create a Blueprint

A Blueprint decomposes a set of approved Requirements into a directed acyclic graph of tasks. Use a Blueprint when a requirement needs more than one Work Order to fulfill — for example, a database schema change, a migration script, an API endpoint, and a frontend update that must land in sequence.

When to use a Blueprint

• The requirement touches more than one service or repository.
• The change has a strict ordering constraint (schema before migration, migration before API, API before frontend).
• Risk classification is deployment or infra-change — a Blueprint forces an explicit scope boundary review before any Work Orders are generated.

Blueprint structure

A Blueprint has four sections:

1. Scope boundary — the repositories, services, and data stores in scope.
2. Task decomposition — up to 12 tasks per requirement, each mapped to a single agent type.
3. Dependency DAG — the execution order, with circular dependency detection enforced at save time.
4. Risk classification — read-only, data-mutation, deployment, or infra-change. Drives the approval tier for generated Work Orders.

Approval flow

Blueprints move through a section review before Work Orders can be generated. At least one Section Lead must approve. Conductors can override. Work Orders are not generated until the Blueprint reaches approved status — this is not bypassable.

Generating Work Orders

POST /v1/blueprints/:id/generate-orders

Returns an array of Work Order IDs, one per Blueprint task. Each Work Order inherits the risk tier and acceptance criteria from its parent task. Work Orders within a Blueprint respect the dependency DAG — a dependent Work Order will not enter in_progress until its predecessors reach complete.

Create Work Orders

A Work Order is the unit of execution. It carries a spec, an authorization record, and a complete execution trace from first agent action to final test result.

Creation methods

• From Blueprint — POST /v1/blueprints/:id/generate-orders. Preferred for multi-task changes.
• From Requirement — POST /v1/requirements/:id/work-orders. Creates a single Work Order directly from an approved requirement.
• From Slack — Mention the Maestro bot with a task description. Maestro creates a draft Work Order and confirms the spec with you before queuing execution.

Lifecycle

Failure paths: blocked (human intervention required) and cancelled (explicit reject at any gate).

Slack approvals

Every spec and deployment gate surfaces as a Slack message with approve/reject buttons. Approval logs the authorizing user ID and timestamp into the Work Order's immutable audit record. There is no bypass path for spec approval — even Conductors must explicitly approve.

Migrate from Jira

Thrasoz provides a direct import path from Jira. The importer maps Jira's issue hierarchy to Thrasoz's Requirement → Blueprint → Work Order model.

Field mapping

Import steps

Team transition

Run Thrasoz and Jira in parallel during the transition period. Thrasoz can bi-directionally sync status back to Jira issues so your team is not blocked by the migration. Disable the sync once the team has fully adopted the Thrasoz workflow.

Train Agents

Agents in Maestro are scoped to specific capability types and operate under an organization-level authorization policy. Training an agent means registering it, assigning capabilities, and validating its behavior in sandbox before it can handle live Work Orders.

Register a new agent

POST /v1/agents
{
  "name": "backend-code-agent",
  "capability_tags": ["code_generation", "code_review", "test_generation"],
  "default_model": "claude-sonnet-4-6",
  "sandbox_mode": true
}

Capability tags

Eight built-in capability types constrain what a registered agent can attempt:

• code_generation — Write or modify source files.
• code_review — Analyze diffs and surface findings.
• test_generation — Derive test cases from acceptance criteria.
• data_query — Read from approved data sources (read-only).
• external_communication — Send messages to approved channels (requires approval tier).
• spec_generation — Draft implementation specs from requirements.
• blueprint_decomposition — Decompose requirements into task DAGs.
• deployment — Trigger Shipyard pipelines (requires Section Lead approval).

Sandbox testing

With sandbox_mode: true, the agent processes real Work Orders but all file writes, pipeline triggers, and external communications are intercepted and logged rather than applied. Review the sandbox trace at GET /v1/agents/:id/sandbox-trace before promoting to production.

Authorization policy overlay

Per-agent authorization policy overrides the organization default. Use this to restrict a high-capability agent to a specific team or repository set:

PATCH /v1/agents/:id/policy
{
  "deployment": "requires_approval",
  "allowed_repos": ["org/backend-service", "org/infra"]
}

Connect a Codebase

Thrasoz indexes your repositories to give agents accurate structural context during spec generation and code review. Connecting a codebase does not grant agents write access — that is a separate authorization step at the Work Order level.

OAuth connection

Under Administration → Information Sources, connect your GitHub or GitLab account. Thrasoz requests read-only scopes: repo:read, metadata:read. Self-managed GitLab instances can authenticate via a personal access token with read_repository scope.

What gets indexed

• Repository structure and file tree
• Function signatures, class definitions, and public interfaces
• Import and dependency graphs
• Recent commit history and PR descriptions
• Existing test coverage by file

Raw file content is never stored. Only structural metadata and semantic embeddings are persisted.

Access control

Repository access within Thrasoz mirrors your source control permissions. A user who cannot read a repository on GitHub cannot access its indexed metadata in Thrasoz. There is no elevation path — agent access is bounded by the authorizing human's own permissions.

Credentials scan

During indexing, Thrasoz runs a credentials pattern scan and reports any detected secrets to the connecting user. Thrasoz does not store the detected values — only the file path and pattern type are recorded. Resolve findings in the source repository before using the codebase in Work Orders.

Point to Files and Folders

Artifact sources extend agent context beyond codebases. Use them to ground requirements in design documents, architecture records, compliance standards, or any structured reference material.

Adding an artifact source

POST /v1/artifact-sources
{
  "type": "confluence_page",
  "url": "https://your-org.atlassian.net/wiki/spaces/ENG/pages/123456",
  "label": "API Design Standards",
  "refresh": "daily"
}

Supported source types

• Repository directory or file — a specific path within a connected codebase.
• Confluence page or space — indexed with 24h cache.
• Notion page or database — indexed with 24h cache.
• Google Drive file or folder — PDF, Docs, Sheets supported.
• File upload — direct upload up to 50 MB (PDF, Markdown, CSV).
• Public URL — fetched and indexed at connection time; re-fetched on demand.

Using artifact sources in requirements

Reference an artifact source by ID in any requirement or blueprint. The agent will retrieve the current snapshot during spec generation:

"artifact_refs": ["art_7f3b9c", "art_2a1d0e"]

Versioning

Each artifact snapshot is versioned at index time. The version ID used during spec generation is recorded in the Work Order's audit trail, so reviewers can always retrieve the exact document state the agent used — even if the source document changes later.

Module: Requirements

The Requirements module is the entry point for all work in the Software Factory. Requirements are authored and managed in Harbor — as tickets with structured descriptions, priorities, and spec pages in the SIGHT workspace — then enriched and governed by the platform layer (Maestro, Shipyard) before driving execution.

Input

A requirement is created as a Harbor ticket containing:

• Title and markdown description — actor, action, acceptance criterion, success metric (see Write Requirements for structure guidance)
• Priority: P0 / P1 / P2 / P3
• Project key prefix (e.g. SY, FB)
• Optional: linked tickets (blocks / blocked_by / relates_to / duplicates)
• Optional: wiki spec page associated via SIGHT
• Optional: Signals metric context embedded in the description body

Platform enrichment (Maestro layer)

When a requirement ticket is dispatched to Shipyard from SIGHT, Maestro agents apply the enrichment pipeline before execution begins:

Ticket schema (Harbor)

{
  "key": "SY-42",
  "title": "...",
  "description": "...",          // markdown — actor, AC, success metrics
  "status": "open",              // open | in_progress | review | done | validated | archived
  "priority": "P1",              // P0 | P1 | P2 | P3
  "type": "feature",
  "assigneeId": 3,
  "reporterId": 1,
  "tags": [],
  "repo": "harbor",
  "branch": null,
  "prUrl": null,
  "links": [
    { "type": "blocks", "key": "SY-40" }
  ],
  "createdAt": "2026-07-01T10:00:00Z"
}

State machine

open → in_progress → review → done → validated → archived

A validated requirement has been accepted by the reporter after completion. Archived requirements are off-board but remain searchable. Cancellation exits the flow at any pre-done state.

API surface (Harbor)

POST   /api/v1/tickets             # Create requirement ticket
GET    /api/v1/tickets?project=&status=open   # List
GET    /api/v1/tickets/:key        # Full detail + links + comments + time
PUT    /api/v1/tickets/:key        # Update description / priority / assignee
POST   /api/v1/tickets/:key/transition   # Change status
POST   /api/v1/links               # Link to related ticket (fromKey, toKey, linkType)
GET    /api/v1/links/:key          # All links for a ticket

Integrations

• Harbor / SIGHT — requirements live as tickets; SIGHT provides the spec workspace for authoring and reviewing them alongside wiki pages, in Document, Map, and Ledger views.
• Signals — metric context can be embedded in the description; Maestro agents pull live values at dispatch time.
• Blueprints — requirements are linked to blueprint wiki pages in SIGHT; decomposition is authored in the center pane.
• Shipyard — dispatch from SIGHT triggers a Shipyard pipeline; pipeline events update the ticket status via webhook.
• Maestro — routes approval and enrichment steps; Slack-native approval for high-priority or ambiguity-flagged requirements.
• Auditor — every ticket status transition and dispatch event is recorded with the acting user and timestamp, so a requirement's build history stays traceable rather than going stale.

Module: Blueprints

Blueprints decompose approved Requirements into a dependency-ordered task graph. Each task maps to exactly one agent type and one risk tier, producing deterministic Work Order sequences.

Input

• One or more approved Requirements (status = approved)
• Optional: artifact source references
• Scope boundary declaration (repositories, services, data stores in scope)
• Optional: codebase IDs for context during decomposition

Processing pipeline

Output schema

{
  "id": "bp_def456",
  "status": "draft",
  "title": "...",
  "scope_boundary": { "repos": [...], "services": [...] },
  "requirement_ids": ["req_abc123"],
  "tasks": [
    {
      "id": "task_001",
      "title": "...",
      "requirement_id": "req_abc123",
      "depends_on": [],
      "risk_tier": "data-mutation",
      "acceptance_criteria": [...],
      "effort": "M",
      "assigned_agent_type": "code_generation"
    }
  ],
  "risk_tier": "data-mutation",
  "artifact_refs": [...],
  "codebase_ids": [...],
  "created_by": "usr_xyz",
  "created_at": "2026-06-09T14:00:00Z",
  "approved_by": null,
  "approved_at": null
}

State machine

draft → section_review → approved → work_orders_generated

API surface

POST   /v1/blueprints
GET    /v1/blueprints/:id
PATCH  /v1/blueprints/:id
POST   /v1/blueprints/:id/approve
POST   /v1/blueprints/:id/generate-orders
GET    /v1/blueprints/:id/tasks
GET    /v1/blueprints/:id/dag

Module: Work Orders

Work Orders are the atomic execution unit. Each carries a spec, a complete authorization record, and an immutable execution trace from spec approval through test result.

Input

• Blueprint task (preferred — inherits DAG ordering and scope)
• Standalone approved Requirement (for single-task changes)
• Slack mention (creates a draft Work Order; spec must be confirmed before execution)

Processing pipeline

Output schema

{
  "id": "wo_ghi789",
  "status": "complete",
  "title": "...",
  "requirement_id": "req_abc123",
  "blueprint_id": "bp_def456",
  "task_id": "task_001",
  "risk_tier": "data-mutation",
  "spec": "...",
  "execution_trace": [...],
  "review_findings": [...],
  "qa_results": { "passed": 12, "failed": 0 },
  "diff_url": "https://github.com/org/repo/pull/42",
  "authorizing_human": "usr_xyz",
  "created_by": "usr_xyz",
  "created_at": "2026-06-09T14:00:00Z",
  "completed_at": "2026-06-09T14:47:00Z"
}

State machine

draft → spec_ready → spec_approved → in_progress → code_review → qa → pending_approval → complete

Failure paths: blocked (human intervention required), cancelled (explicit reject at any gate).

API surface

POST   /v1/work-orders
GET    /v1/work-orders/:id
PATCH  /v1/work-orders/:id
POST   /v1/work-orders/:id/approve-spec
POST   /v1/work-orders/:id/reject-spec
POST   /v1/work-orders/:id/approve
POST   /v1/work-orders/:id/reject
GET    /v1/work-orders/:id/trace
GET    /v1/work-orders/:id/diff

Integrations

• Blueprints — input; inherits DAG ordering.
• Shipyard — execution engine; receives spec, returns trace.
• Auditor — emits events on every state transition and gate decision.
• Signals — records telemetry on completion; feeds cycle time and throughput metrics.
• Maestro — routes spec approval and deployment approval notifications via Slack.

Module: Auditor

The Auditor is a read-only observer. It never modifies work — it records it. Every event from every module is written to an append-only, hash-chained log that can be verified for integrity at any point.

Role and scope

Processing pipeline

Event schema

{
  "event_id": "evt_jkl012",
  "timestamp": "2026-06-09T14:23:00Z",
  "event_type": "work_order.spec_approved",
  "actor_human_id": "usr_xyz",
  "actor_agent_id": "agent_backend-code-agent",
  "work_order_id": "wo_ghi789",
  "blueprint_id": "bp_def456",
  "action_class": "code_commit",
  "authorization_method": "manual",
  "authorization_tier": "requires_approval",
  "input_summary": "...",
  "output_summary": "...",
  "outcome": "approved",
  "policy_compliant": true,
  "risk_flags": [],
  "chain_hash": "sha256:a1b2c3..."
}

API surface

GET    /v1/audit-events                 # Paginated event stream
GET    /v1/audit-events/chain-of-custody/:wo_id
GET    /v1/compliance/report            # SOC 2 / ISO 27001 summary
POST   /v1/compliance/export            # SIEM export trigger
GET    /v1/audit/risk-flags             # Open anomaly flags
POST   /v1/audit/risk-flags/:id/resolve

External SIEM support

Native integrations: Splunk HEC, Datadog Logs, Chronicle, and any OCSF-compatible sink via webhook. Events are delivered with at-least-once semantics; the event_id field enables idempotent deduplication on the receiving end.

Organization

Organization settings control workspace identity, data handling, and agent execution windows. Only Conductors can modify these settings.

Workspace settings

• Organization name and slug — the slug appears in all API paths and cannot be changed after creation.
• Default timezone — used for scheduled reports and agent execution hour enforcement.
• Data retention — audit log retention period. SOC 2 Type II profiles enforce a 365-day minimum.
• Agent execution hours — restrict autonomous agent execution to defined windows (e.g., 06:00–22:00 local time). Execution outside this window is queued.

Single Sign-On

Thrasoz supports SAML 2.0 and OIDC. Supported identity providers: Okta, Azure AD, Google Workspace, Ping Identity, and any SAML 2.0-compliant IdP. SSO enforcement can be set to optional, required, or required-with-exceptions (for service accounts).

Domain whitelist

Restrict member invitations to specific email domains. Members with non-whitelisted domains who are already in the organization are grandfathered; new invitations to non-whitelisted domains are blocked.

Members & Roles

Thrasoz has three roles. Role assignment is the primary mechanism for controlling who can approve what.

Role definitions

• Conductor — Full administrative access. Can modify authorization policy, invite members, manage billing, and approve any Work Order regardless of risk tier. Reserved for engineering leadership.
• Section Lead — Operational approver. Can approve Work Orders up to deployment tier. Cannot approve infra-change tier without a Conductor co-signer. Cannot modify organization settings or billing.
• Player — Contributor. Can submit Requirements, create Work Orders, and view all non-sensitive audit records. Cannot approve any Work Order or modify any policy.

Invite flow

POST /v1/members/invite
{
  "email": "[email protected]",
  "role": "section_lead"
}

The invitee receives an email with a time-limited token. If SSO is enforced, the token redirects through your IdP before account creation completes. Invitations expire after 72 hours.

Service accounts

Agents registered in the system operate under service accounts with a fixed role of Player. Service accounts cannot hold Section Lead or Conductor roles — human approval authority cannot be delegated to an agent.

Billing

Thrasoz pricing has two components: a platform subscription tier and usage-based AI execution costs.

Plan tiers

• Starter — Up to 5 members, 50 Work Orders/month, community support. No SLA.
• Scale — Up to 50 members, unlimited Work Orders, 1 business day SLA on critical issues, SSO optional.
• Enterprise — Unlimited members, custom data residency, 2-hour P1 SLA, dedicated CSM, SSO required, custom contract.

Usage-based AI execution

AI execution costs are billed monthly based on actual token consumption across all agent runs. Usage is reported per Work Order and aggregable by team, agent, or repository. Spend alerts can be configured at the organization or team level.

Billing cadence

Subscription fees are billed monthly or annually (annual carries a 15% discount). AI execution costs are billed monthly regardless of subscription cadence. Invoices are available for download via the API:

GET /v1/billing/invoices
GET /v1/billing/invoices/:id/pdf
GET /v1/billing/usage?month=2026-06

Security

Authorization policy

The authorization policy is a YAML document version-controlled alongside your Maestro configuration. Each entry maps an action class to an authorization tier.

version: "1.0"
policy:
  read_operations:         auto
  draft_generation:        auto
  internal_notification:   auto
  code_commit:             requires_approval
  external_communication:  requires_approval
  deployment_trigger:      requires_approval
  data_mutation:           requires_approval
  financial_transaction:   blocked
  user_account_change:     blocked
  production_db_write:     blocked

approvers:
  default:
    - slack_user_id: "UXXXXXXXX"
      name: "Lead Engineer"
  financial_transaction:
    - slack_user_id: "UXXXXXXXX"
      name: "CFO"

Audit trail

Every action Maestro authorizes generates an audit event. Fields: event_id, timestamp, action_class, agent_id, work_order_id, authorizing_human, authorization_method (auto/manual/policy), input_summary, output_summary, and outcome.

Audit events are immutable, append-only, and exported to your configured SIEM sink in real time. Retention is configurable — SOC 2 Type II profiles default to 365 days.

API tokens

API tokens are scoped at creation time to a specific set of resource types and actions. A token cannot be used to approve Work Orders — approval requires an authenticated human session. Tokens are displayed once at creation and cannot be retrieved again; rotate via the API or dashboard.

POST /v1/api-tokens
{
  "label": "ci-readonly",
  "scopes": ["work_orders:read", "audit_events:read"],
  "expires_at": "2027-06-09T00:00:00Z"
}

Data residency

Enterprise plans can select a data residency region: US, EU, or APAC. All compute, storage, and audit log persistence is confined to the selected region. Region selection is made at organization creation and cannot be changed after data is written.

Changelog

June 2026 — Modules GA

• Requirements, Blueprints, Work Orders, and Auditor released as generally available modules.
• Full state machine enforcement with Slack-native approval gates.
• Semantic deduplication for Requirements (cosine similarity ≥ 0.85).
• OCSF-format Auditor event stream with Splunk, Datadog, and Chronicle sinks.
• Blueprint dependency DAG with circular-dependency detection.

May 2026 — Information Sources

• Codebase indexing for GitHub and GitLab (OAuth and PAT).
• Artifact sources: Confluence, Notion, Google Drive, file upload, public URL.
• Artifact version pinning in Work Order audit trail.
• Credentials scan on repository index.

April 2026 — Signals Expansion

• Signals context attachment in Requirement submissions.
• Metric enrichment automatically prepended to acceptance criteria.
• Work Order completion telemetry feeds Signals cycle time and throughput metrics.

March 2026 — Maestro v2

• Maestro rewritten as a standalone orchestration service with a versioned REST API.
• Per-agent authorization policy overlays.
• Sandbox mode for agent validation before production promotion.
• Live execution trace via streaming API and Slack progress feed.

Roadmap

Items listed here represent planned investment areas. Dates and scope are subject to change.

Near-term — Q3 2026

• Multi-agent Work Orders — coordinate two or more agents on a single Work Order with explicit handoff gates.
• Labor domain module — requirement and blueprint support for workforce planning and scheduling changes.
• Blueprint templates — reusable Blueprint structures for common change patterns (service migration, schema evolution, API versioning).
• Harmony AI export — Harmony query results exportable as Requirements with pre-populated Signals context.

Medium-term — Q4 2026

• Self-healing Work Orders — Shipyard telemetry regression triggers automatic remediation Work Order creation.
• Compliance profiles — SOC 2 Type II and ISO 27001 report generation from Auditor event stream.
• AI displacement reporting — Work Order completion data feeds labor displacement and ROI metrics in Signals.

Longer-term — 2027

• Predictive effort estimation — ML model trained on historical Work Order cycle times per technology domain.
• Federation — cross-organization Blueprint sharing with isolated execution and separate audit namespaces.
• External agent registry — register agents built on third-party frameworks (LangChain, CrewAI, AutoGen) under Maestro's authorization policy.

Glossary

• Agent — A bounded AI process with a defined capability type, governed by Maestro's authorization policy. Agents cannot escalate their own permissions.
• Artifact Source — An external document or file (Confluence page, Notion database, Drive file, upload) indexed and versioned for use as agent context during spec generation.
• Auditor — The read-only module that records every system event into an append-only, hash-chained log and exports to SIEM.
• Authorization Policy — A version-controlled YAML document mapping action classes to authorization tiers: auto, requires_approval, or blocked.
• Blueprint — A decomposed, dependency-ordered set of tasks derived from one or more approved Requirements. Blueprints produce Work Orders.
• Capability Tag — One of eight defined scopes that limits what a registered agent is allowed to attempt: code_generation, code_review, test_generation, data_query, external_communication, spec_generation, blueprint_decomposition, deployment.
• Closed Loop — The full cycle: Signals intelligence → Maestro authorization → Shipyard execution → telemetry feedback → Signals update. The loop closes when execution outcomes update the metrics that triggered the requirement.
• Conductor — The Thrasoz role with full administrative access, including authorization policy modification and final override on any Work Order.
• Fleet — The collection of all registered agents in an organization, managed and monitored via the Orchestra View in Maestro.
• Harmony AI — The natural language query interface to Signals data. Surfaced via Slack and the Maestro web dashboard.
• Information Gap — The latency between a business event and the moment the person who needs to act on it learns about it. Thrasoz's purpose is to close this gap.
• Maestro — The orchestration layer. Receives Signals intelligence, routes human approvals, and dispatches Work Orders to Shipyard.
• OCSF — Open Cybersecurity Schema Framework. The event format used by the Auditor for SIEM export.
• Player — The Thrasoz role for contributors. Can submit Requirements and create Work Orders; cannot approve anything.
• Requirement — A validated, enriched statement of intended system behavior. The entry point for all work in the Software Factory.
• Risk Tier — The classification assigned to a Blueprint task or Work Order: read-only, data-mutation, deployment, or infra-change. Determines the approval gate required.
• Section Lead — The Thrasoz role for operational approvers. Can approve Work Orders up to the deployment tier.
• Shipyard — The execution engine. Receives approved Work Order specs, runs agents, manages multi-repo pipelines, and feeds telemetry back to Signals.
• Signals — The observability and intelligence layer. Ingests operational data from 15+ sources, surfaces anomalies, and enriches Requirements with live metric context.
• Work Order — The atomic unit of the Software Factory: a requirement + spec + authorization record + execution trace. Nothing executes without one.

Support

Community

The Thrasoz community forum is the first stop for questions about configuration, agent training, and workflow design. Search before posting — most configuration questions are already answered.

Direct support

Submit a support request from within the product using the /thrasoz support Slack command or by emailing [email protected]. Include your organization slug, the affected Work Order or Blueprint ID, and the error message or unexpected behavior observed.

Enterprise

Enterprise plan customers are assigned a dedicated Customer Success Manager. Your CSM is the escalation path for P1 incidents, onboarding assistance, and custom integration requirements. Contact your CSM directly via the dedicated Slack channel provisioned at contract start.

SLA tiers

• Starter — No SLA. Community forum and documentation only.
• Scale — 1 business day response on critical issues (system unavailable, data loss risk).
• Enterprise — 2-hour response on P1 (system unavailable); 1 business day on P2 (degraded, workaround exists); 3 business days on P3 (non-critical).