# ASTRA decision controls: implementation plan

Status: planning document. The lite/full draft and decision-context fields are implemented. The controls below are not all implemented and are not a compliance certification.

## Current boundaries
Browser drafts remain editable. Local source-review attestations are self-reported. Sharing a decision creates a snapshot; invited-library access and author/reviewer permissions are checked on the server in existing workflows. Connected decisions retain append-only events. Checksum exports detect payload changes relative to a trusted checksum; they do not establish authorship or prevent an administrator replacing both.

New deadline, responsibility, confidentiality and conflict fields travel with drafts and decision exports. The overdue indicator is calculated from the recorded deadline when the view renders. It is advisory: no reminders, enforcement, automatic resolution or gate approval. Confidentiality text does not narrow the invited library's actual audience. Do not share restricted information with that library unless every recipient is authorized.

## Increment 1 — authoritative decision revisions and approval rules
Model decision ID, immutable revision ID, parent revision, author account, server creation time, referenced source versions and snapshot digest. Add explicit draft / submitted / approved / superseded transitions. Define the authorized approver and required reviewers per decision. Enforce transitions on the server inside transactions; deny direct API attempts that bypass UI checks. Lock only a submitted revision; subsequent edits create a new revision and invalidate earlier approval for the changed material. Preserve prior reasons, evidence and approvals.
Acceptance: concurrent edits cannot silently overwrite, old revision bytes remain retrievable, and unauthorized users cannot approve or alter another revision.

## Increment 2 — accountable challenges
Persist each challenge's target revision and claim, author account, response owner, response deadline in UTC, escalation owner and severity. Require assignment acceptance rather than treating a typed name as consent. Append responses and evidence; require authorized challenger/reviewer disposition separately. Unanswered, overdue and disputed challenges stay unresolved. Block configured approvals while blocking challenges remain unresolved; any permitted exception needs an identified approver and preserved reason. A deadline does not automatically reject a scientific claim.
Acceptance: simulate deadlines with a controlled clock; test late responses, revoked membership, races between response and approval, and revised conclusions. Reminders require an authorized delivery channel and visible failure status; the system cannot force a person to respond.

## Increment 3 — confidentiality and conflicts
Implement record- and attachment-level authorization from explicit account/group IDs. Test access via list, direct URL, download, export and dependency views, including revoked access. Enforce classification before sharing and record access changes. Conflict disclosures need account attribution, dates, revisions and an explicit human mitigation/recusal decision. Disclosure alone does not establish independence.
Acceptance: unauthorized recipients receive no protected metadata or file bytes; changing a label cannot silently broaden access.

## Increment 4 — audit, recovery and operational validation
Retain server-attributed events with sequence/version preconditions, idempotency and transactional writes. Define the administrative threat model: application append-only history is not protection against privileged database administrators. Plan independently retained signed checkpoints or write-protected archives if required by the chosen use case. Specify retention, key stewardship, complete export and a tested isolated restore. Document incident and dispute ownership.
Acceptance: test tampering detection, duplicate retries, partial failures, restore completeness, source/review relationships and permission preservation. Record failures as well as successes.

## Release decision
First run the linked 2–3-case usability pilot. Then implement and test each increment in an isolated environment, obtain authorized user acceptance and perform production verification with designated test accounts. Select any regulated use case separately with qualified stakeholders before defining its required validation and procedures. No regulator-readiness claim follows from these features alone.