121 lines
5.0 KiB
Markdown
121 lines
5.0 KiB
Markdown
# Forms Runtime Domain Boundary
|
|
|
|
## Purpose
|
|
|
|
Runtime form submissions for validation, drafts, attachments, signatures, status tracking, and handoff to domain modules.
|
|
|
|
## Owns
|
|
|
|
- form submissions
|
|
- draft state
|
|
- runtime validation results
|
|
- attachment references
|
|
- signature state
|
|
- handoff status
|
|
|
|
## Does Not Own
|
|
|
|
- form definition authoring
|
|
- document storage
|
|
- domain-specific adjudication
|
|
|
|
## Required Integrations
|
|
|
|
- access
|
|
- forms
|
|
|
|
## Optional Integration Candidates
|
|
|
|
- files
|
|
- approvals
|
|
- workflow engine
|
|
- portal
|
|
- cases
|
|
- policy
|
|
- audit
|
|
|
|
## Implemented State
|
|
|
|
- exact immutable Form-definition resolution through `forms.definitions`
|
|
- tenant-bound instance identities and append-only revisions/status events
|
|
- server-side type, option, constraint, required, attachment, signature, and
|
|
optional policy validation
|
|
- `started` launch sessions and definition-controlled draft persistence
|
|
- final submission receipts, handoff references, replay safety, and OCC
|
|
- actor-bound idempotency that permits an exact retry after definition
|
|
supersession without exposing another participant's submission
|
|
- owner-restricted participant access plus manager scopes
|
|
- bounded list/detail/history/event APIs and accessible definition-driven WebUI
|
|
- `forms_runtime.service_launcher` retaining exact Service and binding
|
|
provenance
|
|
- native Case and Workflow handoffs that commit a durable effect intent before
|
|
invoking the owner capability, use stable provider idempotency keys, and
|
|
reconcile outcome-unknown execution
|
|
- migrations, uninstall guards, tenant summaries, events, recovery notes, and
|
|
tenant/replay/stale-write/validation/handoff tests
|
|
|
|
## Security And Policy
|
|
|
|
Authenticated accounts receive only the participant role by default. It permits
|
|
access to their own instances; tenant-wide reads and review/handoff transitions
|
|
require manager scopes. Event payloads exclude submitted values. Exact
|
|
definition lookup, publication state, tenant, current authorization, and
|
|
optional policy references are re-evaluated for each consequential operation.
|
|
Definition providers must return the requested owner, tenant, object, and exact
|
|
revision; a mismatched provider response fails closed.
|
|
Policy-referenced definitions fail closed when no compatible
|
|
`forms_runtime.policy_evaluator` is active.
|
|
|
|
Files and signature providers retain their own content and key custody. Runtime
|
|
stores only same-tenant evidence references. Cases and Workflow Engine retain
|
|
their own target state; Runtime stores only a permitted same-tenant handoff
|
|
reference and status evidence.
|
|
|
|
## Approved Intake And Evidence Profiles
|
|
|
|
The product and security profile approved on 2026-08-04 sets the next
|
|
implementation boundary:
|
|
|
|
- authenticated-account and invitation-token intake are the first public entry
|
|
profiles;
|
|
- anonymous intake is available only through an explicit per-form policy
|
|
opt-in, while a pseudonymous profile remains deferred;
|
|
- an anonymous submission cannot later be claimed by an identity; an invitation
|
|
submission can be linked only with explicit consent and proof of that
|
|
invitation;
|
|
- invitation tokens are hashed, tenant/form bound, replay safe, rate limited,
|
|
and expire after 14 days by default;
|
|
- drafts expire after 30 days by default, while every service/form must declare
|
|
submitted-data retention explicitly; and
|
|
- CAPTCHA remains an optional privacy-approved provider instead of a mandatory
|
|
external dependency.
|
|
|
|
Files is the first attachment provider and retains byte storage, quarantine,
|
|
scanning, classification, retention, and legal-hold ownership. Runtime stores
|
|
only immutable same-tenant evidence references and must fail closed when a
|
|
required item is pending, rejected, expired, unavailable, or unverifiable.
|
|
|
|
The first native signature profile is an authenticated acknowledgement. It is
|
|
not an advanced or qualified electronic signature. Those assurance levels
|
|
require a separately selected external trust-service provider and current
|
|
provider evidence; a required signature never silently degrades.
|
|
|
|
## Recovery And Operations
|
|
|
|
Database recovery restores identities, revisions, and events together. After
|
|
restore, verify one current revision per instance, monotonically increasing
|
|
revision history, matching event revisions, resolvable exact Form and Service
|
|
references, and referenced evidence availability. A replay with the original
|
|
idempotency key and request hash must return the original revision; a changed
|
|
request must conflict. Failed handoffs leave the prior revision current.
|
|
|
|
Destructive retirement is blocked while state exists and requires a verified
|
|
database snapshot plus an export or retention decision for referenced evidence.
|
|
No local generated files are required, so API and worker nodes remain stateless.
|
|
|
|
The approved public-intake and concrete file/signature provider profiles remain
|
|
implementation depth. Conditional multi-page definitions are resolved from Forms, and
|
|
native Case/Workflow handoffs execute automatically when the exact owner
|
|
capability is installed. Additional target kinds remain adapter depth; the
|
|
owner and security boundaries no longer depend on those additions.
|