Files
govoplan-forms-runtime/docs/FORMS_RUNTIME_DOMAIN_BOUNDARY.md
T

5.0 KiB

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.