Privacy and terms

Use the smallest record that can answer the question.

This build combines local tools with live integrations. The Forecast Lab stores its ledger in the browser. The Commons can read public Solana data and send questions or contributions to Telegram when deployed with its server functions.

Before a wider public launch: identify the legal operator, jurisdictions, contribution terms, refund rules, data processors, retention periods, security measures, and contact channels in a final legal notice.

Local records

What stays in your browser

The Personal Forecast Lab stores forecasts, deadlines, outcomes, and scores in the browser's localStorage. Demo-mode funding and question records are also stored there. Opening the ZIP locally does not activate the deployed Telegram or Solana server functions.

The local records can include:

  • personal forecast questions, inputs, probabilities, deadlines, outcomes, and Brier scores;
  • the simulated funding total and most recent simulated offering when demo mode is active;
  • demo question requests, including any Telegram username or context entered in the form.

Anyone with access to the same browser profile may be able to read those records. Avoid entering sensitive information unless it is necessary for the forecast. The ledger can be exported as JSON and removed through the interface or by clearing site data in the browser.

Live data flow

What the deployed service can process

The deployed routes can process a Telegram username, question, context, deadline, retention choice, contribution reference, proposal text, optional image, abuse-prevention logs, and technical security logs. The public funding route also reads the published Solana wallet and a market price feed.

01

Public wallet

Direct transfers to the published Solana address are public on-chain. The site does not connect to a user wallet, request a private key, or handle card or bank credentials.

02

Question review

The question, supporting context, and Telegram username are forwarded to the private reviewer channel so the evidence can be assessed and an answer returned.

03

Security and abuse prevention

Limited logs may be used to authenticate routes, rate-limit submissions, detect automated abuse, and investigate failures or misuse.

04

Research

Research reuse should require a separate, specific opt-in. Removing direct identifiers does not always eliminate re-identification risk, especially in detailed personal narratives.

A final notice should identify the responsible entity, contact details, lawful bases, processors, international transfers, retention schedules, complaint routes, and which fields are required.

Question covenant

Terms of the question service

One contribution is intended to support one question, regardless of size. The current amount selector opens the question form but does not itself transfer funds or automatically match an on-chain transfer to a submission.

The 48-hour period is a response target when the available evidence is sufficient. A valid response may:

  • give a probability range with assumptions and uncertainty;
  • request more information or a clearer resolution rule;
  • state that the available information is insufficient;
  • decline the request and explain the applicable boundary.

Before adding card or bank checkout, the operator must publish the payment provider, tax treatment, refund and cancellation rules, eligibility, geographic restrictions, response window, and what happens when a question cannot be answered.

Contribution size does not change the evidence. A larger offering does not justify a more confident answer.

Scope boundaries

Questions outside the service

The service does not provide diagnosis or treatment, legal conclusions, personalized investment instructions, emergency decisions, criminal accusations, stalking assistance, hidden-trait inference, employment or tenant screening, or forecasts about a private person who is not participating.

A forecast from the Order should not be the sole basis for a high-impact decision about another person. No rank within the Order depends on a forecast score.

User controls

Access, correction, and deletion

A hosted service should provide a clear route to request access, correction, deletion, restriction, export, objection, and withdrawal of optional consent where applicable. A user should also be able to challenge the factual inputs, assumptions, reference class, and interpretation used in an answer.

Human review remains part of the question service. Automated model output should be labeled and separated from the reviewer's interpretation.

Intellectual property

An original project, not an adaptation

The site uses the general idea and English term psychohistory as a conceptual starting point. It does not reproduce plot, characters, quotations, fictional institutions, distinctive terminology, artwork, logos, or screen designs from Isaac Asimov's works or their adaptations.

The Order of Possible Futures, the Canon of Contingency, the doctrine, liturgies, explanatory text, visual system, and software were created for this project. Isaac Asimov, his works, associated publishers, estates, and adaptations remain the property of their respective rights holders. No affiliation, sponsorship, approval, or endorsement is claimed.

Before launch, conduct jurisdiction-specific clearance for the final organization name, domain name, service description, logo, fundraising language, and any later material added by contributors.

Before launch

Required decisions

  1. Name the legal operator and the entity receiving funds.
  2. Define whether contributions are donations, memberships, purchases, or another legal category.
  3. Complete payment, consumer, fundraising, tax, nonprofit, and data-protection review for every target jurisdiction.
  4. Publish final terms, privacy notice, cookie notice if needed, refund policy, safeguarding policy, moderation policy, and contact details.
  5. Use verified payment webhooks and one-time question tokens. Never trust query parameters or browser storage as proof of payment.
  6. Document access control, encryption, backups, incident response, deletion, retention, vendor review, and administrator authentication.
  7. Separate automated model outputs from human interpretation and preserve an auditable record of assumptions and revisions.
  8. Test accessibility, mobile behavior, failure states, abuse cases, and data deletion before taking real submissions.

Not legal advice: the correct obligations depend on the operator, service model, users, countries, data, payment structure, and deployment architecture. Obtain qualified review before collecting real money or personal information.