Contract tracker architecture
Contract tracker architecture: the decisions that matter
The architecture of a contract tracker comes down to 3 choices: matter membership as the access gate in RLS, approvals and signatures bind to a document version hash and built-in simple e-signature before a provider integration. Each is explained below with the alternatives that were rejected and what you accept by choosing it.
Last checked
Matter membership as the access gate in RLS
Situation: Legal confidentiality requires per-matter visibility, including from administrators.
Choice: Documents, search and audit queries join matter_members in RLS; admin role does not bypass confidential matters.
- Rejected: Role-only access: leaks across matters.
- Rejected: Application-level filters: easy to miss in one query.
- Consequence: Admin recovery needs an explicit break-glass add with audit.
- Consequence: All list queries must pass the membership predicate.
Approvals and signatures bind to a document version hash
Situation: Approving one draft and signing another is a classic failure.
Choice: Approvals reference a version id and signers record the sha256 of the exact bytes signed.
- Rejected: Approve the contract record: edits slip through.
- Rejected: Trust the file name: unverifiable.
- Consequence: Any edit resets approvals.
- Consequence: Certificate pages can prove document integrity.
Built-in simple e-signature before a provider integration
Situation: Third-party signing adds per-envelope cost and data egress.
Choice: Ship an in-product ceremony with strong evidence; add a provider adapter for higher assurance later.
- Rejected: Provider only: cost per signature.
- Rejected: No signing: users leave to finish.
- Consequence: Product must be explicit about assurance level.
- Consequence: Adapter interface kept for phase 2.
How the data is indexed
Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.
- clients: unique (org_id, reference) — client reference.
- matters: unique (org_id, reference) — matter reference.
- matter_members: unique (matter_id, user_id) — one membership per user.
- contracts: (org_id, status, expires_on) — renewal pipeline.
- document_versions: unique (contract_id, version) — version numbers.
- templates: unique (org_id, name, version) — template versions.
- clauses: (org_id, category) — clause picker.
- approvals: unique (version_id, step) — one decision slot per step.
What Forge64 provides underneath
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.
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.
FAQ
- What is the most important architecture decision for a contract tracker?
- Matter membership as the access gate in RLS. Documents, search and audit queries join matter_members in RLS; admin role does not bypass confidential matters.
- Do I have to make these decisions myself?
- No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.
- What do the alternatives cost me?
- For example, for "Approvals and signatures bind to a document version hash": Approve the contract record: edits slip through. Trust the file name: unverifiable.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free