PHPackages                             survos/ai-workflow-bundle - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [API Development](/categories/api)
4. /
5. survos/ai-workflow-bundle

ActiveSymfony-bundle[API Development](/categories/api)

survos/ai-workflow-bundle
=========================

State-bundle workflow primitives for async AI preparation, observation, analysis, and publishing.

2.7.2(1w ago)0311MITPHPPHP ^8.4

Since May 12Pushed 2d agoCompare

[ Source](https://github.com/survos/ai-workflow-bundle)[ Packagist](https://packagist.org/packages/survos/ai-workflow-bundle)[ GitHub Sponsors](https://github.com/kbond)[ RSS](/packages/survos-ai-workflow-bundle/feed)WikiDiscussions main Synced 1w ago

READMEChangelogDependencies (48)Versions (25)Used By (1)

Survos AI Workflow Bundle
=========================

[](#survos-ai-workflow-bundle)

State-bundle workflow primitives for async AI work over any subject.

The bundle defines a small shared lifecycle:

```
new -> prepared -> observed -> analyzed -> reviewed -> published

```

The important split is conceptual:

- `prepare`: make source content and context available.
- `observe`: create neutral evidence from the source. For images this is usually thumbnail observation plus optional high-resolution reads; for text it may be dense summaries, language, or structure.
- `analyze`: apply application meaning to observed evidence and context.
- `review`: app-defined approval after analysis. This can be automatic policy, human review, or another app-specific gate.
- `publish`: project the result into fields, indexes, exports, webhooks, or other app outputs.

The bundle does not decide what those transitions do. Applications provide workflow listeners, task policy, and publishing behavior.

The bundle may define reusable tasks and prompt templates. Treat those as a prompt/task repository, not app policy: applications still decide which tasks to queue, when to append follow-up tasks, and what `publish` means.

Core Classes
------------

[](#core-classes)

- `Workflow\SubjectFlow`: shared state-bundle definition.
- `Contract\WorkflowSubjectInterface`: minimal subject id plus queue/lock shape for entities. Claim subject type defaults to the PHP class name.
- `Task\TaskInterface`: callable workflow task that returns claims.
- `Task\TaskResult`: claims plus optional follow-up tasks.
- `Task\TaskRegistry`: lazy task lookup by name.
- `Task\TaskRunner`: consumes one queued task and records claims through `survos/claims-bundle`.

Task outputs are not stored as opaque JSON result blobs. They are recorded as `ClaimRun` and `Claim` rows. Apps can still denormalize claim projections onto their own entities during `publish`.

Queueing Tasks
--------------

[](#queueing-tasks)

Applications queue and run tasks from workflow listeners. Use task constants instead of string literals so built-in task names stay refactorable:

```