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
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.

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.

Anonymous public intake, concrete file/signature upload adapters, conditional multi-page layout, and automated target handoff execution remain product depth; the owner and security boundaries no longer depend on those additions.

3.2 KiB Raw Blame History