Skip to content

Contract: Protected actions

Status

Draft.

Purpose

This contract defines the minimum behavior for actions that require explicit authorization or step-up confirmation.

Contract

A protected action is an application action that can materially affect accounting records, company configuration, security posture, auditability, backups, or access to sensitive information.

Protected actions must have stable names from a central registry. Application services, authorization checks, seed data, and tests must reference registry names rather than ad hoc strings.

Examples

Protected actions include:

  • AccountingEntry.Post;
  • AccountingEntry.Reverse;
  • Period.Close;
  • Period.Reopen;
  • ChartOfAccounts.Change;
  • FiscalCalendar.Change;
  • AccountingPolicy.Change;
  • CompanyData.Export;
  • Backup.Create;
  • Backup.Export;
  • Backup.Restore;
  • User.Manage;
  • RolePermission.Change;
  • AuditLog.View;
  • SupportAccess.Grant.

Rules

  • Protected actions must require authorization.
  • Protected actions that affect company data must resolve actor and company context before execution.
  • Dangerous protected actions should require reason/comment.
  • Especially dangerous actions should support step-up confirmation.
  • Protected actions should emit audit events.
  • Closed-period rules must be enforced through protected actions, not bypassed by direct edits.
  • The protected action registry must be the source used to generate development/test full-access permission bundles.
  • Adding a protected action must require an explicit permission decision.

Acceptance criteria

  • Unauthorized users cannot perform protected actions.
  • Protected actions are visible in the audit log.
  • Period reopen and backup restore require authorization and audit evidence.
  • Tests can verify that each protected action enforces its policy.
  • Tests can verify that the development/test full-access bundle covers every registered protected action.
  • A protected command without required actor or company context is rejected before domain mutation, except for explicit company creation or company selection flows defined by the Company Identity and Context contract.