Contract tracker scaling and launch checklist

• Pagination: Contract, document and audit lists use keyset pagination on (updated_at, id) and always include the matter-membership predicate; no OFFSET.
• Caching: Template and clause catalogues are cached per org by version; document content and search results are never cached across users.
• Rate limits: Signing pages and intake forms are rate limited per IP and token; uploads and assembly requests have per-user limits.
• Search: Full-text search uses a GIN index on extracted text with matter-membership filtering in SQL; add a dedicated search service only after p95 exceeds 800 ms at 1M documents.
• Storage: Documents are immutable objects under non-guessable keys with signed reads; lifecycle rules follow the retention class.
• Data growth: audit_log is partitioned by month; document_versions retain every version but extracted text of superseded versions may be compressed.

• Metric contracts by status age: time in each status by contract type.
• Metric signature completion rate: completed over sent, by age bucket.
• Log document access log: request id, actor, document id, action; contents excluded.
• Trace signing trace: link open, consent, signature, certificate.
• Slo obligation reminder delivery: 99% of reminders sent within the lead-time day.
• Alert audit chain break: verification failure pages immediately.
• Alert extraction backlog: extraction queue older than 15 minutes.

• obligation_reminders: runs cron daily. Guard: one notification per (obligation, threshold); owner or delegate only.
• extract_text: runs queue (jobs) on upload. Guard: size and page caps; failure leaves the document usable but unsearchable.
• expire_signature_requests: runs cron hourly. Guard: only pending requests past expiry; tokens invalidated.
• generate_certificate: runs queue (jobs) when a request completes. Guard: once per request; hash of final document stored.
• retention_purge: runs cron weekly. Guard: skips legal holds, records every disposal, dry-run report first.
• verify_audit_chain: runs cron nightly. Guard: incremental recompute; a break is a sev-1.

• Read replicas: Portfolio analytics and obligation reports run on a read replica when primary CPU > 60% sustained.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

Every metered resource on Forge64 has a hard cap, so a traffic spike stops at your limit instead of becoming a surprise bill. This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

When should I worry about scale for a contract tracker?

Not before a measured trigger fires. For example, for "OCR for scanned documents": customers upload scanned archives.

What performance targets should a contract tracker aim for?

Contract repository search: p95 < 500 ms at 200k documents. Document assembly: p95 < 4 s asynchronous for a 40-page template. Signing page load: p95 < 300 ms; document preview < 2 s.

Does Forge64 cap my usage costs?

Yes. Every metered resource has a hard cap, and paid plans add an overage spend cap that you set.

• How to build a contract tracker
• Contract tracker architecture
• Example prompt for a contract tracker
• Contract tracker security checklist
• Often combined: approval workflow app
• Often combined: compliance portal
• All app types