Abada 1.1.0-rc.1

Abada 1.1.0-rc.1 release notes

Released 2026-10-04 — evaluation release candidate for milestone M2 Real
process shapes (roadmap docs/development/roadmap.md;
gate report 1.1-rc.1-gate-report-2026-10-04.md).
Upgrade the engine, Studio and the Agent Worker together; see each section's
Upgrade and Rollback notes and docs/operations/upgrading.md.

One APL contract (E1)

APL now has a single machine-readable contract owned by the engine: the JSON
Schema engine/src/main/resources/apl/apl-v1.schema.json. Studio's APL types
are generated from it, and two additive endpoints expose it:

• GET /api/v1/apl/schema serves the schema with this deployment's allowed
  agent models and runtime settings.
• POST /api/v1/apl/validate validates a draft exactly as deployment would,
  without persisting anything, and returns every issue with a JSON Pointer
  path and node id.

Validation now reports every error in every node instead of stopping at the
first one. REST API v1 stays backward compatible: the endpoints, the
validationIssues field of a project deploy response and the path field of
validation issues are additive.

New warnings — action recommended before 1.1.0

Documents that deployed before still deploy, but deployment and validation
can now return warnings:

Code	Example	What to do
ABADA-APL-SCHEMA-001	confidence_treshold: 80 (typo, previously ignored); temperature: hot (previously defaulted to 0.2 silently)	Fix the field name or value
ABADA-APL-VARIABLE-001	a condition reads scoring.value but scoring is only written downstream	Declare the variable in metadata.variables or fix the name
ABADA-APL-VARIABLE-001	a decision-table when rule reads amount, which is not a table input	Add the input or fix the rule; it would fail at runtime

At 1.1.0, schema violations become deployment errors. Validate existing
documents now:

curl -s -X POST "$ABADA_URL/api/v1/apl/validate" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  --data "$(jq -Rs '{source: .}' my-process.apl.yaml)"

Typed variable declarations

metadata.variables (optional) declares the variables expressions may read:
the start payload and anything written by engine-task, script or
human-input nodes. Declaring it enables the unknown-identifier check.
Declarations are not yet enforced on the start payload.

Behavior changes

• Agent-model allow-list: APL authoring and Insight proposal validation now
  honor abada.agent.allowed-models (ABADA_AGENT_ALLOWED_MODELS). They used
  the built-in default list before, so an engine configured with other models
  could generate candidates that failed at deployment.
• Studio validates in the APL editor and before Deploy & Start through the
  engine, lists each issue against its node, and reads the model list and
  field bounds from the engine. Its own copies had drifted: the temperature
  slider stopped at 1 and attempts at 10, where the engine accepts 2 and 20.
• A condition rule written else: <node id> without then now renders its
  edge in Studio; it was drawn to an undefined target before.

Documentation

• human-input is documented as the canonical human task node; approval-gate
  remains a deprecated alias that does not read formKey.
• docs/reference/apl-specification.md §2.1, §5.3 and §6.1;
  docs/reference/apl-node-reference.md §4.6; docs/reference/api-v1.md.

Execution tokens (E2)

Tokens — the threads of execution inside a process instance — are now rows in
a new process_tokens table (Flyway V23) instead of a list of activity ids
in a JSON column. Each token has a stable id, a parent and a scope; joins count
token ids; tasks, external tasks, timer jobs and subscriptions record the
token they resume. This is the foundation for bounded loops (E3), boundary
events (E4), child processes (E20) and for-each (E21).

Behavior changes

• Fix: branches meeting at a join in the same step are all counted. In
  1.0.0-rc.8, when two branches of a parallel or inclusive fork reached their
  join without stopping at a wait state (for example two decision tables or
  scripts), the second arrival was dropped. The instance was reported
  COMPLETED but the steps after the join never ran. They run now.
• A branch that ends before the join no longer blocks it. A fork branch
  that reaches an end event inside the fork scope stops counting toward the
  join; the join fires when the remaining branches arrive. In rc.8 such an
  instance completed without running the steps after the join.
• Merges. A parallel or inclusive gateway with several incoming flows but
  no fork in scope fires after one arrival per incoming stream, or with the
  arrivals it has once no other token can still reach it.
• GET /v1/process-instances/{id}/activity-instances (and the project-scoped
  variant) returns the token id as executionId instead of a synthetic
  exec-<instance id> value.

Upgrade

• V23 only adds a table, four nullable columns and indexes; existing rows are
  not rewritten. Stop all replicas for the upgrade as for any schema change.
• Instances in flight are converted from the stored JSON state on the first
  command that touches them. Work created before the upgrade resumes by
  activity. A recorded join whose expectation does not match the branches
  found is converted anyway and logged (Converting tokens of process instance …); such an instance was already stuck in rc.8.

Rollback

The engine keeps writing current_activity_id, active_tokens_json and the
two join columns through the 1.1.0-rc line, so the 1.0.0-rc.8 images can run
against an upgraded database without a restore. rc.8 ignores the new table
and columns. Upgrading again after rc.8 advanced instances is safe: token rows
that no longer match the legacy columns are rebuilt from them, and a warning is
logged. The legacy columns are removed after 1.1.0.

Bounded loops (E3)

A process can now go back to an earlier step — a reviewer rejects a draft and
the agent writes it again — but never without a limit. The step a cycle
returns to declares loop: { max_iterations: 3, on_exhausted: escalate } in
APL, or abada:maxIterations="3" abada:onExhausted="escalate" in BPMN. The
current pass is the variable <step>_iteration. Past the limit the token
continues at on_exhausted; without it the token stops and an operator
incident opens (GET /v1/projects/{id}/incidents,
GET /v1/process-instances/{id}/incidents). An operator retries it — the
token starts a fresh pass — or cancels the instance. Passes are counted per
token (Flyway V25), so parallel branches looping on one step are bounded
independently.

Flyway V24 adds the incidents table, the INCIDENT token state and drops
the one-subscription-per-activity constraint so a wait inside a loop can be
armed again.

Behavior changes — action required for some BPMN imports

• Unbounded BPMN cycles are rejected at deployment (ABADA-BPMN-LOOP-001).
  rc.8 accepted them and could loop forever. Add abada:maxIterations (and
  usually abada:onExhausted) to the node each cycle returns to. Definitions
  already deployed keep running unchanged; the rule applies to new deployments.
• standardLoopCharacteristics and multiInstanceLoopCharacteristics are
  rejected. rc.8 accepted them and ran the activity once.
• A message or signal catch reached a second time by the same instance (for
  example after a BPMN loop) is subscribed again; rc.8 skipped the second
  subscription and the instance waited forever. A timer that loops to itself
  is rescheduled.
• A message wait without a correlationKey variable now opens a
  MISSING_CORRELATION_KEY incident instead of logging a warning and waiting
  forever. Set the variable and retry the incident.
• An agent step that succeeds clears <step>_raw_output and
  <step>_error_code left by an earlier failed pass.
• Studio keeps APL fields it does not edit (including loop,
  metadata.variables and metadata.description) when it saves a document;
  earlier versions dropped them.

Rollback

1.0.0-rc.8 can run on a V24/V25 database: it ignores the incidents table,
the loop_counts column and the new column values. It does not know bounded loops, however: an instance
stopped by an exhausted loop shows no waiting step to rc.8 and never moves
again, and a process whose cycle rc.8 runs is no longer bounded. Cancel
instances with open loop incidents before rolling back, or restore the
pre-upgrade backup.

Boundaries, service levels and model fallback (E4)

Waiting steps get real boundaries. agent, engine-task and human-input
may declare on_error and an interrupting on_timeout: { after, then }; when
one fires the step's work is cancelled in the same transaction and the token
continues at the target (BOUNDARY_TAKEN in history). Human tasks get an
enforced service level: past sla_hours the open task is escalated in place
(escalate_to groups added, TASK_SLA_BREACHED emitted). BPMN imports gain
interrupting timer and error boundary events on user and external service
tasks, plus abada:slaHours / abada:escalateTo.

Agents keep running through rate limits: fallback_models (checked against
the allow-list at deployment) are tried only while the model before is
unavailable, and when every model is unavailable the attempt is deferred
without consuming max_attempts (EXTERNAL_TASK_DEFERRED, growing delay,
bounded by abada.agent.max-deferrals and abada.agent.max-deferral-delay).
Operators can retry a failed agent task on another allowed model with a
recorded reason.

Flyway V26 adds job kinds (job_kind, boundary_id), tasks.due_at and
escalated_at, and external_tasks.model_override and deferrals.

Behavior chan...

Abada 1.0.0-rc.8

Abada 1.0.0-rc.8 release notes

1.0.0-rc.8 is a fix release on top of 1.0.0-rc.7. It makes the AI
provider keys saved in Studio the single configuration for agent tasks,
Insight and APL authoring, shows agent errors with their stack traces, adds
Studio undo/redo, and lets the agent worker survive a host reboot.

The engine adds Flyway V22 (ai_providers) and new additive endpoints;
REST API v1 and worker protocol v1 stay backward compatible.

Status: prepared. Evidence: docs/development/1.0-rc.8-gate-report-2026-10-01.md.

AI provider keys from Studio

In 1.0.0-rc.7 a key saved in Studio → Settings reached Insight but never the
agent worker, which read only its own ABADA_AGENT_LLM_* variables: agent
tasks failed with AgentConfigurationException although the engine had let
the process start. 1.0.0-rc.8 makes Studio the place to configure models.

• Several providers. Settings → AI Providers adds Google Gemini, OpenAI,
  Anthropic, DeepSeek, OpenRouter or any OpenAI-compatible gateway, each with
  its own encrypted key, base URL, default model and the model prefixes routed
  to it. One provider is marked Used by Insight.
• One configuration. Agent tasks, Insight and APL authoring use the same
  providers. A key saved in Studio takes precedence over the engine's
  environment variables, which remain a developer fallback:
  ABADA_LLM_<PROVIDER>_API_KEY per provider, or ABADA_LLM_API_KEY with
  ABADA_LLM_BASE_URL, ABADA_LLM_MODEL and the new ABADA_LLM_PROVIDER.
• The worker asks the engine. GET /v1/workers/me/ai-credentials returns
  the resolved keys to worker principals registered for abada:agent only
  (not to administrators), with Cache-Control: no-store. The worker caches
  them for ABADA_AGENT_CREDENTIALS_TTL_MS (default 60 s) and refetches after
  a provider rejects a key, so a key rotated in Studio applies without a
  restart. Its own ABADA_AGENT_LLM_* / ABADA_AGENT_OPENAI_* variables are
  deprecated and only used for models the engine does not serve.
• Honest start checks. A model routes to the provider with the longest
  matching prefix; a model no provider serves is never guessed. The engine
  refuses to start a process whose agent models have no provider and names
  them; Studio's Deploy & Start and Dry Run check the same through
  GET /v1/ai-providers/status.
• Encrypted with your own key. No deployment file passed
  ABADA_ENCRYPTION_KEY before, so Studio keys were encrypted with the
  engine's public development key. up server now generates the key,
  production preflight requires it, and the engine re-encrypts keys saved
  under the development key at startup.
• A clear default. The top of Settings → AI Providers picks the default
  provider and model used by Insight, APL authoring and new agent nodes, shows
  what is in use and warns when the chosen provider has no key. Each provider
  says where its key comes from and which models it serves. A provider saved
  in Studio keeps its settings when its key comes from the server, and a
  provider disabled in Studio is not used.
• Gemini's base URL is normalised to its OpenAI-compatible /v1beta/openai
  surface, fixing the Studio connection test against Gemini.
• New API: /v1/ai-providers (list, save, remove, test, status).
  /v1/insight/config/ai and /llm remain as compatibility views of the
  Insight provider. Reference: docs/reference/ai-providers.md.

Agent error details

• A failed agent attempt used to show only its error type
  (AgentConfigurationException). The worker now reports the full stack trace
  with its cause chain (capped at 16 KB), after removing provider keys,
  engine credentials, bearer tokens, Authorization headers and key-like fields.
• Studio's instance inspector shows the error message and a Details button;
  Job failed events and failed engine-task jobs open the same dialog, with
  the attempt, model, worker, job status, the stack trace and Copy details.
• New GET /v1/projects/{projectId}/jobs/{jobId}/error returns the last
  message and stack trace, also while the job is still retrying (the incident
  list only shows exhausted jobs). Only the latest attempt's trace is stored.
• Fixed: Studio read the job list's jobId as id, so Retry on a failed
  engine-task job sent undefined; a node's error message could come from
  another instance's job.

Studio undo and redo

• Every edit of the open process can be undone and redone: Cmd/Ctrl+Z,
  Shift+Cmd/Ctrl+Z or Ctrl+Y, and Undo/Redo buttons in the canvas toolbar.
  This covers node and edge edits, moves, node and process properties,
  auto-layout, APL Apply and adopted AI proposals.
• A drag, arrow nudges or typing in one field within 600 ms is one step;
  history keeps 100 steps per process for the session and survives the first
  save of a draft. Undo restores content only (never ids, revision or the
  process key) and is autosaved like any edit.
• Text fields keep their native undo, and the APL editor's Tab key no longer
  breaks it.

Agent worker

• Startup registration survives a host reboot. After a reboot Docker
  starts every container at once and does not honour depends_on, so the
  worker could call the engine and the OIDC token endpoint before they were
  ready. Up to 1.0.0-rc.7 it then exited and relied on the container restart
  policy (the demo VM showed nine restarts before registration). The worker
  now retries transient failures of PUT /v1/workers/me and of the token
  request it triggers: no connection, a timeout, or HTTP 408, 429 or 5xx.
  Delays grow exponentially from 1 to 30 seconds with jitter.
• Rejected credentials (401/403), invalid capabilities (400) and other
  configuration errors still stop the worker on the first attempt.
• Each retry logs agent_startup_retry with the source (engine or OIDC), HTTP
  status and error code; tokens, secrets and response bodies are never
  logged. A worker that exhausts its budget logs agent_startup_gave_up and
  exits with the last error.
• The worker SDK (abada-worker-client) is unchanged; the retry policy lives
  in the first-party worker.

New setting

Variable	Default	Meaning
ABADA_AGENT_STARTUP_RETRY_MS	300000 (0-3600000)	How long startup registration retries transient failures; 0 exits on the first failure (the 1.0.0-rc.7 behaviour)

Upgrade

• Flyway V22 creates ai_providers and copies the rc.7 Studio key into it
  as the Insight provider. ai_provider_settings is kept, unused.
• Server profile: up server adds a generated ABADA_ENCRYPTION_KEY to
  .env.server. Back it up with the file; changing it later makes saved keys
  unreadable. Production: set ABADA_ENCRYPTION_KEY
  (openssl rand -base64 32) before upgrading; preflight rejects a missing key.
• Existing env files keep working: the engine reads the rc.7
  ABADA_AGENT_LLM_* / ABADA_AGENT_OPENAI_* pairs as providers and logs a
  deprecation warning. Move keys to Studio, or to ABADA_LLM_<PROVIDER>_API_KEY.
• The installer writes an optional Gemini key to ABADA_LLM_GEMINI_API_KEY.

Rollback

1.0.0-rc.7 can start against the upgraded database: V22 only adds a
table. Keys added or changed in Studio after the upgrade are not visible to
rc.7, which reads the old ai_provider_settings row. That row is still
encrypted with the development key, so for rc.7 to read it, also remove
ABADA_ENCRYPTION_KEY from the env file (or re-enter the key in rc.7 Studio).

Abada 1.0.0-rc.7

Abada 1.0.0-rc.7 release notes

1.0.0-rc.7 is a Studio and packaging candidate on top of the M1
"truth and safety" release (1.0.0-rc.6). It redraws the process canvas in
BPMN notation with ELK auto-layout, fixes four canvas defects, stops Studio
from contacting Google Fonts, restyles the development login page and ships
the licence text with every artifact.

The engine runtime, database schema, REST API v1 and external-worker
protocol v1 are unchanged from 1.0.0-rc.6; only version strings changed in
the engine, SDK and agent worker.

Status: GO signed off 2026-09-28; not yet published. Evidence and image digests:
docs/development/1.0-rc.7-gate-report-2026-09-28.md.

Studio

Process canvas

• BPMN notation. Events are circles (thin start ring, thick end ring,
  double ring for timer, message and signal catches); gateways are diamonds
  with their X / + / O / pentagon markers. Activities are fixed-size cards
  with a type accent, icon, a two-line title and one key fact.
• Outcome routes (on_error, on_low_confidence, on_invalid_output)
  leave from boundary markers as dashed, colour-coded edges. Default flows
  carry the BPMN slash, and condition labels drop the ${} wrapper.
• ELK auto-layout replaces dagre: Horizontal, Vertical and Tidy modes from
  a canvas toolbar. Layout runs in a Web Worker with a 5-second timeout and is
  deterministic; loops are routed around the main flow.
• Saved positions are respected. A process with APL ui positions opens
  as it was saved instead of being re-laid-out every session.
• Overview minimap (on by default above 12 nodes), alignment guides with
  centre-line snapping, and shortcuts while the canvas has focus: Shift+L
  re-applies the layout, Shift+1 fits the view, arrow keys nudge the
  selected node (Shift for larger steps).
• The AI diff review graph uses the same shapes and layout (view only).

Fixes

• Edges had no direction arrows: React Flow 12 read the marker value as an
  id. Edges now use per-canvas, colour-matched markers.
• Inclusive fork branches were not drawn, and saving from the canvas dropped
  the fork's rules. Each rule is now a labelled branch edge.
• On a running instance, every outcome route lit up because its target was
  visited on the normal path. Outcome routes now light only when history
  records that outcome.
• A clean checkout failed type-checking (and the Studio image build) because
  a test imported an untracked sample file. The unused sample workflows and
  AI-diff demo generator are removed.

Self-hosting

• Studio no longer contacts fonts.googleapis.com or fonts.gstatic.com.
  Inter is bundled from @fontsource/inter (OFL-1.1) and served by Studio;
  the unused Outfit font is dropped. Rendering is unchanged.
• Studio, the documentation site and the login page use the Abada mark
  instead of the Vite template logo.

Development login page

• The bundled development Keycloak realm uses an abada login theme that
  matches Studio. The dev stack mounts it and the release archive ships it
  under docker/keycloak/themes/abada.
• Keycloak imports realm-dev.json only into an empty database, so the dev
  launcher (release/abada-platform and release/abada-platform.ps1) now also
  sets the theme on an existing abada-dev realm after every start. The
  update is idempotent and only warns on failure.

Production deployments use your own OIDC provider and are not affected.

Packaging

• The release archive contains LICENSE, and all four images contain it at
  /licenses/LICENSE. This closes the gap recorded in the rc.6 gate report.

• The engine and documentation images now build from the repository root,
  like Studio and the agent worker, because that is the only build context
  that contains LICENSE. If you build images yourself, run from the
  repository root:

  docker build -f engine/Dockerfile.prod.engine -t abada-engine:local .
  docker build -f documentation/Dockerfile.prod -t abada-docs:local .

  scripts/dev/up.sh, scripts/dev/rebuild.sh and
  scripts/prod/build-prod.sh are updated.

Single-VM server profile

A new server profile runs the whole platform on one public VM, for example
a live demo at demo.abadaplatform.com:

./release/abada-platform up server

• compose.server.yaml derives every hostname from one ABADA_DOMAIN:
  Studio at the domain (with /api on the same origin), the engine at api.,
  Keycloak at auth. and the docs at docs.. Traefik obtains Let's Encrypt
  certificates; only ports 80 and 443 are published.
• Keycloak runs in production mode (start, edge proxy) and imports
  realm-server.json, which contains no users, secrets or URLs. The launcher
  generates every secret into .env.server, applies the domain and client
  secret, and creates the alice operator and bob reviewer accounts used by
  the AI Lead Triage starter.
• The engine and agent worker reach Keycloak over the private network, and
  tokens still carry the public HTTPS issuer.
• deployment/gcp/startup.sh bootstraps a Debian or Ubuntu Compute Engine VM:
  it installs Docker, downloads and verifies the release bundle and prepares
  .env.server from instance metadata. docs/operations/gcp-vm.md covers
  the VM, firewall, DNS, backup, upgrade and public-demo procedures.
• quickstart.sh accepts ABADA_PROFILE=server (installs and prepares
  .env.server without starting). The PowerShell launcher does not support
  the server profile.

The dev and prod profiles are unchanged. The server profile is
single-host and is not a multi-replica or high-availability deployment; the
public reference-host smoke test is pending (see the deployment matrix).

Dependency updates

• Studio: elkjs 0.12 replaces dagre and @types/dagre;
  @fontsource/inter 5.3 added. No engine, SDK or agent-worker dependency
  changed.

Upgrade

1. Back up the PostgreSQL database (standard practice; this release adds no
   migration).
2. Pull the four exact 1.0.0-rc.7 image tags and recreate the stack. The
   schema stays at V21.

Instances, definitions, tasks and history are untouched. Processes saved
without ui positions are laid out once when first opened in Studio.

Rollback

No schema changed, so you can start the 1.0.0-rc.6 images again against the
same database. Positions saved from the rc.7 canvas stay in the APL ui
block and rc.6 Studio ignores them.

Known limitations and deferred work

All limitations of 1.0.0-rc.6 still apply:

• on_low_confidence, on_invalid_output and on_error compile to a
  synthetic exclusive gateway (<nodeId>__outcome), not to boundary events.
  The canvas draws them as boundary markers for readability. Real boundary
  events, bounded loops and enforced SLAs are scheduled for 1.1.0-rc.1 (M2).
• sla_hours is a monitoring hint and is not enforced.
• Agent tools (MCP), journaled agent steps and per-instance cost are not in
  this release (M3).
• Model calls and other external side effects are at-least-once.
• The deferrals of the rc.5 evaluation scope still apply: public-cloud
  production certification, external-OIDC/TLS reference host, rolling
  upgrades, live telemetry certification, Windows quickstart CI and
  independent security review.

Abada 1.0.0-rc.6

Abada 1.0.0-rc.6 release notes

1.0.0-rc.6 is the M1 "truth and safety" candidate. It closes the security
and correctness findings of the September 2026 review. See
docs/development/roadmap.md and docs/development/m1-task-specs.md.

Status: approved for publication on 2026-09-23 (GO, conditional on the tag
workflow). Evidence: docs/development/1.0-rc.6-gate-report-2026-09-23.md.

Licence change

From 1.0.0-rc.6, Abada is licensed under the GNU Affero General Public
License v3.0 only (AGPL-3.0-only); see LICENSE. The Java worker SDK
(sdk/java) is licensed under the Apache License 2.0 so that workers built
on it carry no AGPL obligations. Releases up to and including 1.0.0-rc.5
were published under the MIT License, and that grant still applies to them.

The repository is public at https://github.com/bashizip/abada-platform
(formerly bashizip/abada-engine; GitHub redirects the old URL). Image names
on GHCR are unchanged.

Breaking changes

Expressions are CEL (T1, T2)

Gateway conditions, decision-table rules and decision-table input expressions
are now evaluated with CEL instead of a JavaScript engine. CEL cannot reach
the JVM.

• Common forms keep working: ${riskLevel == 'LOW'},
  score >= 750 and income >= 60000, ${!approved},
  ${path == 'C' || path == 'CD'}, applicant.creditScore > 700.
• JavaScript-only syntax (===, functions, assignments, Java.type) is
  rejected at deployment with the node id.
• A condition that cannot be evaluated (missing variable, missing map key,
  type mismatch, non-boolean result) now fails the command with
  ABADA-RUNTIME-EXPRESSION-001 (HTTP 422 EXPRESSION_EVALUATION_FAILED)
  instead of silently taking the default flow. Test optional fields with
  has(order.discountCode).
• Before upgrading, run abada expressions check <folder> (engine JAR CLI) to
  list expressions that need changes. Definitions that are already deployed
  keep loading; an incompatible expression fails loudly when it is reached.

Before (JavaScript)	After (CEL)
amount === 5	amount == 5
typeof x !== 'undefined' && x > 1	has(data.x) && data.x > 1 (for map fields)
list.indexOf('a') >= 0	'a' in list
name.toUpperCase() == 'A'	name == 'A' || name == 'a'

Script tasks and Java delegates need operator opt-in (T1)

• Script tasks are rejected at deployment unless ABADA_SCRIPTS_ENABLED=true
  (the dev profile enables it; production defaults to off). Enabled scripts
  run in a sandbox without Java access; variables go in and out as JSON.
• BPMN camunda:class delegates must be listed in
  ABADA_DELEGATES_ALLOWED_CLASSES (comma-separated).

The engine enforces the agent output contract (T4-T7)

• An agent completion may write only its result_variable. The value must
  match output_schema, and with confidence_threshold above 0 it must carry
  a numeric _confidence that meets it. A missing _confidence now fails
  the threshold: agents that set a threshold must return a JSON object
  (declare output_schema). The worker no longer gates confidence locally.
• New routes on agent: on_low_confidence, on_invalid_output; and on
  agent and engine-task: on_error (single target, or per error code).
  Without a route, a rejected result is a failed attempt (retries, then
  incident).
• Agents receive only their declared inputs. When inputs is omitted, the
  engine derives them from ${path} placeholders in the prompt. Placeholders
  that are not declared inputs are rejected at deployment. Nested paths such as
  ${lead.companySize} now render.
• Workflow data never enters the model's system message.
• Token usage (promptTokens, completionTokens) is recorded per attempt.
• Flyway V21 adds external_tasks.agent_outcome.

Migrating an agent that returned plain text under a confidence threshold:

result_variable: lead_priority
output_schema:
  type: object
  required: [priority]
  properties:
    priority: { enum: [HIGH, MEDIUM, LOW] }
confidence_threshold: 85
on_low_confidence: senior-sales-review
# conditions then read ${lead_priority.priority == 'HIGH'}

Studio

• Outcome routes are editable in the agent inspector and drawn as labelled
  edges; they round-trip through APL.
• Studio no longer assigns a default confidence threshold of 85 or default
  tool names to agents; new agents start without a confidence gate.
• Removed inspector fields that had no runtime effect (fallback action, memory
  context, escalation role, dual sign-off). SLA hours are labelled as a
  monitoring hint until enforced SLAs ship.

Fixes

• Engine identity (T11): GET /api/v1/info and the OpenAPI document now
  describe Abada as a runtime for governed AI-driven business processes.
  engine.standard changes from BPMN 2.0 to APL + BPMN 2.0 import. Field
  names and response shape are unchanged; clients that match on the old string
  values must update.

• Agent worker (T3): tasks run concurrently (one virtual thread each,
  bounded by ABADA_AGENT_MAX_TASKS) and keep their locks alive with a
  heartbeat, which removes duplicate model calls when calls are slow. New
  ABADA_AGENT_MAX_TIMEOUT_MS (default 120000) caps descriptor timeouts.

• Heartbeat and completion race (found by the M1 exit demo): a heartbeat
  that committed while the same task's completion request was in flight made
  the completion fail with 409 CONCURRENT_MODIFICATION; the worker then
  recorded the task as failed, and with retries left the retry repeated the
  model call. The engine now reloads the external task under its row lock in
  every external-task command, and the worker stops the heartbeat before
  reporting, retries a 409 completion once with the same idempotency key,
  and never discards a result as a failure because of a conflict.

• Worker identity: the agent worker's default workerId is now
  abada-agent-worker-<hostname>, so replicas no longer share one lock owner.
  Set ABADA_AGENT_WORKER_ID to choose it. Tasks locked under the old shared
  id at upgrade time become available again when their lease expires.

• Release build: the engine image's Maven cache mount is now
  sharing=locked, so the amd64 and arm64 builds no longer race on the Maven
  wrapper download (mvn: not found, exit 127, seen in CI).

• Validation message: a rejected APL or BPMN deployment now says
  "Process definition validation failed". The error code stays
  BPMN_VALIDATION_FAILED because API v1 is frozen.

• APL validation (T8): cycle detection is linear-time; documents with many
  converging branches no longer stall deployment.

New configuration

Variable	Default	Purpose
ABADA_SCRIPTS_ENABLED	false (true in dev)	Allow sandboxed script tasks
ABADA_DELEGATES_ALLOWED_CLASSES	empty	Java delegate classes BPMN may instantiate
ABADA_AGENT_WORKER_ID	abada-agent-worker-<hostname>	Lock-owner id; must differ per replica
ABADA_AGENT_MAX_TASKS	4 (1-50)	Agent tasks one worker runs concurrently
ABADA_AGENT_MAX_TIMEOUT_MS	120000	Upper bound for agent timeout_ms
ABADA_AGENT_STRUCTURED_OUTPUT	json_object	off, json_object or json_schema request format when output_schema is declared

Dependency updates

• Documentation: Astro 7.1.1 → 7.3.4 and js-yaml 4.3.1 → 4.3.2 (fixes
  GHSA-26w7-cxv4-gfx2, GHSA-376h-93r7-7g6f, GHSA-2883-xcg3-v3hh); devalue
  updated transitively (GHSA-9rgm-9g3h-6x36).
• Studio (test tooling only): Vitest and @vitest/coverage-v8 3 → 5 (fixes
  GHSA-82fw-gwwq-j7x9). No runtime dependency changed.

Upgrade

1. Back up the PostgreSQL database.
2. Run abada expressions check <folder> against your APL and BPMN sources and
   fix every reported expression (see the table above). Do the same for
   agents with a confidence_threshold: declare output_schema and return a
   JSON object with _confidence.
3. If you use script tasks or camunda:class delegates, set
   ABADA_SCRIPTS_ENABLED=true or ABADA_DELEGATES_ALLOWED_CLASSES before
   deploying.
4. Pull the four exact 1.0.0-rc.6 image tags and recreate the stack. Flyway
   applies V21 (one nullable column) on startup. Upgrades from every prior
   schema version (V1-V20) are covered by the PostgreSQL upgrade tests.

REST API v1 and external-worker protocol v1 keep their shapes. Their
behaviour changes where the contract is now enforced: agent completions that
write variables other than result_variable, or fail the output contract, are
rejected instead of accepted.

Instances already running keep their definition version. An incompatible
expression in such a definition fails the command with
ABADA-RUNTIME-EXPRESSION-001 when it is reached. Redeploy a corrected
version and migrate or cancel those instances.

Rollback

V21 is additive, but rc.5 would evaluate conditions with JavaScript again and
accept agent output the engine now rejects. Roll back by restoring the backup
taken before the upgrade, then starting the rc.5 images. Work done on rc.6
after the backup is lost.

Known limitations and deferred work

• on_low_confidence, on_invalid_output and on_error compile to a
  synthetic exclusive gateway (<nodeId>__outcome), not to boundary events.
  Real boundary events, bounded loops and enforced SLAs are scheduled for
  1.1.0-rc.1 (M2).
• sla_hours is a monitoring hint and is not enforced.
• Agent tools (MCP), journaled agent steps and per-instance cost are not in
  this release (M3).
• Model calls and other external side effects are at-least-once. The lock
  heartbeat removes duplicate calls caused by slow models; it does not make a
  call exactly-once across a worker crash.
• The deferrals of the rc.5 evaluation scope still apply: public-cloud
  production certification, external-OIDC/TLS reference host, rolling
  upgrades, live telemetry certification, Windows qui...

Abada 1.0.0-rc.5

Abada 1.0.0-rc.5 release notes

Abada 1.0.0-rc.5 prepares the public development installer as a complete
AI-process evaluation experience. A fresh installation validates Gemini before
startup and Studio creates an idempotent Lead Triage starter after the first
authenticated login.

Lead Triage starter

• Studio creates and deploys lead_triage in its own Abada Starter project
  only when the development starter is enabled; unrelated projects remain
  untouched.
• The process combines Gemini classification, deterministic routing, a human
  review task and explicitly labelled local CRM/nurturing acknowledgements.
• The persisted canvas uses the existing deterministic left-to-right layout.
• HIGH, MEDIUM and LOW inputs are available in Deploy & Start. Four LOW runs
  can be started explicitly to generate Insight evidence; they execute
  sequentially with a quota-safe delay and no proposal is approved
  automatically.
• Alice initializes the Starter, while Bob is provisioned as its Viewer and
  the exclusive candidate for HIGH human reviews through the dedicated
  lead-triage-human-reviewer project task group.
• The governed Insight proposal request has a bounded 90-second timeout for
  Gemini responses without changing workflow-agent timeout contracts.

Installer and configuration

The Bash public installer requires a Gemini credential. Interactive installs
read it with hidden input from /dev/tty; automation may provide
ABADA_AGENT_LLM_API_KEY. The installer validates gemini-3.6-flash, stores
the credential only in the untracked mode-0600 .env.dev, and enables the
Agent Worker and Insight Engine. The credential is never bundled into release
artifacts.

New development configuration:

• ABADA_STARTER_WORKFLOW_ENABLED
• ABADA_AGENT_LOCAL_ACK_TOPICS
• ABADA_INSIGHT_INITIAL_DELAY_MS, ABADA_INSIGHT_INTERVAL_MS,
  ABADA_INSIGHT_DRIFT_SECONDS, ABADA_INSIGHT_MIN_FALLBACK_SAMPLES,
  ABADA_INSIGHT_LLM_TIMEOUT_MS, and
  ABADA_INSIGHT_FALLBACK_RATIO_THRESHOLD

ABADA_AGENT_LOCAL_ACK_TOPICS is a development demonstration facility, not a
production integration contract. Production remains opt-in and uses external
OIDC and operator-managed workers.

Upgrade note

RC.5 contains no database migration and does not change REST API v1 or external
worker protocol v1. Pull the four exact RC.5 image tags and recreate the stack.
Existing projects and edited starter documents are not overwritten.

Abada 1.0.0-rc.4

Abada 1.0.0-rc.4 release notes

Abada 1.0.0-rc.4 makes the public installer and first-party agent worker part
of one reproducible release path. It preserves the PostgreSQL runtime, REST API
v1, external-worker protocol v1 and database schema from RC.3.

Permanent public installer distribution

The Linux/macOS installer no longer depends on anonymous access to a private
GitHub repository and no release bundle is copied manually into
install/public/. Versioned bundles and SHA-256 files are published to a
private Cloudflare R2 bucket and exposed through the narrowly scoped public
Worker at install.abadaplatform.com.

A v* tag now performs the whole release transaction in order:

1. publish Engine, Studio, Docs and agent-worker images for linux/amd64 and
   linux/arm64;
2. build the release bundle twice and prove it is reproducible;
3. publish the bundle and checksum to the GitHub release mirror and R2;
4. verify the public checksum and all four anonymous GHCR manifests;
5. run the public installer and start the stack on a clean CI runner; and
6. update /latest only after every preceding check succeeds.

The installer still downloads the checksum separately and verifies SHA-256
before extraction. ABADA_VERSION and ABADA_RELEASE_BASE_URL remain
supported for immutable versions and mirrors. Installer responses retain the
short 300-second cache so fixes propagate quickly; versioned bundles are
immutable and long-lived.

Agent worker starts naturally in development

./scripts/dev/up.sh and ./release/abada-platform up dev now start the
first-party agent worker without an --agent switch. The development launcher
creates or updates the confidential Keycloak client, generates its local
secret when absent, grants the worker group and registers the global
abada:agent capability before starting the service.

The release workflow publishes
ghcr.io/bashizip/abada-agent-worker:1.0.0-rc.4 alongside the other platform
images and refuses to promote the release if that image is missing or private.
Provider credentials remain local environment values and are never embedded
in an image, bundle or repository file.

Upgrade

No database migration is required between RC.3 and RC.4.

For a new development installation:

curl -fsSL https://install.abadaplatform.com/install.sh | bash

For an existing production-style installation, back up PostgreSQL, set
ABADA_VERSION=1.0.0-rc.4, run doctor prod, pull the images and recreate the
application services. PostgreSQL volumes remain authoritative; do not delete
them during the upgrade.

Certification boundary

RC.4 remains an evaluation release candidate. The executable Compose and
PostgreSQL/Testcontainers contracts are covered, while public-cloud TLS/OIDC,
multi-host failure, production backup/restore, rolling upgrades, independent
security review and supply-chain attestations remain tracked by the 1.1
infrastructure roadmap.

Abada 1.0.0-rc.3

Abada 1.0.0-rc.3 release notes

Abada 1.0.0-rc.3 makes the human-input loop a first-class, fully working
feature in Studio and completes the platform administration surface. It
preserves the PostgreSQL runtime, REST API v1, external-worker protocol v1 and
database schema from RC.2.

Human-input forms and the Task Inbox

The entire human-input chain now works end to end: author a form, link it to a
human node, deploy, start the process, and work the task in the Studio Task
Inbox.

One identifier, one contract. The stack uses formKey everywhere
(BPMN camunda:formKey, APL formKey, task and task API). A formKey is a
project-unique logical key — a bare slug such as loan-approval — that
resolves to a FORM project resource (forms/loan-approval.json). Forms are
live resources: task clients render the current revision, and editing a form
affects tasks already in flight. The legacy APL formId name remains accepted
on deployment for existing documents.

Engine. New project-scoped endpoints complete the task lifecycle and form
lookup:

• GET /v1/projects/{id}/forms lists the project's FORM resources.
• GET /v1/projects/{id}/forms/{formKey} resolves a key to its schema.
• GET /v1/projects/{id}/tasks/{taskId} plus claim, unclaim and fail
  (alongside the existing list and complete), all with idempotency-key support.
• GET /v1/tasks/mine lists every task visible to the current user across all
  projects, carrying the owning project id.

A user task's formKey is now persisted on the task (previously parsed but
lost at write time) and exposed on the task API, so clients always know which
form a task renders. Deployment never fails on an unresolved form key; it is
reported as a warning so the form can be added after the process is published.

Studio. The human node's form field is now a picker of the project's
forms, with a custom-key fallback and in-place creation of a new form through
the form builder. The form builder gained textarea and date fields plus default
values and placeholders. The Task Inbox lists tasks per project or across
projects, renders the task's form pre-filled from process variables, validates
required and numeric fields, and supports claim, unclaim, complete and fail —
the completion values become process variables by the form field ids.

Studio administration

Studio's Admin tab (renamed from Administration) manages platform users and
groups directly: list/search/create users, enable and disable accounts, assign
and revoke group memberships, create groups, and view project member roles.
The engine proxies the Keycloak Admin REST API server-side using a dedicated
service account; the Keycloak console is never exposed to operators. The view
was redesigned to the Studio design system and now fills the page width, with
modals rendering correctly over the whole viewport.

Keycloak dev realm fix

The dev realm import grants the abada-admin-api service account the
realm-management client roles (manage-users, query-users,
query-groups, view-users, view-groups, manage-groups, view-realm).
Previously the import granted realm roles with those names, which the Admin
REST API ignores, so a fresh environment returned 403 until the roles were
assigned manually. Fresh bootstraps now work with no manual step.

Upgrade

No database migration is required between RC.2 and RC.3.

Download and verify the RC.3 bundle:

curl -fsSLO https://raw.githubusercontent.com/bashizip/abada-engine/main/release/quickstart.sh
chmod +x quickstart.sh
./quickstart.sh 1.0.0-rc.3

For an existing production-style installation, back up PostgreSQL, replace
ABADA_VERSION with 1.0.0-rc.3, run doctor prod, pull the images, and
recreate the application services. PostgreSQL volumes remain authoritative;
do not delete them during the upgrade.

Verification

The candidate is gated by the backend and frontend suites, dependency audits,
OpenAPI compatibility checks, the executable Compose deployment contract, the
checksummed release archive, and multi-architecture image-manifest validation.
The human-input flow is covered by project task lifecycle and form endpoint
tests, and the Studio form renderer by unit tests that pin the
field.id-based variable binding.

Abada 1.0.0-rc.2

Abada 1.0.0-rc.2 release notes

Abada 1.0.0-rc.2 is a corrective release candidate for the self-contained
Compose distribution. It preserves the PostgreSQL runtime, REST API v1,
external-worker protocol v1 and database schema from RC.1 while repairing the
first-run frontend experience.

This is published as a normal GitHub release, not a GitHub prerelease. The
rc.2 version still communicates product maturity: public-cloud production
certification remains deferred to the 1.1 infrastructure track.

Tenda diagram repair

Tenda now renders executable BPMN definitions that do not contain BPMN
Diagram Interchange coordinates. The viewer creates a temporary, vendor-neutral
layout model and reconstructs standard incoming/outgoing sequence-flow
references before generating shapes and connectors. The deployed definition
and engine execution semantics are not modified.

The release also removes the retired diagram-js keyboard binding and displays
an actionable error panel when malformed XML genuinely cannot be rendered.
The bundled approval workflow now includes explicit BPMN-DI coordinates.

The Tenda deployment client uses POST /api/v1/processes/deploy. The obsolete
/api/v1/processes/upload endpoint present in the original RC.1 image is not
used by the RC.2 bundle.

Platform onboarding

The Linux/macOS and PowerShell launchers finish with a structured success
panel containing URLs, health state, telemetry mode, starter identities,
first-run guidance, and exact log and teardown commands.

Development now includes separate starter identities:

Application	Username	Password
Tenda	alice	alice
Orun	orun-admin	orun-admin
Keycloak administration	admin	admin

If Keycloak reuses Alice's session when Orun opens, choose Sign out and
switch account and authenticate as orun-admin.

Service information contract

GET /api/v1/info now returns a typed service-discovery response containing
product and release identity, the documented BPMN support level, PostgreSQL
production persistence, API documentation links and authoritative health
probe links.

The earlier untyped status, profile, host/JVM runtime details and DMN/CMMN
roadmap claims are removed. Clients that treated this informational endpoint
as a health check must use the advertised Actuator liveness or readiness probe.

Image platforms

RC.2 is the first release built and verified for both linux/amd64 and
linux/arm64. The immutable RC.1 images remain amd64-only and continue to use
the launcher's explicit compatibility mode on ARM64 hosts.

Upgrade

No database migration is required between RC.1 and RC.2.

Download and verify the RC.2 bundle:

curl -fsSLO https://raw.githubusercontent.com/bashizip/abada-engine/main/release/quickstart.sh
chmod +x quickstart.sh
./quickstart.sh 1.0.0-rc.2

For an existing production-style installation, back up PostgreSQL, replace
ABADA_VERSION with 1.0.0-rc.2, run doctor prod, pull the images, and
recreate the application services. PostgreSQL volumes remain authoritative;
do not delete them during the upgrade.

Verification

The candidate is gated by the backend and frontend suites, dependency audits,
OpenAPI compatibility checks, the executable Compose deployment contract, the
checksummed release archive, and multi-architecture image-manifest validation.

Abada 1.0.0-rc.1

Abada 1.0.0-rc.1 release notes

This release candidate consolidates platform deployment around PostgreSQL,
external production identity and optional best-effort telemetry. Runtime API
v1, worker protocol v1 and database execution semantics are unchanged.

Validation scope

This is an evaluation prerelease. Its publication evidence consists of the
PostgreSQL/Testcontainers runtime suite, backend and frontend contract checks,
dependency audits, executable Compose configuration and negative preflight
validation, an executable Spring Boot JAR, and the self-contained checksummed
deployment archive.

The production Compose profile is configuration-valid but has not yet been
certified on a public reference host with real TLS and an external OIDC
provider. Multi-host failover, production rolling upgrades, cloud
backup/restore, candidate image attestations and independent security review
remain explicit infrastructure debt in the
1.1 RC Google AI Lab roadmap.
Do not interpret this prerelease as a production availability or hosted-SLA
claim.

Deployment migration

Before	1.0 RC
docker-compose.yml + docker-compose.dev.yml	compose.yaml + compose.dev.yaml
docker-compose.yml + docker-compose.prod.yml	compose.yaml + compose.prod.yaml with .env.prod
generated release/docker-compose.release.yml	checksummed abada-platform-<version>.tar.gz
telemetry/Consul in the base stack	optional compose.telemetry.yaml; Consul removed
development HTTPS and mkcert	local HTTP .localhost routes
repository-relative release assets	every asset included in the versioned archive
frontend VITE_* image build arguments	validated runtime-generated /config.js

Copy release/.env.prod.example, replace every placeholder, then run:

./release/abada-platform doctor prod --env-file .env.prod
./release/abada-platform up prod --env-file .env.prod

Production now fails Compose configuration when required secrets, hostnames,
CORS origins or OIDC settings are absent. Direct JWT validation now requires
the explicit OIDC_AUDIENCE; bundled Keycloak is development-only.

Telemetry

Telemetry defaults to disabled and supplies a no-op tracer for engine command
code. Add the telemetry Compose overlay for the pinned bundled stack or set an
external HTTP(S) OTLP base endpoint. Collector failure cannot affect workflow
readiness or transaction commit; telemetry queues and timeouts are bounded.
Grafana Alloy replaces the end-of-life Promtail agent for file-based log
collection. Alloy reads the named engine log volume without Docker socket
access, persists file positions and runs with anonymous usage reporting
disabled. Existing Promtail position files are not reused; Alloy begins at the
end of existing engine log files and records new offsets in alloy_data.
The bundled stack initializes Jaeger's named Badger volume with a one-shot,
networkless service so the non-root Jaeger process can write its data and key
directories.

Frontend dependency security

The published React Router versions available during RC preparation were all
covered by active client-side or server-feature advisories. Tenda and Orun now
use a deliberately small browser-history router for their existing SPA routes.
This removes unused SSR, RSC, data-router and server-action code from the
frontend dependency surface without changing their public URLs.

Upgrade preparation

Back up and restore-test PostgreSQL before changing the exact ABADA_VERSION.
Verify the new archive checksum, run production preflight, inspect Flyway
startup, then execute a canary workflow. Image rollback does not reverse schema
migrations.

The embedded Java engine/Maven distribution, Kubernetes, hosted SaaS and
multi-tenancy remain deferred beyond 1.0.

Abada 0.11.0-alpha

Abada Engine 0.11.0-alpha Release Notes

Release date: 2026-07-19

Abada 0.11.0-alpha is the stable-contracts and security prerelease. It freezes
the /api/v1 REST surface and external-worker protocol v1, completes backend
RBAC, ships a Java worker client, and aligns Tenda and Orun with durable API
records.

Highlights

• Stable typed DTOs and machine-readable error codes across API failures.
• Executable generated-OpenAPI compatibility checking in CI.
• Bounded database pagination and filters for definitions, instances, tasks,
  incidents and history.
• Explicit deployment, process-control, task, operations and worker
  permissions for OIDC and trusted-proxy modes.
• Negative tests for invalid/expired JWTs, forged proxy headers, role
  boundaries, CORS, logging and cross-user task access.
• Worker protocol v1 with bounded fetch-and-lock, heartbeat, lock extension,
  completion, BPMN error, technical failure/retry, idempotency and trace
  propagation.
• Standalone Java 21 worker SDK under sdk/java.
• Orun now consumes durable audit history and correctly maps incident IDs;
  Tenda types match the frozen engine DTOs.

Database upgrade

Back up PostgreSQL, start one 0.11.0-alpha engine, and allow Flyway to apply
V9. V9 adds nullable BPMN-error and trace-context columns to external_tasks
plus an acquisition/ownership index. No existing row is deleted or rewritten.
Confirm schema version 9 before starting remaining replicas. Downgrade is not
supported; restore the backup to roll back.

Worker migration

Secured deployments now require completion bodies shaped as
{"workerId":"...","variables":{...}}. Raw variable-map completion remains
accepted only in disabled local/test mode. Use the Java worker client or update
existing workers before enabling 0.11 in production.

Boundary BPMN error events remain unsupported. A worker BPMN error is therefore
recorded as an unhandled business error and fails the process instance.

Verification evidence

The release candidate was verified on 2026-07-19 with Java 21, Node.js 24 and
Docker Desktop:

• (cd engine && ./mvnw clean package): passed, 151 tests with no failures,
  errors or skips. PostgreSQL 16 Testcontainers covered fresh Flyway V9 installation,
  upgrades from schemas V1 through V8, restart recovery and multi-replica
  persistence/concurrency behavior.
• engine/mvnw -q -f sdk/java/pom.xml verify: passed for the standalone
  Java worker SDK.
• (cd tenda && npm run lint) and (cd tenda && npm run build): passed.
  ESLint reported nine
  existing React Fast Refresh warnings and no errors; Vite reported a large
  chunk warning.
• (cd orun && npm run build): passed with a large chunk warning. Orun does
  not yet define lint or test scripts.
• npm audit in both Tenda and Orun: passed with zero vulnerabilities.
• The Java SDK uses Jackson 2.21.5, resolving the high- and medium-severity
  advisories GitHub identified during publication.
• Production and release Compose configuration validation: passed. Production
  validation emitted expected warnings for unset local Keycloak/OAuth
  environment variables.
• Production image build: passed for abada-engine:0.11.0-alpha on
  linux/arm64, image ID
  sha256:419060f06f42361c124569d1333705955d299cbe7e35c3d3cd5d4eee6f7a6448.
• Executable JAR:
  engine/target/abada-engine-0.11.0-alpha.jar, SHA-256
  fd8b769027bff379c1316733c9e4864eec571932b921f0ab9212fe276bbe1444.

Non-blocking backend warnings were limited to the existing H2 dialect,
Open-EntityManager-in-View, optional Bean Validation provider, Mockito dynamic
agent attachment and Prometheus meter-tag warnings. These do not invalidate
the PostgreSQL-backed correctness evidence, but should be removed before the
1.0 RC where practical.

Known limitations

• Boundary BPMN error events are not part of the supported BPMN subset.
• Worker effects outside the engine remain at-least-once and must be made
  idempotent by workers.
• The 1.0 RC still requires published conformance, rolling-upgrade, security
  review, benchmark and operational-runbook evidence.