TailTally event catalogues and private Signals

TailTally keeps its catalogue, stock, checkout and finance records on the device. Its optional Furries PH connection lets an eligible dealer publish a reviewed event catalogue. Private TailTally Signals follow a separate partner policy controlled by FPH Admin. Connecting never makes the server an inventory master.

Implementation status, 2026-10-21: cross-repository source implementation is under local validation. This page describes the supported implementation path; it does not establish that a hosted API, database migration, native release or partner configuration is active. Windows and Android are the first native validation targets. Other platforms retain separate acceptance gates.

Connect and link an event

1. Open Extensions: In the installed TailTally app, enable the Furries PH connection and choose Connect account in browser. Network-off prevents connection and sending. Local selling continues without an account.
2. Use the system browser: Sign in to the FPH account that owns the Dealers Den registration. Complete existing account security, including MFA when required. TailTally does not collect your password, website cookies or pasted access tokens. The native connection uses a scoped authorization code with PKCE and a registered callback.
3. Review technical access: Select the eligible registrations and review the connection’s event, catalogue, media and private Signals capabilities. Consent is already held in the owner’s separate system. This review grants technical account access; it is not another consent form or a duplicate consent record.
4. Return to TailTally: Check the account connection, then refresh eligible registrations. The server rechecks ownership and current confirmed, approved, fully paid dealer eligibility. A previously visible cached registration cannot authorize a new upload.
5. Choose the local event: Link an existing local event or create one from the eligible registration. Products stay in the same app-wide catalogue; linking does not duplicate it or copy remote stock into the local ledger.

If the connection expires, reconnect through the browser. Account changes, profile changes and restore must not attach a pending callback to another local profile. Rego’s connection-management controls revoke technical grants; revocation does not remove local products, sales or event records.

Publish an event catalogue

1. Select the event: Use its linked local event and choose the products, variants or bundles being brought. Nothing is selected automatically.
2. Choose public fields: Price and stock quantities are independently optional. Choose images separately. Stock is an as-of snapshot, not a reservation, live availability guarantee or cross-device inventory service.
3. Review the fixed snapshot: Check the public preview before publishing. Customer details, production costs, private finance records and Signals are excluded. A sale after preview preparation does not silently alter it.
4. Publish: Wait for a confirmed publication revision. If the result is uncertain, retry the same pending operation rather than preparing a duplicate. If another device changed the online catalogue, refresh and review again.
5. Withdraw when needed: Use Unpublish catalogue and wait for confirmation. Disabling the extension or disconnecting stops future sends but does not itself remove a previously published catalogue.

Catalogue metadata is API-managed Supabase data. Images reuse the existing FPH API Sanity upload and read proxy: POST /api/upload-image and /api/img/…. There is no separate TailTally media service, proxy endpoint or Sanity credential in the app. The API checks media ownership and current live attachment; withdrawn catalogue media must not be retrievable through a stale public link.

Partner websites consume the bounded public catalogue projection at GET /api/v1/public/events/:eventId/dealer-catalogues or its /:catalogueId detail route. They use returned proxy image URLs. These routes do not provide private Signals or internal registration/payment identifiers.

Configure private Signals in FPH Admin

Open TailTally configuration in Admin. Only the exact FPH administrator authority can change partner policy; being a partner administrator or ordinary platform staff does not confer that right. The API also requires the established recent-MFA checks.

1. Find the partner: Search the partner directory and load its saved policy. An unavailable policy is not permission to enable access.
2. Choose access: Leave access disabled, enable sanitized analytics, or explicitly select full / unscrubbed business Signals. The initial policy is disabled; sanitized is the initial disclosure mode. Full mode additionally requires an inclusive start and end date for explicitly linked events. Review those dates before authorizing historical financial activity.
3. Review and save: Enter the operational reason and review the affected partner, disclosure mode and full-mode date window. A confirmed revision and audit receipt establish the policy change. Conflicts require a fresh policy read; edits to the window require their own reviewed policy revision.
4. Check the result: Verify EMS visibility with the intended partner/event permissions. Admin enablement does not grant access to unrelated events.

Policy	Partner receives
Disabled	No Signals navigation, page content, API report or export.
Sanitized	Coarse cohort analytics with small groups suppressed; no dealer identity, stable pseudonym or identifiable source-row export.
Full / unscrubbed	Permitted dealer-identifiable business Signals and source rows for explicitly linked events within the reviewed inclusive history window, plus the disclosed current-state/model exception below. No credentials, payment instruments, unrelated customer data or raw private files.

What the full-data history window authorizes

Full mode requires a valid saved window scoped to explicitly linked events. TailTally intersects that window with the linked event’s activity dates, including related participation expenses. It never widens the requested range or exports every event on the device. With no overlap, it sends no contribution and does not advance the acknowledgment as though a send succeeded.

Financial activity follows the existing date basis: sales and refunds use their creation time in the event timezone, finance uses posting dates in the reporting timezone, and expenses use effective dates. Those activity facts must fall inside the transmitted reporting window, which must fit the current Admin authorization. The sale’s separately selected business day is preserved as recorded; it does not replace the timestamp used to decide whether the sale falls inside the window.

Current-state/model exception: current packed stock, event assortment and the current reviewed planning model remain current-state snapshots. They are not a reconstruction of historical inventory balances or financial activity for the authorized period. Planning assumptions and cost/return provenance may refer to older source dates. Admin confirmation and EMS disclose this distinction; do not label those inputs as period actuals.

An older saved full policy without a reviewed history window is inactive for native policy access, ingestion, EMS capabilities, reports, comparisons and exports until an FPH Admin reviews and saves bounded access. Admin can still inspect that legacy policy and its technical audit. No automatic authorization or synthetic Admin decision is created. Sanitized mode remains compatible with existing bounded/cohort behavior and requires no full-data history window; it does not gain identifiable drilldowns or weaker suppression rules.

Policy is rechecked on ingestion, report reads and exports. Changing the window creates a new policy revision, invalidates prior contribution payloads and changes the native scope-bound source digest even if local facts are unchanged. A prior acknowledgment cannot suppress publication under the newly reviewed policy epoch. Source compare-and-swap checks prevent overwriting a newer contribution. Pending full batches without a valid window, or with an old mode, epoch or range, cannot be replayed under different authority; changed bodies need new operation IDs. An uncertain request retains its exact retry identity and reconciliation path.

Previously downloaded files cannot be recalled. Existing external consent records remain authoritative; the date-window review is technical authorization, not a new dealer consent form or a second consent ledger.

Read TailTally Signals in EMS

The TailTally Signals section is hidden by default. It appears only after the server confirms that the selected partner is enabled and the user can access the selected event. Direct navigation is subject to the same API permission checks. Unavailable or disabled capability checks must not display stale report data.

Page	Read it for
Sales	Units sold/returned, gross/net sales, discounts, tax and supported finance/cost recovery metrics.
Logistics	Event stock and planned quantities, participation expenses and the coverage limits on what was physically brought or prepared.
Trends	Comparable event observations and completeness; unsupported forecasts remain unavailable.

The pages are /ems/manage/tailtally-signals/sales, /logistics and /trends within the current EMS event context. Exports use the same current authorization and disclosure projection, rather than a second unrestricted download. Full-mode reports show the authorized inclusive period and the current-state/model exception. A policy-window or source change invalidates stale pagination/export results instead of mixing different snapshots.

Keep currencies separate. Unknown cost is not zero; incomplete cost coverage does not establish profit. Cash movement differs from earned revenue, and a commission deposit must not be counted twice. Stock reports distinguish current event stock from historical or unpacked stock; plans differ from completed physical movement. Suppressed metrics are not missing zeroes. As-of dates and coverage labels are part of the result and must stay visible when interpreting it.

The public catalogue’s price and stock switches do not control private Signals. Admin policy controls that separate stream. A native Send current event Signals action must use current policy and canonical local records; offline checkout does not wait for the network or ask the dealer to enter sales and expenses twice.

Operator verification and release boundaries

1. Configure only after review: Apply the reviewed canonical migrations and API bindings through the normal release process. Keep the API’s TAILTALLY_ENABLED feature switch disabled until coordinated acceptance is complete. Existing Sanity configuration is reused; no second media deployment is required.
2. Verify normal and denied flows: Check owned paid eligibility, callback return, event reuse, publication, proxy images and withdrawal. Check disabled, sanitized and full Signals with both authorized and unauthorized event users.
3. Verify on native platforms: Validate system-browser return, protected credentials, restart, offline selling and network-off on Windows and Android. Browser fixtures and compilation do not establish those native flows.
4. Record exact evidence: Separate source/tests, native device or emulator, hosted migration/API, provider media and real-account verification. Do not infer a live release from a static documentation build.

If upload or policy outcomes cannot be confirmed, preserve the operation identity and escalate using sanitized support details. Do not attach credentials, customer records, raw dealer business exports or private images to public reports.