# Limitations and availability

> Important boundaries around Agreebase signatures, blockchain writes, providers, legal effect, and service availability.

Audiences: users, developers, agents
Kind: policy
Updated: 2026-07-12

Agreebase records evidence of text, proof-of-control steps, participant actions, and sealing. It does not guarantee every real-world or legal conclusion that a person might draw from that evidence.

## Legal and factual limits

Agreebase is not legal advice. A signature method does not prove legal capacity, authority, truth of every statement, consideration, enforceability, or the absence of coercion. Seek qualified advice for matters that require it.

## Content limits

Ordinary agreement and declaration bodies are limited to 350 normalized words and approximately 7,000 characters. Agreements have at most 15 signing participants including the initiator and five active witnesses. Notarizations have at most fourteen co-notarizers, a 64 KB normalized text limit, and a 300-word limit when public text is enabled.

## External providers

Email, GitHub, X, Reddit, Telegram, passkeys, storage, language-model assistance, and blockchain writes depend on configured providers and external availability. A signature method can be unavailable even when the record itself exists. Use another available method where the record permits it.

## Background processing

PDF generation, PDF signing, email delivery, share-card generation, and blockchain writes can be asynchronous. A sealed record can temporarily show a pending document or blockchain status. Keep the AGR reference and retained artifacts; do not assume that a successful HTTP response means every side effect has completed.

## Permanence and later changes

Confirmed blockchain data cannot be edited or unpublished. Agreebase preserves earlier records when later amendments, cancellation records, or superseding records are created. A newer record may become current authority without rewriting the older chain commitment.

## Operational guidance

Integrations should inspect status, version, next actions, and structured errors. Do not blindly retry a mutation after a timeout. Re-read the record first and use the current lifecycle state.