← Back to directory

workflows-and-automation.md

architecture/workflows-and-automation.md · 37.1 KB · 2026-11-02 12:48

Workflows and Automation

Status: settled semantic contract, 2026-09-11; the broader workflow runtime/product surface remains incomplete, while the bounded IDY-007 Slice 1 execution and lease-bound finalization mechanisms are implemented and verified. Deferred wake/recovery, retry/replay, scheduling, integrations, AI execution and other capabilities remain outside that verified slice. Owner: Workflow and Automation/Scheduling reusable execution responsibilities. Examples are illustrative compositions, not a fixed worker API or guaranteed delivery model.

Canonical Prerequisites

The core object model and authority contract supplies the cross-cutting rules for definitions, derived State, authority, non-destructive history and bounded causal execution.

Scope and Invariants

Workflows express business processes as readable, configurable, executable platform data. Definitions and workflow nodes use the universal primitive, as do executions, schedules, jobs, triggers, and outcomes when persistent/addressable. Their type definitions are themselves addressable; none of these categories introduces a bespoke foundational store. All participate in the connected graph with the objects they operate on and the knowledge or policies they reference. Configuration is serialisable, human-readable, AI-readable, schema-validatable, and capable of historical identification. Engines are reusable execution responsibilities, not a requirement for separate services, classes, modules, or queues. Workflow governs process execution; Automation/Scheduling governs when configured work becomes eligible to run. Scheduling work is not the same thing as defining its executable behaviour. Deterministic workflows must operate without AI; explicitly configured AI actions do not transfer runtime control to a provider.

Workflow and Logic as semantic roles

Workflow and Logic are two of the four semantic roles in the shared object model; they are not mutually exclusive application subsystems. A Workflow Object represents a human action or interaction, while a Logic Object represents an automated action or evaluation. A Workflow composition may contain Logic for automated determination and a Logic composition may contain Workflow where a person must supply information or select among ambiguous results. Data Objects can reference Data, Logic, Workflow or Presentation through their current value.

This composition is recursive and uses the one universal Object system: a data-oriented Object may contain Logic, Workflow and Presentation Objects, a workflow-oriented Object may contain Data, Logic and Presentation Objects, and a logic-oriented Object may contain Data, Workflow and Presentation Objects. Contained Objects are not automatically new Types or separate persisted categories; independent identity is governed by the ordinary addressability contract.

Workflow and Logic are not merely automation scripts, and Logic is not a separate rules-engine primitive. Their normal governed execution can assign values and establish, replace, modify or remove object constituents, including a capability becoming part of a Business. Such a change uses the existing validation, authority, Command, mutation, provenance and history boundaries; it does not require a capability-specific assignment mechanism.

This role vocabulary does not replace the infrastructure distinctions in this document. A Workflow Definition is addressable configuration, a Workflow Execution is an identified enactment, and an Action, Command, Attempt or Outcome is an execution record with its own contract. Each continues to use the universal object model where independently addressable. None is an additional semantic business role, and none creates a second workflow or logic storage system.

Dependency resolution is contextual traversal of the relevant object hierarchy. It may expose a human Workflow requirement, identify an authorized Logic reference for an explicit governed operation or report an unavailable dependency; traversal itself does not evaluate or execute Logic. Resolved, legitimately absent, unresolved, incompatible and execution failure remain execution conditions; they are not a universal persisted state taxonomy on Data Objects. A reference remains the Data Object's current value until a governed operation replaces it with a concrete value or another reference. See core object model and authority for the canonical value, Business configuration, Search and replacement examples.

Terminology

| Term | Distinction and ownership | | --- | --- | | Workflow Definition | Versioned addressable process configuration describing steps, triggers, conditions, Action references, transitions and intended outcomes; not a particular run. | | Workflow Step | A configured node/place in a Workflow Definition that describes work or control flow and continuation, and may reference an Action. It is not the reusable Action, a particular visit to the step, an Action Execution or an Attempt. | | Workflow Execution | An identified enactment of a Workflow Definition against inputs and authority context, bound to an explicit definition version, with observable progress and results. | | Command | An addressable request with stable semantic identity; delivery of the request is not the Action Execution or proof of an Effect. | | Event | The addressable representation of an occurrence under Time and events. It records or reports what happened; it is not the Effect itself, an execution instruction, a notification or proof of every downstream Effect. | | Trigger | Configured criterion/source of initiation, such as an eligible event, time occurrence, or metric condition; not the event itself. | | Schedule | Configuration expressing intended timing or recurrence and relevant time context; not the executable business definition. | | Job | A unit of runtime work intended for execution; it may support a workflow action or other engine responsibility, but is not synonymous with a workflow definition. | | Automation | Configured initiation and application of behaviour without a person manually performing every step; composes triggers, conditions, schedules where needed, and actions/workflows. | | Action | A provider-independent semantic request available within a capability. In this foundation its executable contract is an exact-revision Operation Contract; it is not a particular performance. | | Operation | A governed executable action that may belong to or support a Capability; not the broader capability composition or its Operation Contract. | | Operation Contract | An approved, versioned contract for an Operation, interpreted by a fixed trusted handler; it is not the broader Capability, a Command, Policy, AuthorityGrant, Workflow, Action Execution or executable code. See the Operation Contract. | | Action Execution | An identified enactment of an Action in a particular input, Business and authority context; distinct from the Action definition and from individual Attempts. | | Attempt | An individually addressable try within an Action Execution, retaining its own progress, evidence and result. Another try does not erase an earlier Attempt or automatically create another semantic operation. | | Outcome | The recorded result or determination about an Attempt, Action Execution or process, including failure or unknown status. It is neither the intended goal nor automatically proof that an Effect occurred. | | Effect | An actual resulting change or consequence, internal or external. An intended Effect is not yet actual, and an unknown result does not establish either occurrence or absence of the Effect. |

The execution contracts below preserve these distinctions through commit, retries and recovery. Transport delivery is not semantic execution. A Workflow Execution visits Steps in its explicitly bound definition. A Step can reference an exact Operation Contract revision through its Action/invocation binding; its enactment is recorded as an Action Execution, with Attempts and Outcomes linked to that execution and relevant step visit. Reuse, branching and repeated visits do not collapse these identities or imply a universal one-to-one mapping. Effects are the consequences; Events and outcome evidence describe occurrences/results without becoming the consequences themselves. These are semantic distinctions within the universal model, not additional foundational stores.

For the current Action foundation, an Operation Contract provides the executable binding for an Action without creating a parallel Action Type or runtime. Its parameters declare type, label, description, requiredness and source. Sources may be user input, the current Object, related Objects, Business configuration/context, another Action or trusted programmatic invocation. Runtime resolves all non-user sources through authorized reads and exact revisions; presentation does not resolve them. A saved editor action is not automatically any of a workflow execution, schedule, or queued job. A scheduled publication can refer to an action or workflow; the schedule does not contain a second independent execution language.

Definition and Node Contract

The first definition-driven initialization slice represents User and Business initialization (the User being the platform account persisted under the legacy Type name Principal) through the existing Workflow Definition, pinned Node and Workflow Execution objects. The Workflow Execution records the subject instance, exact workflow revision, exact applicable Definition revision, requirement evidence and current progress. Its completion is initialization-specific and does not assert universal Business or User operational completeness.

Initialization input is projected from the Definition's constituent requirements through the existing View/Form boundary. Explicit user input is validated and submitted through an approved Operation and the shared Command boundary. A missing requirement is a visible workflow condition; it is not an unexplained generic execution error, permission to invent data or a second lifecycle state machine. Repeated submission uses deterministic Command identity and existing-object detection, so compatible constituents are reused and ambiguous/incompatible constituents are surfaced for resolution.

A definition identifies relevant triggers, required inputs, conditions, actions, transitions, and outcomes in inspectable configuration. Workflow nodes and other components needing independent identity, reuse, relationships, provenance, history or lifecycle are addressable objects, not opaque fragments of provider text. Values may still contain scalar parameters and nested structures as allowed by their type definitions. Conditions evaluate explicit business data and semantics; unknown or invalid input must not silently become a successful condition. Transitions express the intended continuation or branch, rather than relying on hidden controller order. Humans must be able to inspect and configure definitions, including branches, waits, approval requests, and integration targets. Type validation and action-capability validation precede execution; readable configuration alone does not make a definition valid. Definition editing and permitted activation are distinct concerns; governance determines who may author, approve, and operate them. Workflow Nodes are independently addressable Business-owned objects with retained revisions. Each Workflow Definition revision contains a complete node_bindings set of Node object IDs and exact object revisions, plus one entry_node_id from that set. Node configuration remains Node-owned; the binding is Definition configuration and is not a separate Relationship object. Graph continuation labels inside a Node are resolved only against the Nodes in that exact binding set. Labels are readability aids, not Node identity. A later Node revision cannot change a retained Definition revision or an execution pinned to it. Each execution identifies the definition revision it uses. Resumption does not silently switch to an edited definition; dependency changes require explicit re-evaluation and governed continuation. An explicit migration can establish a new binding for future continuation while preserving execution identity and the complete prior binding history. Editing a definition alone cannot migrate its executions.

Action Vocabulary

The original action breadth is preserved; this list names behaviours, not mandatory software classes.

| Action | Responsibility boundary | | --- | --- | | Create object | Use Object/Data validation and governed creation authority. | | Update object | Validate the target type, intended change, and permitted business transition. | | Relate objects | Use the Relationship contract and authorised endpoints. | | Send communication | Request Communication delivery, retaining result context. | | Create task | Create a typed task and its assignment/subject relationships. | | Wait | Persist the pause and resume the same identified execution under current authority and dependency checks. | | Request approval | Invoke governance-owned approval semantics; a request is not approval. | | Call integration | Invoke an available, validated integration capability with appropriate authority. | | Generate content | Use the Content responsibility, with AI optional rather than implicit. | | Invoke AI | An explicit controlled action subject to AI output validation before further effects. | | Create notification | Request user-facing communication, not a replacement for a canonical event. | | Branch | Select configured continuation using explicit conditions. | | Record outcome | Relate the actual result to its action/process and relevant business subject. |

Publishing content, updating a campaign, and triggering a webhook are compositions of these reusable capabilities. No new engine is needed merely because the same operations now apply to Equipment rather than Campaigns.

Execution and Evidence

Execution inputs include the definition reference, triggering context, subject objects, relevant values, and acting authority. The runtime checks applicable type validity, permission, policy, and approval requirements before effects. It delegates operations to the responsible engine and retains enough result context to explain what occurred. Progress, conditions evaluated, action results, errors, and outcomes should be inspectable by authorised users. Canonical events/history provide change and causality evidence; the workflow document does not redefine Event. An action request, successful local validation, remote acceptance, and completed business outcome must not be conflated. Invalid configuration, denied authority, unmet approval, missing input, and unavailable integration need distinguishable reporting. Partial external success or an uncertain response cannot be labelled total success merely because local execution finished. The following settled contracts control transaction boundaries, resumption and retry eligibility. Their concrete database/dispatcher mechanisms belong to implementation architecture.

The existing Action Execution, Attempt and Outcome records are the execution and result model. Outcome distinguishes successful local simulation from real external effect: a simulated result has explicit simulation mode/status and never implies provider acceptance or delivery. Requested, running, completed, failed, partial and indeterminate/Unknown results retain their applicable execution context; an uncertain external result remains Unknown/Reconciliation until governed evidence resolves it. No parallel execution-result store is introduced.

Mutation Operations produce governed local business-object effects. An external Action may have no local business-object mutation effect; this does not bypass execution control or omit evidence. It resolves and validates the exact Operation and its declared inputs, checks current Business authority, and submits through the same stable-identity CommandHandler. The Command fingerprint binds the Operation ID/revision, validated inputs and resolved source references. Matching duplicate delivery returns the existing result; changed content under that Command identity conflicts. Authorization and the exact active Operation revision are rechecked under the existing coordination boundary before evidence commits. For the current send_email simulation, effects=]; the platform still atomically persists Command and Action Execution, Attempt, explicit simulated/not-sent Outcome, Event and Provenance. The simulation makes no network request and its retained evidence is not proof of delivery. See [Operation Contract, Identity and Governance and Communication and Integrations for their respective contracts.

Dependency Resolution and Bounded Causality

Before a dependent Action executes, the runtime resolves the objects, values, relationships, definitions and configuration conditions required by that Action. It distinguishes a resolved dependency, a legitimately absent or inapplicable dependency, a required but unresolved dependency, an incompatible workflow configuration and an execution failure after resolution. These conditions must not collapse into one generic failure state.

An unresolved dependency is a workflow condition, not permission to invent a value. The configured response may request missing context, invoke a resolution workflow, ask an authorized human, select an explicit alternative or pause the execution. Where useful, the unresolved condition produces an addressable Event containing the operation, required dependency, subject, workflow and causal context. Resolution and any later retry still pass through current authority, validation, Policy and commit checks.

The runtime must impose a finite execution boundary even where static cycle analysis is incomplete. Before continuation, evaluate the causal ancestry and configured execution limit where possible. A detectable cycle is rejected, paused or flagged for authorized human resolution. A cycle discovered during operation pauses the active execution and retains the causal evidence needed to explain the cycle. No workflow may continue indefinitely by recursively triggering further workflows.

The current bounded implementation exposes one sequential step through the existing lease and governed Operation boundaries. A settled generic Command dispatches each committed Event after its transaction commits; rollback does not dispatch. The runner admits matching Workflows idempotently, claims the dispatch lease, resolves exact pinned Workflow Definition and Node revisions, evaluates either the validated workflow expression or an exact logic_reference through the generic Logic evaluator, and rechecks the condition inside the trusted workflow Operation before committing execution progress. This is a bounded execution slice, not evidence of a general worker, scheduler, queue, recovery loop, retry/replay engine or external-effect runtime. The current implementation invokes this runner synchronously from the post-commit Command path; no bin/runtime-dispatch.php entrypoint or general dispatcher is currently available.

An expired claimed lease remains fenced and is not implicitly reclaimed, resumed or replayed. The documented recovery extension is owned by the existing governed Operation -> Command -> authority/Policy -> commit boundary: it quarantines an expired execution into reconciliation_required, preserves the execution and evidence identity, and permits only an explicit authorized terminal or safe-resume decision. Safe resume requires evidence that no consequential Operation or unknown Command remains unresolved; current_node_id and step_count alone are not proof. A local command with an unknown outcome remains in reconciliation and is handled through the existing Command reconciliation path where applicable. This recovery extension is specified and source-implemented in IDY-007C, but authenticated STAGING recovery execution remains unverified.

Executable local_command nodes may pin an exact Business Operation identity and revision. Their validated literal or execution bindings are passed as trusted inputs to the existing Operation Invocation boundary; no workflow handler performs a direct mutation. The current Spearmint demonstrator uses this mechanism for a governed create_enquiry Operation after an exact platform-owned Logic Definition permits the branch. Scheduled and external trigger dispatch remain outside this demonstrated slice.

A condition's Boolean false is a valid branch result, not an execution failure. The persisted false_next continuation determines whether the Workflow ends successfully, ends with a configured failure, waits or enters review. The evaluator and runtime must not classify false as a system failure merely because the selected business branch is negative.

Action Preconditions and Commit Boundary

The authoritative sequence is Prepare -> Validate -> Authorise -> Commit -> Record Outcome. Required state change and required historical evidence commit coherently in durable persistence; the final reporting step is not permission to defer required commit evidence.

Immediately before consequential commit, evaluate against current authoritative state:

An Action waiting to update Project P123 must recheck after another user changes it. A stale incompatible expected version is rejected, never overwritten. A prior UI check, queued payload, approval or valid AI response does not bypass current checks.

No consequential Action is considered committed before the durable boundary. Failed, rejected and stale attempts remain distinct from committed occurrences. Unknown commit status is explicitly Unknown/Reconciliation; it is never guessed as failure or success. A local commit is not a guarantee of atomic remote effects.

Logic may detect a condition, calculate or derive a value, validate an input, classify a state, propose a change or initiate a configured workflow. Workflow governs controlled progression, human decisions and authority. A useful composed pattern is Logic detects -> system explains -> system proposes -> workflow requests authority -> human accepts/rejects -> state changes -> outcome is recorded; sufficiently deterministic, authorized and low-risk operations may omit proposal or approval only where their governing configuration permits it.

The operation's consequence matters independently of whether its local representation is a data mutation. Reversible internal changes, consequential internal changes, external effects and irreversible work may require different approval, execution, reconciliation and provenance treatment. Sending communication, publishing, submitting an order or modifying an external system remains subject to the relevant Communication/Integration and Governance contracts; a successful local workflow step does not establish external success.

Commands, Executions, Attempts and Recovery

A Command is an addressable request with stable semantic identity. Repeated delivery of that same Command does not automatically create a new operation. A consequential Action Execution is addressable; its explicit Attempts identify individual tries. Command, Action definition, Action Execution, Attempt, state-transition occurrence and Outcome must not be conflated.

Safely repeatable Actions have deterministic idempotency semantics. Non-safely-repeatable Actions require reconciliation or governed recovery before repetition. A retry never erases a previous Attempt or changes its identity to conceal duplication. A new attempt is evidence of another try, not automatically a new intended business operation.

Unknown external outcome is distinct from both failure and success. Timeout after possible remote acceptance must remain unknown until evidence or a governed reconciliation determination resolves it; automatically resending can create duplicate effects. Recovery and compensation are explicit, attributable work linked to the original execution.

Persist progress, waits, definition references, Action/Attempt identity and outcomes so recovery resumes the identified execution instead of recreating it from an untrusted delivery. Re-evaluate current authority, applicable Policies, versions and dependencies before continuation. Dependency invalidation can suspend active work or require a new determination; committed Actions remain historical facts.

UI, API, Workflow and AI-originated mutations reference an approved Operation Contract revision where applicable and use the same authoritative Operation -> Command -> Validation -> Authority/Policy -> Commit path. Each entry point establishes attributable caller and Business context; none gets a direct-write exemption.

Before Business-scoped operational execution, the applicable subscription entitlement gate defined by subscriptions and entitlements must be satisfied (intended future architecture; all Businesses are currently treated as active and no entitlement is enforced). Workflow recovery, retries and continuation must not bypass that gate; suspension preserves recorded execution history and does not itself revoke authority.

Workflows and logic have no independent identity or authority; they execute under authority delegated by a User, and the technical executor is execution provenance only (delegated authority for automation). Proposed direction, not settled and not implemented: if a User's delegated authority is removed without a replacement, or is lost (account disabled, User leaves the Business, authority revoked), the affected workflow or logic execution is paused, relevant staff are notified, and a replacement authority is required before it resumes. The detailed rules are open; see identity-and-governance.md.

Migration, Re-entry and Compensation

These are settled execution/recovery semantics, not permission to implement a shortcut that resets history. Resumption continues the identified execution from its recorded progress and explicit definition binding; runtime interruption neither selects a new version nor changes its business outcome.

Migration is an explicit governed change of an existing Workflow Execution's definition-version binding or continuation mapping. It preserves that execution's identity and records the source and target definition versions, source and target continuation/State references, mapping, reason, acting authority, required Decision/Approval and result. Validate target compatibility, inputs, dependencies, State constraints and current Authority/Policy/preconditions through the normal Command/commit boundary. An unsupported or incompatible migration is refused; failure does not silently change the binding.

Commit the new binding and required migration history coherently. Future work uses the newly recorded binding; earlier step visits, Action Executions, Attempts, Events, Effects and Outcomes remain associated with the definition versions and authority actually used. Migration is not retroactive replay, implicit approval reuse, erasure of unfinished/failed work or permission to repeat external Effects.

Re-entry is an explicit governed return to a Step or continuation in an identified Workflow Execution. Record its reason, definition version, entry point, relevant inputs/State, authority and relationship to prior visits. Preserve previous visits and their Action Executions, Attempts and Outcomes rather than clearing them to make the execution appear new. Recheck current dependencies and preconditions before further effects. Re-entry does not by itself authorise another semantic operation: retry of existing work retains its Command/Action Execution identity and idempotency rules; genuinely new work is explicitly identified and linked to its origin.

Starting another Workflow Execution is distinct from re-entering the existing one. Give a genuinely new execution its own identity, explicit definition binding and causal link to prior work when applicable; never relabel or replace the historical execution to conceal the restart.

Compensation is a separate governed operation linked to the original execution and Effects, with its own execution/Attempt/outcome evidence. It may counteract consequences but cannot erase the original committed occurrence or assume an unknown Effect happened. Migration, re-entry and compensation all preserve Unknown/Reconciliation: unsafe or uncertain external work requires reconciliation or governed recovery before repetition.

The initial runtime may defer migration/re-entry support and refuse those requests explicitly. That is an implementation limitation, not unsettled architecture or permission to substitute direct binding edits, destructive resets or blind retries.

Distribution Contract

The initial modular monolith is distribution-ready through explicit Command identities, durable state, version checks, serializable contracts, actor/authority attribution and recoverable executions. Process-local memory or locks cannot become the authority for duplicate suppression or commit. Repeated messages and worker restarts preserve semantic operation identity; technical worker identity is execution provenance only and remains separate from business authority, which is delegated by a User.

These contracts do not require microservices, a message broker or universal exactly-once remote delivery. The first local mutation can execute synchronously; the minimal dispatcher uses the same contracts.

Automation and Scheduling

Automation supports event-based, time-based, and metric-based triggers, using the same governed action surface. Example: post_engagement > threshold can propose or initiate resharing according to policy and the configured conditions. Example: a new blog post can initiate sharing to a permitted channel, rather than introducing a special marketing-only runtime. One-time work, recurrence, and queue-based dispatch are distinct scheduling needs; best-time optimisation is optional later scope. Timing configuration needs an explicit business timezone and any permitted destination-specific override, not a silent server-time assumption. Recurrence interpretation, daylight-saving gaps/overlaps, timezone changes and missed schedules after downtime require explicit configuration and handling. The initial scheduler mechanism supports bounded waits and one-time dispatch; unsupported recurrence is rejected, not silently assigned server-time semantics. Conflicts include duplicate intended actions, posting frequency constraints, external rate limits, and competing rules affecting the same subject. Rule loops and high-frequency triggers need observable handling; the bounded interpreter's limits are implementation parameters, not architectural authority to suppress history or silently skip required work. FIFO and priority queues are possible implementation choices, not universal business ordering guarantees. Scheduler readiness, action readiness, permission, and required approval are separate concerns. A due time is not permission to bypass a content review or execute against unavailable credentials. Background publishing, metric collection, report delivery, and content generation illustrate reusable jobs beyond workflow runs.

Cross-Capability Examples

The Capabilities document owns the full website-enquiry business scenario. Within this contract: a form creates Enquiry and relationships, enquiry.received supplies trigger context, and a workflow evaluates the enquiry. The process can match/create a customer, create an opportunity, assign a task, send confirmation, record interaction, and attach knowledge. Analytics consumes relevant outcomes; optional AI summarisation is an explicit action, not a prerequisite for receiving enquiries. The shared customer remains the same object across the sales view, confirmation communication, and report. Equipment servicing can compose Objects + Types + Relationships + Knowledge + Workflow + Communication + Views. Equipment, Service Contract, Service Event, Technician, and Parts are business vocabulary, not justification for an EquipmentServicingEngine. Specialist route optimisation would require a separate reusable-behaviour assessment, not an automatic engine per new capability.

Human Operation and Counterexamples

Positive: a user configures a post-sale workflow, inspects its conditions and tasks, and runs it with no AI provider. Positive: an approval node exposes the requested decision and resumes only according to the approved governance/execution contract. Positive: an operator sees that a remote publish result is uncertain and can inspect evidence without being told it succeeded. Negative: treating a schedule row as the only workflow definition hides its actions, branches, and business meaning. Negative: executing arbitrary code returned by AI bypasses the platform's configuration and action boundaries. Negative: assuming a retry is harmless, or claiming exactly-once effects because a job has an identifier, invents unsettled semantics. Negative: using a notification's read state as the authoritative approval decision bypasses governance.

Implementation and Build Gates

D01-D10 are settled. The roadmap bounds the first Spearmint workflow. Unsupported scheduling or cancellation operations must be explicit capability limitations, not simplified meanings that remove identity, policy, history or recovery. Mechanisms and parameters are specified in implementation guidance; none is a new numbered architecture decision.

Implementation architecture owns worker and runtime design; Security and operations owns operation; Development owns validation; Implementation status owns evidence. Acceptance checks: distinguish Workflow Definition, Step, Workflow Execution, Command, Action, Action Execution, Attempt, Outcome, Effect and Event alongside Trigger/Schedule/Job/Automation; inspect addressable nodes; preserve identity, version bindings and history across migration/re-entry/compensation; validate inputs/actions; demonstrate no-AI execution; expose failures; prove governed action boundaries before claiming scheduling or delivery guarantees.

Source Lineage

Source map records redistribution under documentation ownership. 02 technical architecture, sections 10-11; 03 engines and MVP, workflow priority, enquiry, equipment servicing, and human-operated-first examples; 00 combined handoff, corresponding sections supply the foundation. 01 product and principles supplies no-AI operation and readable business ownership; older automation, scheduling, and job-queue documents contribute trigger/conflict/timezone/background-work requirements, not their table schemas or implied runtime availability.