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:
journal_entry.post;journal_entry.reverse;journal_entry.adjust;accounting_correction.stage;accounting_correction.mark_ready;accounting_correction.abandon;close_run.evaluate;close_run.waive_check;close_run.revoke_waiver;close_run.approve;close_run.abandon;financial_period.hard_close;financial_period.reopen;report.view;report_run.capture;sales_tax_return_control.stage;sales_tax_return_control.mark_ready;sales_tax_return_control.approve_filing;sales_tax_return_control.record_external_filing;sales_tax_return_control.abandon;sales_tax_remittance.approve;sales_tax_remittance.record_external_payment;sales_tax_remittance.post;sales_tax_remittance.record_bank_match;sales_tax_remittance.abandon;company_conversion_run.stage;company_conversion_run.mark_mapped;company_conversion_run.mark_reconciled;company_conversion_run.approve;company_conversion_run.apply;company_conversion_run.fail;company_conversion_run.abandon;company_conversion_run.supersede;chart_of_accounts.change;fiscal_calendar.change;accounting_policy.change;company_data.export;backup.create;backup.export;backup.restore;user.manage;role_permission.change;audit_log.view;support_access.grant.
Rules
- Protected actions must require authorization.
- Protected actions that affect company data must resolve actor and company context before execution.
- Dangerous protected actions must require reason/comment.
- Especially dangerous actions should support step-up confirmation.
- Protected actions must 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.
- Correction protected-action requirements are binding only through the canonical Accounting Correction Contract while this general contract remains draft.
- Close protected-action requirements are binding through the canonical Close Run Contract while this general contract remains draft.
- Reporting protected-action requirements are binding through the canonical Reporting Contract while this general contract remains draft.
- Sales-tax return and remittance protected-action requirements are binding through the canonical Sales Tax Accounting and Remittance Contract while this general contract remains draft.
- Company-conversion protected-action requirements are binding through the canonical Company Conversion Run Contract while this general contract remains draft.
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.
Related binding contracts
../accounting-correction.contract.md../close-run.contract.md../reporting.contract.md../sales-tax-accounting-and-remittance.contract.md../company-conversion-run.contract.md