Availability & service states
Understand the difference between published research, configured services and verified activity.
Research available
The website can serve the complete repository index, detail pages, documentation and Markdown briefs with no database, account gateway or model credentials. These pages present the bundled research snapshot.
Repository counts refer to indexed candidates. They are not counts of running applications, deployed contracts, active models or funded projects.
Storage unavailable
When the database is absent, catalogue and activity reads include storageUnavailable: true. Catalogue entries also expose votesAvailable: false. The overview supplies empty collections so the page can render; its default statistic values do not establish live balances or observed activity.
Consumers must honor the availability flags. A disabled vote, empty feed or unavailable treasury is preferable to representing an unsaved action as successful. The default Vercel runtime currently needs a durable database integration before these features can operate.
Configured is not a health check
The overview reports whether expected runner, RPC, router and repository configuration is present. For example, a runner flag means its URL and shared secret are set. It does not prove the service is reachable, has credit or can complete the next job.
A publication flag indicates a public repository is configured for display. Actual runtime publication additionally needs a scoped publisher token, enabled publication and passing privacy checks in the separate runner.
Activity must have evidence
A build feed entry is an authenticated runner event. A commit link points to an actual public commit. A reviewed patch is still separate from deployment evidence, and a successful contract deployment is separate from a token launch.
If no completed job or verified transaction exists, the corresponding section remains empty. No sample activity, estimated revenue or synthetic completed builds are used to imply adoption.
Known absence and unexpected errors
Known missing-storage conditions degrade to readable research pages. Other read failures return an error rather than quietly pretending the data is empty. Retry a failed read and investigate the actual response before changing configuration.
Preserve job identifiers and provider billing records after an execution failure. An uncertain dispatch or unknown cost must be reconciled before retrying paid work.