Operating and releasing interactive bots

Updated 2026-10-21 for TASK358. The code and selected schema are deployed; the new feature remains OFF pending the remaining acceptance checks. Discord’s private command setup is verified and Telegram setup is still held. This runbook does not establish enabled access, provider delivery or pilot acceptance.

The release owner maintains the current acceptance record for TASK358. Individual phase certificates retain their original source and evidence limits.

Who operates each surface

Surface	Owner and permitted work
Admin /admin/security	Exact FPH administrator controls the Interactive bots master switch, with recent MFA, reason and an audited versioned save.
Partners event Email blasts	Existing event-authorized operators compose event mail and optional bot copies.
Admin /communications	Existing authorized platform operators compose sitewide communications and optional copies.
Admin /join/communications	Existing authorized operators use the Join roster/selection workflow and optional copies.
Rego/Partners account settings	Each signed-in owner manages linking, readiness and their own category/purpose/provider choices.
Canonical API	Resolves actors, audience, ownership, consent, source state, deduplication, final submission and receipts.

Do not restore Admin communications into Partners or use a bot as a staff approval/payment workflow. Existing email, inbox, linking/automatic activation, Telegram legacy commands, Discord signed PING/finance interactions, EPS/Finance and established operational bot senders retain their separate rules.

Assemble the release packet

Record one exact code revision per affected repository, the ordered canonical migration set, Worker class/binding migration, current provider-command plan, test artifacts, known failures and intended activation scope. Do not certify a moving working tree using old totals or a later filename with an old digest.

Evidence	What it can establish	What remains separate
Source/contract checks	Mounted routes, fields, source registry and enforced boundaries	Actual execution and provider effects
Local SQL/native PostgreSQL	Actual queries, permissions, transactional races and owned shutdown within the fixture’s declared schema	Hosted Auth/PostgREST/RLS/schema parity and production load
Configured local Worker/browser	Actual runtime/UI behavior for intercepted synthetic journeys	Cloudflare billed CPU, complete memory, production identity and live rendering
Hosted OFF readback	Exact deployed code/assets, schema/grants/bindings and default-OFF denial	Enabled private interactions and provider delivery
Provider acceptance receipt	Provider accepted a particular request	Recipient read, device notification or physical scan
Recipient confirmation	The intended recipient saw the specified message/image	General delivery SLO or every client/device
Canonical scanner/device check	The recorded credential/state passed or failed the real verifier/device journey	Other devices, states or later source changes

The producer catalogue has 67 classified event types in the current source baseline: 53 automatic-copy candidates, five reviewed campaign types, four explicit exclusions and five established-delivery entries. Coverage requires the current registry and source-pair tests, not this count alone. BNPL and platform notice families and campaign integration are under active release verification; their presence in source is not a passing release gate.

Notification coverage and exclusions

This is the complete 67-type catalogue, grouped in operator language: 53 automatic-copy candidates, five reviewed campaign types, four excluded credential/guest types and five established-delivery types. A classified or locally mounted event is not release acceptance. Each allowed copy still requires the original audience, current source/identity/consent and final submission checks.

Group (event types)	Events covered	Required boundary
Registration updates (5)	Own receipt; own group-member receipt; status change; explicit receipt resend; verified gift-recipient summary.	Current participant/verified recipient only; group organization grants no other member’s private data.
Dealer applications (4)	Submission or resubmission; approval; denial; changes requested.	Current applicant; omit answers, crew data and internal review notes.
Dealer packages (2)	Registration receipt; registration/payment status update.	Current owned projection; crew and payer rights remain distinct.
Shop orders (2)	Buyer receipt; payment, order or fulfilment status update.	Current buyer; omit internal notes and keep collection authorization separate.
Refund requests (2)	Request received; request decision.	Current payer; approval is different from money returned.
Upgrade requests (2)	Request received; accepted, declined or finalized decision.	Current participant and existing financial/access policy.
Transfer requests (2)	Request received; decision or received transfer.	Recheck current ownership; no target identity or transfer authority in the copy.
Activity applications (2)	Submission received; published decision.	Current applicant; no sensitive answers or reviewer fields.
Volunteer applications (2)	Application received; published decision.	Current applicant; no private application or staff-only fields.
Affiliate rewards (2)	New conversion reward availability; commission availability.	Current affiliate owner; availability does not mean payout completed.
Pay-later updates — held in the minimum release profile (15)	Agreement recorded; evidence submitted; evidence rejected; verified payment received; payment reconciled; due deadline; grace started; grace ended; cancellation; paid state; accepted schedule changed; refund reserved; refund completed; refund failed; source status updated.	Current payer and already-released underlying finance capability only. Terms, evidence, payment, access and bank-return states remain distinct.
Registration reminders (5)	Registration opening; registration closing; waitlist offer; expiring offer; expired turn.	Original current prefill/offer owner and deadline; opening/closing require announcement consent. No transferable offer credential.
Social relationships (5)	Request received; accepted; declined; withdrawn; friendship removed.	Current recipient/participant and block/privacy rules; minimum released identity only.
Platform notices (2)	Operational service notice; optional platform announcement.	Original eligible cohort plus current scope/visibility/consent; safe static authenticated navigation, not copied notice content.
Partner access (1)	Linked-owner invitation or access summary.	Ordinary authenticated dashboard only; no credential, organization/role label or bearer invitation.
Reviewed campaigns (5)	Event operational; event announcement; platform operational; platform announcement; marketing.	Exact selected canonical email audience, explicit reviewed copy and current channel/purpose consent. Direct registration follow-up permits announcement/marketing only.
Excluded credentials and guest content (4)	Auth action emails; credential-bearing membership invitations; public guest contact mail; guest/report conversation mail.	No new bot copy. Never mirror OTP/reset/magic links, invitation secrets, guest content or report reply capabilities.
Established delivery workflows (5)	EPS operations; EMS staff; finance staff; report staff; payment-account issue alerts.	Preserve each existing authorized audience, channel policy and budget. The new master does not gate them or create duplicate personal copies.

The minimum release profile deliberately leaves the held pay-later schema unpublished. Payment-plan reads and BNPL notification copies remain unavailable until that finance feature is separately released. Compatibility applies only to an attested complete absence of the finance catalogue; partial presence fails closed. Ordinary transaction paths must pass the reviewed absent-finance-schema compatibility checks; this profile does not waive ownership, current financial guards or hosted verification.

An installation in this absence profile also defers the accepted-terms reader wrapper and its service-only permissions, plus 40 finance observers across the same 19 relations: 38 source-change/truncate observers and two campaign observers on the payment-agreement relation. Adding finance tables later does not rerun the skipped branches of already-recorded migrations. A separate genuine finance release must install those deferred objects through new additive migrations and upgrade the API to a supported full-finance contract. The current absence-only bridge rejects any canonical finance presence, including a partial installation. Campaign profile/catalogue mismatches also latch unavailable. The later supported finance release must explicitly re-attest that campaign profile through a reviewed additive migration while preserving prior capture invalidation; installing the missing observers alone does not restore campaign eligibility. Preserve the existing finance activation, checkout, collection and scheduler holds; changing the bot switch or rewriting recorded migration history is not an upgrade.

The exact deferred wrapper is public.bnpl_read_accepted_terms with argument types (uuid, uuid, text, uuid): revoke execution from PUBLIC, anon and authenticated, and grant it only to service_role. The future finance release must verify the complete wrapper, permissions and all 40 observers against its reviewed schema inventory before any enablement; this minimum profile provides no full-finance certification. The two additional campaign observers on public.bnpl_payment_agreements are zzzzz_interactive_bot_campaign_source (AFTER INSERT/UPDATE/DELETE, ROW) and zzzzz_interactive_bot_campaign_truncate (BEFORE TRUNCATE, STATEMENT).

Required release checks

Git build ordering for the executor migration

Cloudflare’s non-production trigger uses wrangler versions upload, which cannot apply the new v8-interactive-bot-executor Durable Object migration. Actual Cloudflare build logs confirmed that restriction. Keep the preview trigger unchanged: changing it to wrangler deploy would let a branch replace production. Integrate current main, validate the candidate, and use the existing production main-branch Git trigger to apply the migration with the master OFF. Read back the deployed executor binding and normal routes before provider setup. Subsequent version uploads can then use the existing namespace.

See Cloudflare deployment management.

1. Reconcile source and provider setup: Read back current canonical schema, function bodies, service/browser grants and automatic-link/readiness behavior. Inventory Telegram menus and Discord commands before an additive change. Preserve existing finance commands, webhook endpoints and installations.
2. Verify owned transaction journeys: Test both providers and independent owners across all declared types, pagination, exact-reference lookup, event/status filters, complete detail sections and ordinary website fallback. Preserve group/dealer/gift/payer distinctions and held financing features.
3. Verify final authority: Exercise wrong owners, public contexts, forwarded/expired/replayed controls and concurrent transfer, refund, cancellation, identity change, opt-out and OFF. Prove the final reservation boundary and the already-in-flight exception.
4. Verify QR: Compare exact payloads with canonical issuers and verifiers. Record eligible and withheld/revoked cases separately for admission and Shop lookup/collection. Inspect both provider attachments and real scanner/device behavior. A local PNG decode alone does not close this gate.
5. Verify automatic copies: Account for every catalogue producer/event/ recipient pair. Compare the original committed event and intended audience, safe text, purpose/consent, replay/outage/expiry behavior and independent email and bot receipts. Retain explicit credential/guest exclusions and established delivery deduplication.
6. Verify campaign copies: Exercise all existing composer owners, exact previews, overlapping audience deduplication, stale preview denial, partial channel failure, confirmed-unsent retry, cancellation, lost responses and unknown outcomes. Accepted email and accepted/unknown copies must not resend.
7. Verify Free-plan operation: Measure the complete ingress and object execution, memory, database work/cancellation, provider pacing, queue latency, alarm/cron delivery and retention under representative traffic and backlog. Do not substitute a heap sample, abort signal or local elapsed time for hosted billable CPU, whole memory or database cancellation evidence.
8. Verify OFF deployment: Publish only the reviewed release packet through the normal linked-GitHub release process, with the master OFF. Read back the exact artifacts, schema and effective policy. Confirm legacy email/bot behavior and denial of every new capability before any pilot enablement.
9. Verify an authorized pilot: Record explicit environment/recipient/send authorization, then genuine linking and both-provider private journeys, receipt confirmation, current scanner cases, desktop/mobile screenshots, rate-limit recovery and OFF/ON without backlog replay. Broader availability needs a separate explicit Admin enable decision.

Missing proof remains an open gate. A deadline does not convert unexecuted hosted/provider/device checks into acceptance. Each live canary needs applicable environment, recipient and send authorization.

Use the master switch

1. Open Security: Sign in at Admin Security with the exact platform administrator role. Read Interactive bots saved state, revision and epoch. Loading/unavailable is not a saved ON state.
2. Review the decision: Keep OFF for staging and release preparation. For an authorized change, enter a clear reason, review the proposal and confirm.
3. Complete MFA: Use the existing MFA dialog when requested. A stale AAL2 session is not sufficient for this switch’s recent-MFA requirement.
4. Read back: Confirm the current policy and audit receipt after save. Concurrent edits can conflict; reload and review rather than overwriting. Each applied save advances revision and epoch, including an OFF save.

If the response is lost, leave editing locked until an authoritative reload. Review the newly read state. Retrying the original request with its original request ID/revision can apply an uncommitted proposal or recover its audit receipt; it is a mutation attempt, not a read-only lookup. Do not repeatedly toggle or generate fresh request IDs to resolve uncertainty.

OFF blocks the new reads, session redemption, QR issuance and new event/campaign submissions, invalidates prior sessions and suppresses unreserved work. An already committed send reservation can be in flight and cannot be recalled. Missing/malformed/unavailable policy fails closed. Re-enabling starts a fresh epoch for future eligible work; it does not replay work generated while OFF, revive old interaction pages or resume a suppressed campaign.

Compose an email blast with optional copies

Join bot copies require an explicit account association proven through the owner’s email code, plus current provider readiness and announcement consent. Unassociated and anonymous entries remain ineligible; matching email or UUID does not establish ownership. Original email delivery continues independently.

1. Choose the existing audience: In Partners open the event’s Email blasts page. Use Admin Communications or Join Communications for their respective audiences. Keep the existing email permissions, selection and purpose rules.
2. Review email first: Compose and preview the email/inbox message normally. In Optional bot copies, Telegram and Discord checkboxes start unchecked. Leaving both unchecked preserves the ordinary email-only request.
3. Select channels and purpose: Select only the requested copy channels. Partners exposes Bot copy category with Operational update, Announcement and Marketing. Admin uses its existing Email purpose; Join uses announcement. This classification cannot override any recipient’s consent or source scope.
4. Write Bot copy message: Supply explicit reviewed plain text, at most 1,800 UTF-16 units and within the provider’s escaped payload bound. There is no automatic email-HTML conversion or silent truncation. Do not include secrets, invitation/recovery actions, QR images, attachments or private notes.
5. Review each channel: Inspect exact text, eligible/excluded counts and missing-link/consent-readiness exclusions. Selected OFF/unavailable channels or a selected channel with no eligible recipients cannot be sent. A change to content, audience, purpose, channels, policy or recipient binding can require a fresh preview. Uncheck copies explicitly if you decide to proceed with email only.
6. Queue once: Use the existing email send/queue action only after a matching current preview. The approved original audience is the upper boundary; anonymous Join/email-only contacts cannot acquire a bot recipient by email matching. A later new link or opt-in does not fill an old campaign audience.
7. Check independent outcomes: Open campaign history and Bot copies / View bot delivery. Inspect each provider independently of email.

If email is accepted but optional capture fails, the bot-copy result is unavailable. Do not send the email again to repair the copy or assume a later retry will populate missing recipients. Direct attendee-notice retries retain their original operation identity; do not create a new operation merely because the optional response was lost.

Send a single registration follow-up

The existing registration Email action also has Write follow-up. Its Optional bot copies start unchecked. Selected copies require an explicit plain Bot copy message, a current eligibility preview and a stable operation identity. This follow-up defaults to Announcement; only Announcement or Marketing is permitted, not Operational.

The API reserves that operation before attempting the external email. An accepted replay, pending reservation or unknown result does not attempt the email again. If the email result is uncertain, the UI retains the operation and freezes another send; refresh/review its existing outcome. Once email is provider-accepted, use View bot delivery for independent copy status/recovery. Do not resend the email to repair a copy. This path adds no attendee-inbox entry; normal receipt resend retains its separate existing behavior.

Current registration ownership, event scope and any direct or inherited financing restrictions are rechecked for the copy. The same unknown/accepted no-resend rule and provider-specific confirmed-unsent recovery apply. These are implemented source contracts; local checks, hosted behavior and live receipt remain separately recorded.

Read delivery state and recover safely

State	Meaning and permitted response
Queued / retrying	Waiting for eligibility, pacing or a confirmed-unsent retry. Refresh; respect provider cooldowns.
Leased / reserved	Processing or at the final submission cutoff. A lease alone is not permission to send; a reservation may already be in flight.
Sent / accepted	Provider acceptance receipt recorded. It is not recipient-read or device-notification proof. Never resend this channel to fix another.
Skipped / suppressed	Current gate, source, consent, identity, scope or expiry prevented submission. Do not broaden the audience or turn ON to replay it.
Cancelled	Unsubmitted selected work cancelled under the cutoff rules. Already accepted/in-flight requests cannot be recalled.
Failed, confirmed unsent	Use the channel’s explicit retry action only when it is offered and currently authorized. Rechecks still apply.
Unknown / uncertain	The provider may have accepted a write or its final receipt is unavailable. Never automatically retry or manually recreate the same message as recovery.

Partners history offers Retry failed telegram/discord copies and Cancel pending telegram/discord copies; Admin offers Retry Telegram/Discord failures and Cancel Telegram/Discord queued with confirmation. Use the channel-specific action, not email Retry failed or a second whole blast. After an uncertain retry/cancel result, Refresh bot delivery reads current state without replaying the mutation. A refresh is not a delivery attempt.

Known-unsent runtime retries are bounded to five attempts, use exponential backoff with jitter and respect valid provider cooldown hints. Unknown writes are terminal for automatic resend. Provider receipt acceptance is retained even if a later cooldown/finalization write fails; reconcile durable state rather than concluding a missing final response means the message was unsent.

Runtime, pacing and retention

The target host is Workers Free. Keep the existing bounded executor and shared notification budgets. Do not increase a plan, add a paid queue, add warming, extend deadlines or raise limits to make a release test pass.

Current official limits reviewed 2026-10-19: Workers Free has a ten-millisecond HTTP Worker CPU allowance, 50 external subrequests per invocation, up to 1,000 Cloudflare-service subrequests and 64 combined secrets/text variables per Worker. The earlier observed hosted inventory had 15 text variables and 47 secret names (62 of 64 slots); the isolated release candidate has 17 text variables plus those 47 secret names (64 of 64). Reconcile the exact deployed inventory before publication; no spare variable slot is established for that candidate. These are platform/configuration bounds, not measured feature capacity or positive hosted CPU evidence. See Worker limits and the subrequest limit clarification.

Mechanism	Current source boundary
Provider dispatch	At most one send per invocation; one provider POST has a ten-second deadline.
Private interaction	Actor-scoped existing Durable Object, original absolute eighteen-second envelope; no handoff retry or inline fallback.
Read budget	At most 32 accounted canonical read fetches per interaction; no authority is cached by this budget.
Paging/session	Up to ten cards per page; five-minute actor/identity/epoch-bound single-use controls.
Isolated bot maintenance	All bot cleanup/recovery work runs outside the shared email/platform cron batch. One of 17 bounded slots runs per due alarm; most slots use one service RPC, and materialization plus a fresh policy hint uses two before any separately dispatched wake. Existing helper deadlines and limits remain. Alarms are paced at least ten seconds apart; an idle full rotation takes at least 170 seconds, plus execution time. The ten-minute repair wake accepts timestamps anywhere inside the due UTC minute.
Data in the cleanup object	Version, next task, due time and a 17-bit backlog mask; original three cursor positions retain their meaning. No identity, receipt, message or QR content.
Callback/history access	Expiry is enforced before cleanup. History captures retain the existing expiry-plus-24-hour SQL rule; cleanup cadence and backlog determine actual deletion time.
Terminal delivery records	Sanitized receipts/attempt metadata are eligible for bounded cleanup after 30 days under current SQL. Verify the actual purge cadence; do not advertise universal deletion at the threshold.
QR	Generated bytes/payloads are not durably stored in new bot operational records. Provider messages, screenshots and downloads have independent retention and cannot be recalled.

Monitor shared account quotas, source arrival rate, oldest due work, accepted/ failed/unknown/suppressed counts, provider cooldowns, cleanup backlog and oldest eligible row. Use only sanitized metadata and counts; exclude destination IDs, ciphertext, authored messages, financial details, raw QR values and tokens. Audit retention follows the platform audit policy separately.

Check application-level error logs as well as runtime outcomes. A scheduled invocation can report ok after a processor catches a subrequest-limit error; that outcome alone does not prove lease renewal, email processing or cleanup. Keep the release OFF if shared jobs or isolated maintenance exhaust their budgets. An empty idle window does not certify populated production workloads.

The shared serial scheduler retains each task’s original required lease coverage. Renewals acquire up to 90 extra seconds of ownership, capped at 300 seconds, so quick tasks can reuse the lease. Network time consumes that grant; a failed renewal or insufficient remaining coverage stops later work. The normal release still frees the lease. Processor deadlines, notification policies and provider retry rules are unchanged.

An aborted HTTP fetch is not proof that PostgreSQL cancelled its statement. lock_timeout bounds lock waits, not total query CPU. Local SQL settings, finite synthetic cohorts and accepted local alarms do not prove sustained production capacity, complete memory, hosted cancellation or a 24-hour purge. Those observations belong in the release packet with their actual bounds.

Pause and recover an incident

1. Contain: If new bot privacy, duplication or authorization is in doubt, turn the master OFF with a reason and read back the policy. Preserve existing email and legacy bot paths. Do not remove credentials or disable the shared webhook as the routine feature rollback.
2. Assess the cutoff: Separate unsent/suppressed work from reserved, accepted and unknown requests. Preserve sanitized receipts and exact deployed versions. Do not promise recall of already delivered images/messages.
3. Preserve evidence: Record the environment, revision, time range, source family, sanitized counts/reasons and provider outcome. Keep credentials and personal content out of public tickets and shared release notes.
4. Repair deliberately: Resolve the source/identity/consent/runtime failure and verify normal permitted as well as denied paths. Keep maintenance active while OFF; do not delete deduplication history or rewind epochs to revive work.
5. Review re-enable: Confirm legacy email/bot health, current release proof and any unknown outcomes. A new authorized enablement covers future eligible work. It is not approval for backlog replay or another live test message.

For code rollback, use a reviewed compatible revision through the normal release process while OFF. Canonical migrations are additive; do not drop operational tables or apply a destructive schema rollback as routine recovery. Review compatibility of the Worker binding/class migration before changing versions.

Focused verification commands

Run only with installed dependencies and the reviewed synthetic/owned-local fixture configuration. These commands are checks, not publication or acceptance receipts. Run source-family/native/Worker/campaign suites selected by the exact release packet as well; do not replace them with this short list.

# partners-api
pnpm type-check
node scripts/test-interactive-bot-event-catalog.mjs
node scripts/test-interactive-bot-transaction-contracts.mjs
node scripts/test-interactive-bot-registration.mjs
node scripts/test-interactive-bot-telegram.mjs
node scripts/test-interactive-bot-discord.mjs
node scripts/test-interactive-bot-transport.mjs
node scripts/test-interactive-bot-qr-image.mjs

# partners.furries.ph and rego.furries.ph, separately
pnpm typecheck
pnpm build
# admin.furries.ph
pnpm typecheck
pnpm test
pnpm build
# docs.furries.ph, once after the coordinated content edits
pnpm check
pnpm build

The API read-only registration inventory tool is node scripts/check-interactive-bot-registration.mjs --check; it reads configured provider credentials and performs provider reads, so run it only in the intended authorized environment. It never registers commands. Preserve the existing menus and use the reviewed additive command plan for a separately authorized registration.

The additive setup tool defaults to provider reads and a dry-run plan:

# partners-api; provider can be discord, telegram or both for dry-run
node scripts/configure-interactive-bot-provider-commands.mjs --dry-run --provider=both
node scripts/test-configure-interactive-bot-provider-commands.mjs

Its separately authorized apply accepts one provider at a time and requires a fresh local release-check receipt. That receipt must identify the provider, affirm root authorization, verified hosted master OFF and the new Worker route, bind the current same-provider plan and hosted-evidence SHA-256 digests, and be no older than 30 minutes (no more than 30 seconds in the future). The tool reads identity and inventory again before writing and holds if evidence or the plan changed. Do not reuse a digest from another checkout or an old guide.

Discord setup adds or updates only its recognized /fph command with help, account, notifications, transactions and find in bot DMs; unrelated commands, guild inventory and supported installation types are preserved. Telegram setup only merges fph into the unlocalized private-chat menu while preserving the existing effective commands and descriptions. The tool changes no webhook, master switch or message. An uncertain provider write is not retried or rolled back automatically. Live apply remains held until the release owner records the hosted OFF/route checks; a dry-run is not registration or delivery proof. apply-git-integration:false does not authorize commit/push, publication, activation or provider messages.

Verified Join account association

Join copies require an explicit association proven through an email code in the owner’s signed-in account. The new association batch must be verified and published separately from earlier deployed bot code. Keep the master OFF during publication. Install the Join migration after the existing campaign and encrypted Auth-email-outbox schema, then publish API and account UIs through Git-linked builds.

Start and confirmation bind current policy, actor and entry generations; revoke and own-entry reads remain available while OFF. Proof email and challenge metadata commit atomically. Replay does not queue or wake another message. Credential email is excluded from bot copies. Entry withdrawal, ownership reassignment, disable/re-enable and changed campaign witnesses invalidate stale proofs and captured audiences.

Verify anonymous signup and existing email/inbox/bot senders independently. Local browser mocks and native synthetic rows do not prove hosted sign-in, mailbox delivery, provider delivery or production load. Retain failed native attempts and accept only the final source-pinned result. Expiry tests use the real fifteen-minute boundary. Twenty-four-hour retention remains a separate elapsed-time gate unless directly established.

The association migration was published on 2026-10-21 with the master still OFF and no enrolled accounts. Its qualified native suite passes 29 groups / 2,021 assertions, including real expiry, both providers and observer failure. Separate finite 500-entry samples pass under unchanged time limits. These results do not establish hosted capacity or real recipient delivery. Join previews label unique eligible accounts and entries without a separate copy; the inherited combined exclusion count includes duplicate representations and consent/readiness exclusions, without a separate numerical breakdown. Keep elapsed twenty-four-hour cleanup and genuine linked-user/provider/inbox/device acceptance open before activation.

Related operating guidance

See the user guide, event email communications, deployment and Wrangler, and data privacy and auditability.