Records

A record in CompStack is evidence that a process ran. It's the filled-out leave request, the signed audit attendance sheet, the supplier evaluation result, the photo of the completed safety check. Records are the half of ISO compliance that auditors actually check at audit time.

CompStack treats records two ways, and you'll meet both:

  1. Uploaded records - drag a file (PDF, image, Excel, etc.) onto a process, tag it, add a title and date. Done. This is the 80% case.
  2. Structured records - fill in a configurable form like "leave request" or "system access request." The form is defined by an admin as a record type.

Both kinds live in the same /records list, both go through the same optional approval flow, and both are immutable evidence after submission.

The two paths

Path A - upload from a process (the wedge)

This is the path most people use most of the time.

  1. Open /processes and click into the process you ran.
  2. Click the Records tab.
  3. Click + Add record.
  4. Drop or pick one or more files. Type a title. Set the date the work happened. Add tags.
  5. Click Upload.

The record is created with status Approved immediately (no review queue - this is evidence of work that already happened, not a request for permission). It's now visible on the process's Records tab forever, on /records, and to anyone in your org with access to the process.

Limits today: 100 MB per file, allowed types are PDF, PNG, JPEG, WebP, Word, Excel, CSV, plain text, JSON.

Path B - file a structured record

For high-frequency forms (leave, access requests, supplier evaluations), an admin pre-defines a record type with a JSON schema. Users then file records against that type.

  1. Open /records and click + New record.
  2. Pick the record type (e.g. Leave Request).
  3. Fill the form. Save draft, or submit for approval.
  4. The record routes through whichever approval chain the type is bound to.

Use this when you want consistent fields across many records of the same kind. Admins manage these types at /records/types.

What's on the record detail page

Every record at /records/{id} shows:

Records are immutable after submission

Once a record is submitted (status leaves draft), the evidence fields lock: title, form data, record date, submitter, organization, type, files, links - none of those can change. The Postgres triggers reject any attempt.

What you can do post-submission:

If you need to "fix" a record, you don't edit it - you supersede or void it. This matches how ISO 9001 audit trails actually work.

Where records live

Records are visible to:

Cross-org isolation is enforced at the Postgres RLS layer - there's no path in the app that lets one org read another org's records.

Tags

Tags are free-form strings. They're normalized to lowercase + trimmed at insert. Common patterns auditors will use:

There's no autocomplete in the upload modal yet (deferred to v2.1) - type your own tag values, separated by commas or Enter.

Approval modes

Three modes, all stored explicitly so an auditor can tell them apart:

If your audit program requires every record to have human approval, use Path B (structured records bound to a chain) so approval_mode='chain' everywhere.

Test it

Known gaps

These are explicitly deferred. Track them in Known gaps and backlog:

← Back to CompStack