Can the legal review step be a human instead of AI?

The review step drafts the findings; the approval gate is always human. Many teams treat the AI review as counsel's first pass — it flags, counsel reads the flags plus the diff at the gate, and the approval records their decision.

How do we trigger a revision?

Manually from the dashboard, or by labeling a ticket that describes the needed change — the run starts seeded with that ticket. Scheduled annual-review runs work too: the draft step reports 'no changes needed' or proposes them.

AI Workflows for Policy Review and Updates

Name: Fleet
Author: Fleet

Company policies rot quietly. The security policy references a tool you retired; the data-retention policy predates the product feature it should constrain. Reviewing them is everyone's job and no one's, so updates happen in bulk panic before an audit or after an incident.

When updates do happen, the chain of custody is murky: a doc edited by several hands, approved in a meeting nobody minuted, published to a wiki without versions. For documents whose entire value is being authoritative, that's self-defeating.

How it works with an agent fleet

A Fleet workflow drafts the policy revision against what changed, routes it through a legal/owner review that flags substantive concerns, and publishes only after a recorded approval.

Step	Kind	What it does
`revise`	Document	“Draft the policy revision described in the trigger ticket. Preserve unchanged sections verbatim; mark every change.” Reads `policies/security.md`, `docs/systems/*.md`.
`counsel-review`	Review	“Review the revision for legal exposure, contradictions with other policies, and unenforceable language.”
`owner-approval`	Approval gate	Pauses the run for a human sign-off; records the approver, timestamp, and note.
`publish`	Publish	Shares the approved document at a link.

You build this once on the dashboard canvas; your self-hosted Fleet worker pulls the definition and runs it against your repository.

Each revision is a fresh run: drafted, reviewed, approved, published — four artifacts with lineage. The policy's history becomes a sequence of approved revisions instead of a wiki page's edit log.

The fleet pattern

Label-triggered revision → counsel review → owner approval gate → publish. The bureaucratic virtue (who approved this wording, and when?) falls out of the machinery instead of requiring discipline.

Guardrails that matter here

Publication depends on the gate — an unapproved revision cannot become the published policy
The review step cross-references sibling policies from the corpus, catching the contradiction class of error (two policies disagreeing about retention windows)
Approver identity and timestamp are recorded against the exact revision — chain of custody by construction

Who this is for

Compliance, legal, and security owners maintaining policy sets that auditors, customers, or regulators actually read — anywhere 'who approved this version' is a question with consequences.