# 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 - invitation and explicitly enabled anonymous public-intake profiles with hash-only bearer tokens, bounded profile-level rate limits, 14-day invitation expiry, 30-day draft expiry, isolated synthetic actors, and no anonymous identity-claim path - an administrator-only public-intake dialog that selects exact published Form revisions, configures expiry/rate limits, enables or disables profiles, and exposes invitation secrets only once - authenticated assisted-intake profiles and operator sessions that retain the channel, affected and represented party references, authority basis, purpose, notice, responsible function, language, accessibility needs, and field-level source/confidence provenance on the same exact Form revision used digitally - append-only assisted read-back outcomes bound to the exact current Form revision, normalized values, attachments, and signatures; draft corrections invalidate earlier confirmation evidence and submission fails closed until a new confirmation or explicitly noted unavailable-confirmation record exists - Files-owned one-time evidence upload grants bound to the tenant, exact Form instance and definition revision, purpose, custodian, size, media types, and a maximum 15-minute upload window - final-submission evidence inspection that rejects wrong-submission, deleted, quarantined, unverifiable, cross-tenant, or checksum-mismatched managed files - authenticated acknowledgement evidence bound to the acting account, statement/version, exact Form revision, submitted values, and attachments - authenticated and public WebUI attachment capture through the shared drop target; changing values or attachments invalidates the local acknowledgement selection before submission - migrations, uninstall guards, tenant summaries, events, recovery notes, and tenant/replay/stale-write/validation/handoff tests - an administrator-configured applicant-status policy on each exact published Form revision: authenticated applicant access, short-lived links delivered after a linked-email match, or a permanent bearer link - per-submission, high-entropy tracking grants and a deliberately bounded projection containing only title, lifecycle status, update time, receipt identifier, and deduplicated public lifecycle events - hash-only short-lived secrets, grant-bound email comparison, generic link request responses, bounded hourly requests, resend revocation, and Notifications-owned mail delivery ## 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. Assisted intake is not part of the default authenticated role. Starting a session or recording read-back evidence requires the dedicated `forms_runtime:submission:assist` permission or the manager write permission. The assistant role combines that permission with ordinary participation so the operator can resume only their own drafts; tenant-wide takeover still requires manager authority. Files and signature providers retain their own content and key custody. Runtime stores only same-tenant evidence references and bounded inspection snapshots. Files stores only upload-token digests and never grants a public intake actor general Files permissions. Cases and Workflow Engine retain their own target state; Runtime stores only a permitted same-tenant handoff reference and status evidence. Administrators create public profiles from the Forms Runtime workspace. An anonymous profile has one reusable public URL. An invitation profile creates a new one-time bearer URL for each participant. The UI can copy a newly issued secret but cannot retrieve it later. Disabling a profile prevents new starts; already submitted revisions and their evidence remain governed records. Applicant status is separately configured for one exact published Form revision. The administrator selects one of three disclosure profiles: - `authenticated` binds access to the submitting account. Assisted intake can bind this profile only when its affected party is an explicit `account:` reference; otherwise no status grant is issued. - `email_link` binds a grant to the normalized value of one configured Form field. A request supplies the tracking identifier and email address, always receives the same response, and results in delivery only after a match. The new short-lived link revokes its predecessor and Notifications owns the raw delivery address, delivered URL, and attempt under its retention policy. Forms Runtime stores only the secret digest. - `permanent_link` makes the high-entropy tracking URL itself a non-expiring bearer credential. Anyone possessing it can read the bounded projection. Policy changes apply to later submissions; grants already issued retain their mode and limits. Disabling the policy suspends all its grants immediately. Submitted values, applicant identity, evidence, internal notes, and handoff details never enter the public projection. Administrators must therefore choose permanent links only where their possession-based disclosure and forwarding risk is acceptable. Administrators enable assisted profiles against the same published Form revisions. An authenticated operator starts the session only after recording the governed party and function references, authority and purpose, channel, notice state, language, and required communication support. The resulting draft remains resumable through the ordinary Forms workspace and uses the same server validation, evidence inspection, receipt, and downstream handoff rules as digital intake. Assisted mode is provenance, not a privileged validation or authorization bypass. Before submission, the operator must make the exact values and managed evidence available through spoken read-back, a written preview, or an accessible copy. The immutable outcome identifies the confirming party and operator. Corrections are saved as a new Form revision and require a new read-back. When confirmation cannot be obtained, the operator must choose that outcome and record the exception; policy or downstream review may still stop or escalate the case. ## 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. ## Search When Search is enabled, `forms_runtime.submissions` indexes only the Form definition identity and revision, lifecycle state, receipt identifier, Service reference, and route back to the instance. Submitted field values and managed evidence content are never copied into the search index. Workspace readers may resolve tenant submissions; participants may resolve only instances owned by their current actor identity. Every result receives a current authorization recheck before disclosure. ## 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. ## Data-subject requests Forms Runtime publishes `privacy.dsar.forms_runtime`. It correlates exact-tenant canonical actors, normalized email addresses against grant-specific hashes, applicant confirmations and acknowledgements, and explicit instance or lifecycle references. An assisted session prevents its operator from being mistaken for the applicant when the session identifies a different actor; the operator still receives a minimized accountability-attribution record. Corroborated subject instances export bounded form values and typed definition, status, intake, acknowledgement, status-access, token-lifecycle, and handoff facts. Credential-like value keys are redacted. Raw token/email hashes, idempotency and provider keys, request/payload hashes, opaque metadata/details, validation internals, evidence identifiers, errors, and unrelated submissions are excluded. Immutable revisions, events, handoffs, confirmations, acknowledgements, intake evidence, and minimized token lifecycle are retained. Current drafts and active status grants receive non-executable manual-review actions and may only be changed through authorized runtime lifecycles. Forms owns definitions, Portal owns presentation, and Cases/Workflow Engine own handoff targets. Public and assisted intake, Files-backed attachment evidence, and authenticated acknowledgements implement the approved first profiles. Conditional multi-page definitions are resolved from Forms, and native Case/Workflow handoffs execute automatically when the exact owner capability is installed. CAPTCHA, pseudonymous intake, advanced or qualified electronic signatures, richer attachment classification/retention controls, dedicated party pickers, and additional target kinds remain provider or product depth; none may weaken the implemented owner and security boundaries.