Activity · Limits
Beta limits and known gaps
Activity has a repository-verified core and a canonical beta contract. It does not yet have the packaging, enforced budgets, operational objectives, or downstream proof required for a production-ready infrastructure claim.
Published contract limits
| Surface | Current contract |
|---|---|
| Timeline, profile, and comment page size | 1 to 100, default 50 |
| Gateway timestamp tolerance | 300 seconds by default, deployment-configurable |
| Tenant selection | One signed UUID in x-tenant-id |
| Actor selection | One signed non-empty x-actor-id |
| Post visibility | public, followers, or private |
| Timeline order | ranked_at DESC, then entry UUID descending |
| Public API style | Signed HTTP only, no public WebSocket |
These are contract properties, not managed-service quotas or service objectives.
Missing enforced budgets
Activity does not publish a supported ceiling or rate budget for:
- requests per actor or tenant
- post, comment, metadata, or render-reference payload size
- followers per actor or fan-out batch size
- concurrent jobs or queue depth
- maximum fan-out or counter convergence delay
- rebuild duration or recovery throughput
Do not invent client-side assumptions for these values. A deployment may still have framework, database, or infrastructure limits, but those are not a portable Activity contract.
Retry and consistency boundaries
Publish accepts an optional caller-supplied idempotency_key. Reuse the same key for duplicate-safe retries within one tenant and actor. Activity does not define a global retry budget, backoff schedule, or public replay API.
Fan-out and counter aggregation are asynchronous. Their effects converge under repository-tested retry behavior, but no public latency objective exists. Rebuild is an internal viewer-scoped worker with no customer HTTP trigger.
Product model gaps
| Area | Current gap |
|---|---|
| Follow policy | No protected accounts or follow requests |
| Post lifecycle | No public visibility change or restore operation |
| Moderation | Report exists, but review and moderation transitions do not |
| Rich content | render_refs lacks formal mention, media, and link validation |
| Shares | Attribution and nested rendering rules are still being hardened |
| Host events | Outbox rows exist, but webhook delivery and retry policy do not |
| Data lifecycle | No public retention, export, erasure, or tenant-offboarding contract |
Activity does not own chat, presence, room membership, read receipts, typing indicators, recommendation policy, or host rendering. Those are boundaries, not missing features.
Authentication and tenant gaps
The gateway secret is deployment-wide, not tenant-specific. Per-tenant key registration, a documented secret-rotation contract, and a customer credential control plane are not established.
Tenant isolation uses tenant_id attributes and query filters. It is not schema-per-tenant isolation. Hosts must choose their tenant topology and protect the gateway signer.
Packaging and operations gaps
There is no supported SDK or generated client release. Production deployment manifests, published images, restore proof, alerts, SLOs, RPO, RTO, SLA, support policy, regions, and pricing are not established.
Local tests and formal checks do not establish production capacity or operational readiness.
Proof and adoption boundary
Repository tests and the FeedCore TLA+ model support the core safety and convergence claims documented here. The current boundary snapshot does not show a downstream production integration. Activity therefore remains a contract beta, not an integrated or production-ready service.
The evidence page records what is proven and what is not.