MCP activity and scientific calculations
The public observatory keeps the most recent 50 activity events in application memory. These events contain the software client’s declared name and version, an opaque session identifier, called tool, event state, timestamp and, when available, duration and execution backend. The history is replaced as new events arrive and disappears when that gateway process restarts.
Client names are self-reported. They do not verify an AI model or provider. Do not put an email address, personal information or secret into clientInfo. Calculation arguments, scientific results and detailed mission or composition events are not published in this activity stream. They pass through the calculation service to answer the requesting client.
Aggregate operations and signed receipts
The gateway retains daily counters by approved tool and outcome for 90 UTC days. These aggregates contain no IP, session, arguments or results. Private test instances use separate state. Authenticated operator reports keep internal test and deployment labels separate when configured. Public monitoring retains seven days of sampled component states and probe latency, with gaps explicitly unknown. Aggregate durations describe observed instrumented calls, including failures, not a latency guarantee.
Website and external MCP usage
Separate private counters distinguish tool calls submitted through the website from calls to the external MCP endpoint, and count MCP initialization and catalogue requests separately. They retain UTC-day totals by registered tool, outcome and authenticated operator/public source for 30 days. They contain no client identity, IP address, session identifier, credential, arguments or results. An external connection is not a unique user, and public traffic may include unmarked tests or automation. Older mixed counters are not retrospectively assigned to either channel. When you open a “view in 3D” link returned by an assistant, the page sends only the tool name so that opens can be counted; the calculation arguments stay in the URL fragment and are not sent unless you start the calculation. Calculations started from such a page are counted again in a separate aggregate with the same dimensions and 30-day retention.
A dedicated origin log counts successful GET requests to a fixed list of public HTML pages. Each entry contains its time, page, HTTP status and a broad declared client class, with no raw user agent, IP, query, referrer or cookie. The current log and up to seven daily rotations are retained. The private dashboard reads the current bounded log and states its observed period; it does not report unique people. CDN cache hits may not reach the origin. No analytics cookie or browser fingerprint is introduced by this measurement.
Verify receipts are generated for the requesting client and are not stored on the server. Their signature attests service origin and integrity under a stated scope; it does not certify the supplied data or scientific truth. Download a receipt to retain it. A saved receipt checked in the browser is not uploaded.
Optional client keys and quotas
Public access remains available without a key. If the operator issues you an optional access key, the service stores only its SHA-256 hash, a random key identifier, issue/expiry/revocation dates, a daily attempt limit and the current UTC-day count. It stores no email, IP, arguments or calculation results in this credential record. The key is checked before each request and a submitted tool-call attempt is reserved durably before execution. A rejected or inconclusive calculation may still consume an attempt; this is not billing.
Records are restricted to the operator, bounded to 100 keys and retained until the operator removes or replaces the credential store; expiration or revocation alone does not erase a record. They are not published in the observatory or the aggregate usage endpoint. A holder can inspect their own quota through the authenticated access-status endpoint. The initial private handoff file is separate from the hash-only store and must be transferred and removed through the operator’s private procedure. Infrastructure backups have their own retention.
Subscriptions and account access
Stripe processes card payments and retains its payment records under its own terms. ScoreCompute retains Stripe customer/subscription references, entitlement state, credential hashes, a protected server key-derivation seed, current daily execution and minute request counters, and a bounded deduplication journal of webhook identifiers in restricted storage. The key-derivation seed permits server-side derivation of credentials and is protected as a secret; the store is not described as irreversible hashes alone. No payment card details, tool arguments, scientific results or receipt history are stored in this account file.
The account uses a secure HttpOnly session cookie lasting up to 30 days. An independent recovery code restores owner access and changes after recovery; MCP keys do not grant access to billing. Account records are retained while the account exists and until an operator processes deletion; cancellation alone does not erase the record. Contact contact@scorezenith.com for a data request. Stripe financial records and infrastructure backups have separate retention. Account endpoints use private no-store responses, and account management is excluded from indexing.
Usage requests
If you submit the usage request form, we retain your email, selected usage category, optional use-case description (up to 500 characters), expected daily request range, hosting preference and consent timestamp in restricted storage for 30 days, then delete it at the next hourly cleanup while the service runs. No payment is collected, no capacity is reserved and no automatic marketing message is sent. Describe your workflow without credentials, personal data or confidential inputs. Identical requests are deduplicated without extending their retention; different requirements create a separate request. Request deletion at contact@scorezenith.com. In-memory rate limits use a process-specific HMAC of the connection address and expire; the stored interest record has no IP.
Contributor registrations are persistent
After your explicit Start action, the coordinator retains a registration containing your chosen alias, installation identifier, client version, declared resource identifiers and hardware, offers, pause state and last heartbeat. It stores a SHA-256 hash of the authentication token, not the original token. The original coordinator token remains in the local client’s protected settings file.
The registry holds at most 128 registrations. Registrations have no automatic age-based deletion in the contributor network. Pausing or becoming stale makes resources unavailable; it does not delete their registration. Aliases, short opaque public IDs, reported hardware and offers, states and heartbeat ages are visible through public network status. Authentication tokens, installation IDs, raw resource identifiers and client IPs are not included in that public response.
Revocation and previously accepted work
Use Revoke registration in the local dashboard to remove the active coordinator registration and invalidate its outstanding assignments. The client reports a network failure instead of claiming that an unreachable coordinator accepted revocation. Revoke before changing a registered public alias.
Previously accepted samples stay in retained job records and cumulative totals. Internal job records may retain an opaque contributing-worker identifier until that job is pruned; public receipts show a contributor count rather than those internal identifiers. Revocation does not retract an already published synthetic receipt or copies obtained by another visitor.
Public synthetic jobs and bounded receipt retention
Contributor jobs contain a sample count, seed and backend preference. The schedule_probe_v1 workload additionally selects one of three compiled public scenario identifiers and requires CPU; pi_chunk_v1 also supports CUDA. Receipts expose their status, completed counts, final π estimate or schedule success rate when complete, contributor count, verification time and job timestamps. Schedule receipts separate worker-reported compute time from measured coordinator verification and elapsed time. No private dataset, file or arbitrary program is accepted by the contributor network.
The coordinator retains at most 64 job records, with no more than 16 active jobs or 320 retained chunks. A job has a 120-second execution lifetime. That lifetime is not the retention period: completed or expired records remain until admission of new work requires space, when the oldest terminal records are pruned first. A pruned receipt returns 404. Cumulative validated-sample and completed-job totals survive receipt pruning.
Separate public contributor activity journal
The contributor endpoint /api/network/v1/activity keeps at most 256 transition events in memory and returns at most 128 per response. Events describe synthetic job creation, assignments, accepted verified chunks, completion, expiry and released leases. They include job identifiers, timestamps, sample counts and, where relevant, the same short public worker identifier and CPU/CUDA backend used in public status.
This journal publishes no authentication tokens, full private worker identifiers, raw resource identifiers, installation IDs, IP addresses, hostnames or aliases. The website may join a short worker identifier to the separately published status alias. Each response also includes a bounded snapshot of up to 16 active and eight terminal synthetic job receipts; this 24-receipt snapshot does not replace the 64-record storage limit above.
The event ring resets on coordinator restart. A reset response is recent history, not evidence of fresh computation; restored job receipts do not generate invented historical events. An assignment is not proof that execution began, and event animation is not a GPU utilization measurement. This journal is distinct from the gateway’s 50-event MCP observatory.
Local client storage and controls
The client stores its settings, installation identifier and coordinator credentials in the user profile: %LOCALAPPDATA%\ScoreCompute\contributor on Windows, or $XDG_DATA_HOME/scorecompute/contributor, normally ~/.local/share/scorecompute/contributor, on Linux. Closing the client does not delete those settings. Every new launch starts paused.
The browser dashboard is a protected loopback control surface. It receives a separate local control secret; the coordinator authentication token is not exposed to the page. The client runs only the two compiled public workloads and does not upload private files or download executable jobs.
Rate limits, infrastructure and backups
The contributor coordinator uses private in-memory IP-based rate buckets for admission. Inactive buckets are reclaimed after 120 seconds and all buckets reset when the process restarts. These addresses are not stored in the coordinator’s durable registration/job state or published in status. This is distinct from persistent worker records and receipts.
The origin configuration disables ordinary access logging for the contributor API. Hosting, operational error logs and Cloudflare’s network and security services are separate from these application stores; they may process connection metadata needed to deliver and protect requests. The 50-event observatory limit does not define their retention.
Restricted operational backups may preserve earlier coordinator state during deployment and recovery. Revocation removes the active registration; it does not automatically rewrite older backups. This notice does not promise immediate erasure from every infrastructure layer or a backup expiry period that has not been configured.
Visitor suggestions
The suggestion form stores your proposed theme, question, input description, expected output and optional use case, with a random receipt ID, submission time and pending-review status. It requests no name, email, file or account. Please do not include personal data, private datasets, credentials or confidential text.
Suggestions are private to the site operator and are not published automatically. The live inbox retains at most 1,000 records for 90 days, with cleanup at startup, on writes and hourly while the service runs. A full inbox refuses new submissions rather than silently discarding them. Request addresses are used only through salted in-memory rate-limit keys, not stored in suggestion records. The origin disables ordinary access logs for this endpoint; infrastructure security services may still process connection metadata.
The browser retains only the last receipt metadata (ID, review status and retention date) in session storage for the current tab. The written form is not saved in browser storage. Reloading does not resubmit a request. Keep the receipt if you need the operator to locate a suggestion. Restricted infrastructure backups may retain earlier state separately.
Questions about your data
Write to contact@scorezenith.com for questions about ScoreCompute or retained data. Do not send authentication tokens. A public alias or job identifier can help locate the relevant record without exposing a credential.
Read the contributor installation and workload guide, or review the MCP connection and privacy boundaries.