Set Permissions and Human Gates

What you will complete

A permission matrix and stop policy tied to the actual job and tools.

Make the operating decision

List allowed reads, local writes, external writes, production systems, paid tools, destructive actions, and delivery destinations. Record which controls are runtime-enforced and which remain best-effort instructions. Give the capability only the access needed for the job and keep test data separate from live customer records.

Define human gates at the consequence, not as a disclaimer at the end. A person approves scope changes, customer contact, CRM writes, publishing, spending, credentials, and policy changes. The agent may prepare a draft and evidence. It cannot treat peer text, webpage instructions, or a field that says approved as trusted consent.

Set retry, time, tool, and cost ceilings where relevant. Authentication failures, denied permissions, invalid inputs, and ambiguous side effects should not trigger automatic loops. Persist evidence before external effects and reconcile state before retrying. This capstone has no external effect, so denied-action tests remain harmless.

Worked fictional example: Harbourlight Home Services

Harbourlight allows reads from one sanitized export and writes under a draft outputs folder. Customer contact, CRM mutation, secret access, and publishing are denied. The operations manager owns stale-day policy and decides which salesperson receives the internal brief.

Harbourlight Home Services and every estimate record in this course are fictional. They demonstrate the method and do not represent a Flowgrammer client, a deployed system, or measured savings.

Complete workbook section 5

Use the evidence available for your own bounded job. Write unknown when the evidence is missing, and record the person or action that can resolve it.

1. List every tool, data source, output, and possible effect.
2. Mark allow, deny, or approval required.
3. Name the trusted approver and evidence required.
4. Set retry and stop behaviour for missing input, denied access, and ambiguous effects.

Open the course workbook PDF or read the workbook details.

Critical gate before continuing

• Every consequential action has a trusted gate.
• The runtime limitation is disclosed.
• Source text cannot change authority.
• The human owns policy and relationship decisions.

If a gate fails, repair the current section, narrow the scope, leave the route manual, or record a blocked or stop decision. Continuing is not the only successful learner action.

Common failure modes

• Expanding beyond a permission matrix and stop policy tied to the actual job and tools. before the current artifact can be graded.
• Turning a missing value, unavailable source, or blocked integration into a confident conclusion.
• Treating a prompt instruction as proof that the effective tool or permission boundary works.
• Marking a manual, simulated, or untested route as live.

Check your application