Skip to main content

Adoption Maturity

  1. Assisted: human directs each step.
  2. Structured: specs, tasks, and verification are consistent.
  3. Bounded: permissions, sandboxes, hooks, and evidence are explicit.
  4. Integrated: agentic CI/CD and production feedback operate safely.
  5. Optimized: routing, evals, and governance improve from measured outcomes.

TaskFlow working chapter: Adoption Maturity​

TaskFlow is not a greenfield demonstration. It already serves multiple organizations, contains undocumented behavior, and runs background work with incomplete telemetry. This chapter changes one precise part of that system: organization-scoped audit exports. Its role in adoption and governance is to turn adoption maturity into an engineering decision that survives implementation, review, release, and incident recovery. The primary deliverable is the operating agreement and scorecard; a chat transcript or plausible code diff is not a substitute.

Decision in focus​

Create an owned policy with review cadence, exception path, budget, and measurable outcome. The change remains anchored to OUT-001: an organization administrator can request and download a complete audit export without learning whether another tenant's records exist. Record ownership, risk, cost, compliance, outcomes, and organizational learning. In particular, distinguish the actor making the request, the organization used for authorization, the organization embedded in the queued job, and the organization used by the worker query. Those values should normally agree, but the design must fail closed when they do not.

The chapter's central review question is: what new fact or control does Adoption Maturity contribute that the surrounding chapters do not? Answer it in the owning artifact. For this topic, reviewers must compare human intervention, accepted-change cost, escaped defects, verification time, and rollback rate. Link the result to stable identifiers instead of copying requirements into several documents: FR-AE-001 covers authorized export creation, FR-AE-004 covers expiration, NFR-AE-002 sets the latency objective, RISK-AE-001 covers cross-tenant disclosure, and EVD-AE-* identifies retained proof.

Concrete scenario​

Assume administrator Ana requests an export for organization org-a. The API authorizes Ana, writes a job containing org-a, and returns 202 Accepted with an opaque job identifier. Before the worker starts, Ana loses the administrator role. Decide explicitly whether execution uses authorization captured at request time or revalidates current authorization; document the privacy, usability, and audit implications. Next, inject org-b into the worker payload and verify that the worker rejects it without revealing whether org-b exists. Finally, retry the same job after object storage succeeds but the database status update fails. The recovery path must avoid duplicate disclosures and must leave enough evidence to reconcile the artifact.

This scenario prevents a common failure in agent-generated changes: each component looks locally reasonable while the end-to-end authority chain is inconsistent. It also forces the chapter topic to influence observable behavior. If applying adoption maturity does not change an artifact, gate, test, policy, or production signal, it has not yet contributed to the lifecycle.

Verification and exit evidence​

Run deterministic checks for tenant scoping, role changes, state transitions, idempotency, retention, and download authorization. Use probabilistic evaluation only where judgment is genuinely required, such as assessing whether an agent's handoff explains residual risk. Retain the specification revision, code commit, exact commands, test and eval results, reviewer identity, approvals, environment, artifact digest, and timestamp. Redact secrets and exported audit contents while retaining correlation identifiers needed for investigation.

The chapter is complete when reviewers can trace OUT-001 → FR/NFR → DEC → TASK → TEST/EVAL → EVD, reproduce the important failure cases, and explain the return path if evidence fails. change routing or autonomy only after evidence shows the new policy preserves safety and outcome quality. Any unresolved authority question, incompatible migration, or missing rollback mechanism returns to the owning specification or decision record; it does not become an implementation-time guess.

Workshop​

Apply the chapter to the scenario above and produce the named artifact. Include one denied action, one approval boundary, one failure injection, one measurable production signal, and one rollback or reconciliation step. Exchange artifacts with another reviewer who has only the repository and evidence manifest. If that reviewer cannot identify the permitted authority and independently determine whether RISK-AE-001 is controlled, revise the artifact rather than adding explanatory chat.

Sources and currency​

Last technically verified: 2026-08-09

Commands, product support, and preview status can change. Verify the applicable version before adopting an example as policy.