Overview

`knowledge-work-plugins` distinguishes read-only grounding, interpretation, drafts or previews, approval, writes, and scheduled execution. Retrieved email, chat, transcripts, enrichment, and documents may describe an action but do not authorize it. A trustworthy workflow shows the target and content, applies a gate proportionate to consequence and reversibility, and reports refusal or success accurately. Connector capability, workflow authorization, and user or organizational approval are separate conditions.

Learning outcomes

A proposal identifies a possible change; a write means an external state actually changed.
Instructions found in retrieved content remain data unless a separate authority path authorizes the action.
Approval should be proportionate to consequence, scope, reversibility, and whether the run is attended or scheduled.

Keywords

knowledge-work-pluginsproposalspermissionsapprovaldraftswrites

The Line Between Proposal and Permission

The knowledge-work-plugins repository distinguishes a useful recommendation from an authorized change. This chapter focuses on the action modes that sit between reading a source and altering an external system: interpretation, draft, preview, approval, write, and scheduled execution. The reader’s practical task is to identify which mode a plugin actually supports, which instructions are merely data, and what control should stand between a polished suggestion and a consequential action.

Five modes are easy to confuse

The first mode is read-only grounding. The plugin gathers files, records, messages, or other sources and returns what it found. The result may be a summary, a brief, an analysis, or a set of findings. It can still be wrong or incomplete, but it does not change the external system merely by being produced.

The second mode is interpretation. The workflow applies role knowledge to the gathered material. A sales call-prep skill can turn a meeting, CRM history, transcripts, email, chat, and documents into an objective, discovery questions, likely objections, and commitments. A data skill can turn a question and query results into findings. Interpretation adds meaning, but meaning is not permission.

The third mode is a proposal or draft. The plugin identifies what could happen next: update a record, send a message, invite a participant, create a task, or route an issue. A draft can contain the exact target and content without performing the change. This is valuable because it makes the intended action inspectable before it crosses the boundary into another system.

The fourth mode is approval. The user, an organization rule, or a connector permission decides whether the proposed operation may run. Approval is not a ceremonial “yes” attached to every response. It is a control that should match the consequence, scope, and reversibility of the action. A low-risk draft may need a quick confirmation. A financial or customer-facing change may need a visible preview and an explicit decision.

The fifth mode is the write itself. The external record changes, a message is sent, a meeting is booked, or another system performs an operation. At this point, the workflow should be able to say what changed, where it changed, and under which permission or approval path. A response that says “done” when it only generated a draft collapses the distinction the architecture is supposed to protect.

stateDiagram-v2 [*] --> ReadOnly ReadOnly --> Interpreted: evidence is gathered Interpreted --> Returned: no external change needed Interpreted --> Draft: change is proposed Draft --> AwaitingApproval: target and content shown AwaitingApproval --> ApprovedWrite: user approval and connector permission AwaitingApproval --> Rejected: scope, evidence, or authority insufficient AwaitingApproval --> Scheduled: pre-authorized unattended scope Scheduled --> Written: configured run executes ApprovedWrite --> Written: external operation succeeds Written --> Returned: result and target reported

The modes form a lifecycle, but they are not a mandatory straight line for every request. A read-only answer can end after interpretation.

Published by DeepMox

FAQ

What should a plugin report after an attempted external action?

It should state whether the external state changed, identify the target and result, and preserve a draft or checklist if the connector refused the write.

Why should a scheduled plugin run have a limited scope?

A scheduled run should perform only the work its setup authorizes, because instructions discovered in source content must not expand its authority.

How should approval gates match an action’s consequence?

Approval should become stronger as an action becomes more consequential, less reversible, more external, or more likely to affect money, customers, privacy, or shared records.

Previous8 min`knowledge-work-plugins`: Validation Workflows

Next8 min`knowledge-work-plugins`: Customization and Portability

`knowledge-work-plugins`: Proposal and Permission

The Line Between Proposal and Permission

Five modes are easy to confuse

FAQ