awoss Documentation

This example shows how awoss can be applied to one scoped workflow. It is deliberately narrow: a release-assistant agent that helps an engineering team prepare release notes and internal change summaries.

Workflow

The agent reads selected tickets, pull requests, changelog fragments, and test results. It drafts a release summary, prepares an internal ticket update, and suggests a customer-facing note that a human must approve before use.

The agent is not allowed to deploy code, change production configuration, send external messages, modify customer records, or read unrelated repositories.

Boundary

Boundary item	Example scope
Runtime	One approved agent runtime for release-assistant work.
Repositories	Two product repositories and their release branches.
Documents	Release-planning folder and approved changelog folder.
Tickets	One release project in the issue tracker.
Shell access	Read-only test and metadata commands in a controlled workspace.
Communication	Draft-only internal update and draft-only customer note.
Exclusions	Production deployment, customer database access, unrelated repositories, direct external sending, and permission changes.

Reach

The profile should list what the agent can read or invoke:

selected repository paths
selected ticket fields
release-planning documents
test-result artifacts
approved shell commands
approved draft-message tools

Anything nearby but outside the workflow should be named as excluded. A clear exclusion is useful evidence. A hidden exclusion weakens the review.

Authority

The workflow should identify the authority path:

Action	Authority model
Read release documents	Delegated team workspace access.
Read selected repositories	Repository read access scoped to release branches.
Run allowed test-summary commands	Runtime-mediated command policy.
Draft internal update	Draft-only tool permission.
Draft customer note	Draft-only permission with human approval required before sending.

The profile should say whether the agent acts through a user session, workflow identity, service account, connector identity, or another authority path.

Actions and approvals

The workflow can separate low-impact work from high-impact work.

Action class	Policy
Read selected files and tickets	Allowed inside the named boundary.
Run approved summary commands	Allowed if command and working directory match policy.
Draft internal release update	Allowed as draft.
Draft customer-facing note	Must pause for human approval before use.
Send external message	Out of scope or denied.
Deploy code or change production configuration	Out of scope or denied.
Export sensitive data	Denied unless separately approved and logged.

The important point is that approval rules are defined before the workflow runs, not reconstructed after something goes wrong.

Evidence

The evidence packet does not need to copy every private file or transcript. It should keep redaction-safe records that explain important actions.

Useful evidence may include:

scope record and exclusion list
runtime policy version
repository and document inventory summary
allowed command list
draft-message approval record
denied-action records
source and tool version record
validation findings and retest notes
exception register

The evidence should help reviewers understand what happened without becoming a new sensitive-data leak.

Findings and exceptions

The profile may find gaps. For example:

Finding	Decision
Shell policy is described but not enforced by runtime controls.	Keep workflow in internal review only until runtime enforcement exists.
Draft customer note approval is manual and not attached to the action receipt.	Add approval receipt requirement before customer-facing use.
Repository inventory is current but document-folder inventory is manual.	Accept time-limited exception with owner and review date.
Denied external-send action is logged without payload.	Accept if event ID, actor, policy outcome, and affected tool are recorded.

Exceptions should have owners, review dates, and a clear plan to close or accept the gap. The profile should not hide unresolved gaps.

Profile summary

A short summary might read:

The release-assistant workflow maps to selected awoss candidate controls for scope, delegation, workspace boundary, runtime action control, source trust, sensitive-data handling, logs, validation, and governance. The workflow is suitable for internal review with named exceptions.

That summary is useful because it ties the review to one named workflow, selected controls, evidence, and known exceptions.