AI Proposals and Execution

Internal reference for Copilot draft proposals, form requests, validation, confirmation, and supported executable actions.

AI Proposals and Execution

Copilot should never silently change important PSA data. It should draft, validate, and ask for confirmation first.

Proposal Lifecycle

  1. User asks for a data-changing action.
  2. Capability and skill planning decide whether proposals are allowed.
  3. Proposal builder creates a structured draft.
  4. Form request service detects missing required information.
  5. Proposal validation checks field values.
  6. The UI renders editable fields with correct input types.
  7. User edits or confirms the draft.
  8. Execution service runs the supported action.
  9. Proposal status is updated.

When to Create a Proposal

Create a proposal when the user asks to:

  • Create.
  • Update.
  • Send.
  • Approve.
  • Reject.
  • Return.
  • Reassign.
  • Apply.
  • Enable or disable, once write tools exist.

Do not create a proposal for:

  • Briefs.
  • Summaries.
  • Counts.
  • Navigation.
  • Read-only explanations.
  • General "how do I" questions.

Field Types

Proposal forms should use the right input type.

FieldPreferred input
ProjectProject select.
TaskTask select when editing an existing task.
InvoiceInvoice select with invoice number label.
RecipientContact select from the invoice/customer account.
AssigneeUser/resource select.
Due dateDate picker.
DecisionSelect.
Priority/status/healthSelect.
Description/messageTextarea.

Do not show UUIDs as labels when a readable name or number exists.

Supported Proposal Types

Current supported proposal types include:

  • Create task.
  • Assign follow-ups.
  • Send invoice reminder.
  • Update project health.
  • Draft status update.
  • Decide approval request.
  • Reassign approval request.
  • Closeout work draft.
  • Handoff readiness draft.
  • Create project plan draft.

Supported execution may be narrower than supported drafting. If execution is not supported, the UI should keep the action as a draft.

Validation Rules

Validation should check:

  • Required fields.
  • Entity existence.
  • Entity belongs to the organization.
  • Entity status allows the action.
  • Date format.
  • Contact relationship to customer.
  • Approval request is pending.
  • Action is valid for the record type.

For approval decisions, only pending requests should be updated. Approved, rejected, returned, or cancelled requests should not be changed.

Refining Drafts

If the user updates a draft through chat, Copilot should produce a new proposal or update the existing proposal form, not only respond with prose.

Examples:

  • "Change due date to next Friday."
  • "Use Shiv as assignee."
  • "Make priority high."
  • "Add this description."

The visible proposal should stay aligned with the latest assistant text.

Confirmation Boundary

Assistant text should be clear:

  • "I prepared a draft."
  • "Review and confirm before I create it."
  • "I cannot send this until you confirm."

Assistant text should not say:

  • "I created it" before execution.
  • "I sent it" before execution.
  • "I updated it" before execution.