Skip to main content
FFiscal Vitals
TermsSupportHome

Prelaunch draft · not yet in effect

Privacy policy

This draft describes this website as it works today and the mobile-app behavior supported by the reviewed source. Production configuration, the legal operator, contact channel, and final store disclosures still require verification before launch.

ON THIS PAGE

Status and scopeWebsiteApp dataAI processingProvidersUse and sharingRetentionChoices and deletionRights and safeguardsContact
01

Status, scope, and controller

This is a prelaunch draft, not a final policy. It covers this Fiscal Vitals website and the intended Fiscal Vitals mobile app. The app is in development and is not offered for download from this page.

Public materials associate the developer portfolio with Momentary Lapps, LLC, but the owner has not yet confirmed the exact legal entity that will publish Fiscal Vitals and act as data controller. That entity name, its jurisdiction, and a verified privacy contact must be inserted before this policy can be used for an app-store submission.

02

This website

This website uses local assets and contains no email signup, newsletter integration, contact form, page analytics, advertising pixels, third-party fonts, or tracking scripts. The page does not ask for or collect an email address. Its launch status is simply “Coming soon.”

The website itself does not set cookies or write visitor details to browser storage. The hosting provider may still process ordinary request data—such as IP address, browser or device information, requested URL, and timestamps—in infrastructure and security logs. Access-protection features of a website host may also use necessary cookies. Those host-level practices and retention settings must be confirmed for the final production host.

03

Data the intended app may process

The reviewed app source does not provide a user-facing account sign-up or ask users to connect bank, brokerage, or other financial accounts. It does process public fiscal data and may process the following categories, depending on which launch features are actually enabled:

  • Questions and saved app content. Questions entered into the assistant, generated explanations, source records, citations, and operation status can be stored in bounded journals on the device so a user can reopen or recover work.
  • Preferences and feature state. Assistant-processing choices, local usage counters, and other settings can be stored on the device.
  • Anonymous session and network data. Optional online readers and cloud-assistant routes use an opaque anonymous session rather than a named account. Requests to public-data or app services necessarily expose ordinary network metadata, such as IP address and request timing, to the receiving infrastructure.
  • Product analytics. If PostHog is configured in a launch build, the app can send allowlisted feature events, bounded durations, app/build context, and opaque SDK transport or session identifiers. The implementation disables geolocation enrichment and person-profile processing. It is designed to exclude questions, evidence packets, and free-form user content from analytics events.
  • Crash diagnostics. If Sentry is configured, the app can send crash types, redacted error values, code stack information, app/build context, and a limited set of navigation breadcrumbs. The implementation disables default personal-information sending, screenshots, view hierarchies, failed-request capture, replay, profiling, and performance tracing.
  • Purchase and entitlement information. If subscriptions are later activated, Apple or Google handles payment details. RevenueCat may process an anonymous customer identifier, store product and purchase status, entitlement status, renewal or expiry information, and a subscription-management link. The current integration disables automatic device-identifier collection and RevenueCat diagnostics.

These categories are source-supported possibilities, not a statement that every service is active in a production build. Final behavior must be tested against the exact submitted binaries and live provider configuration.

04

Assistant and AI processing

Fiscal Vitals can answer supported questions deterministically from public records. The source also supports optional AI-assisted wording routes:

  • On-device Apple processing is intended to remain on the device on supported Apple hardware.
  • Apple Private Cloud Compute is an off-device Apple processing route and must not be described as on-device.
  • External cloud processing can send a question and a constrained evidence/request packet through Fiscal Vitals infrastructure to an external model provider such as OpenRouter.

The reviewed settings use an “On-device AI” label and separately mark external cloud AI unavailable. That label alone must not be read as a guarantee that every Apple processing path stays on the physical device: Apple Private Cloud Compute, when used, is off-device and is distinct from the external OpenRouter route. Actual availability and routing must be verified in the submitted build. Dispatch is guarded by feature configuration and processing policy in source. If a cloud route is enabled for launch, the app must present an accurate, prominent choice before sending question content or evidence off device, identify the active provider route, and keep revocation behavior working. Do not put personal, confidential, or financial-account information in a question.

Cloud operations may create bounded app-server operation records to prevent duplicate dispatch and permit recovery. Provider-side handling, retention, training use, regional processing, and contractual deletion behavior have not yet been verified for production and must be confirmed before activation.

05

Potential recipients and service providers

Depending on final launch configuration, data may be processed by the app-store platform and by providers used for hosting, networking, storage, analytics, diagnostics, billing, or AI processing. The reviewed source includes optional integrations for PostHog, Sentry, RevenueCat, Apple on-device and Private Cloud Compute capabilities, and an OpenRouter-backed server route. Infrastructure source also supports hosted API and bounded key-value storage.

A provider appearing in source does not prove that it is active, configured, or approved for launch. Before publication, the operator must verify the exact provider list, roles, contracts, production regions, subprocessors, retention settings, privacy terms, and store declarations. Links opened by a user—including government sources, app stores, or a native share destination—are governed by the recipient's own terms and privacy practices.

06

Why data is used; sharing and sale

Data may be used to deliver requested app features, retrieve and cite public fiscal records, preserve or recover local work, prevent duplicate or abusive requests, verify purchases, diagnose failures, understand feature reliability, provide support, secure the service, and meet legal obligations.

The reviewed source contains no advertising SDK or targeted-advertising flow. Fiscal Vitals does not intend to sell personal information or share it for cross-context behavioral advertising. Service-provider processing needed to operate a requested feature is different from selling data. This statement must be rechecked against final contracts, enabled SDKs, and the legal definitions applicable where the app is offered.

Information may also be disclosed when required by law, to protect users or the service, or as part of a properly governed business transaction. No such disclosure removes the operator's obligation to use appropriate safeguards.

07

Retention and deletion limits

On-device journals are designed to be bounded by record count, storage capacity, and record expiration rather than grow without limit. Some assistant operation records are also designed with bounded expiration for recovery and duplicate prevention. Removing app data generally removes app-managed local records, subject to operating-system backups and restore behavior.

Final production retention periods for hosting logs, analytics, diagnostics, purchase records, support correspondence, anonymous sessions, and cloud AI providers have not been verified. The operator must set and document those periods before launch. Data should be retained only for the purpose stated, legal or security obligations, dispute handling, and the time needed to complete a valid deletion request; it should then be deleted or de-identified where feasible.

08

Your choices and deletion

  • Use deterministic answers without enabling AI where the app offers that choice.
  • Keep questions out of a cloud route unless you affirmatively choose an available off-device option.
  • Remove app-managed local content by using any in-app controls provided in the submitted build or by clearing the app's storage/removing the app, recognizing that device backups may behave differently.
  • Manage or cancel an active store subscription through Apple or Google. Deleting app data does not itself cancel a subscription.
  • Review the data deletion page for local steps and the unresolved service-held-data request-channel gap.

The source does not currently create a user-facing Fiscal Vitals account, so there is no account to delete in the reviewed architecture. Anonymous or pseudonymous records may be difficult to locate without an appropriate support reference. Never send a password, payment-card number, or full assistant question in a deletion request.

09

Rights, children, international processing, and security

Depending on where you live, you may have rights to ask about, access, correct, delete, restrict, or object to certain processing, or to withdraw consent. Those rights can be subject to identity verification, legal exceptions, and limits where data cannot reasonably be linked to you. A verified privacy-request mechanism and response procedure remain launch blockers.

Fiscal Vitals is designed as a general-audience public-finance information tool, not as a service directed to children. The final target-age declaration and any child-specific obligations must be confirmed in both stores before release. The app should not knowingly request personal information from children.

Providers may process data outside a user's state, province, or country. The operator must verify production processing locations and any required transfer safeguards before launch.

The source applies data minimization, allowlists, redaction, bounded storage, and encrypted HTTPS destinations in relevant flows. No technical system is perfectly secure. Production access controls, incident response, provider settings, and transport/storage protections must be validated before this draft becomes effective.

10

Changes and contact

The effective policy should show an effective date and be updated when data practices materially change. App-store privacy declarations and in-app disclosures must change with it.

A dedicated, tested Fiscal Vitals privacy mailbox or request form has not been verified. No unverified address or form is presented as a working privacy channel. Until the legal operator and contact mechanism are confirmed, this draft is not store-ready.

Visit support

FFiscal Vitals

Prelaunch legal drafts

PrivacyTermsSupportData deletion