Features
Governing documents
The association’s CC&Rs, bylaws, guidelines, minutes and policies: how versions are published and superseded, what residents see, and which parts refuse today.
2 sections of this article carry operator-only instructions. They are published so the whole picture is visible, and nobody outside Vara can act on them. They are marked where they appear: The knowledge base and the reindex button, How long documents are kept.
The management console shows every record: drafts, published versions and superseded versions. The resident portal shows only what is current and published. There is no filter a resident can lift and no URL they can guess: the portal page has no way to ask for a draft.
Read the rest of this article knowing that both libraries are empty and cannot yet be filled. The rules below are real and they are what will happen when storage is configured. Today they have nothing to act on.
Uploading and downloading governing documents
Shipped, not configured- What people expect
- A manager uploads the CC&Rs; a resident opens them from the portal.
- Why it does not work today
- Object storage is now wired: the service holds a real client, an upload writes the bytes and then claims the record, and a reader is handed a short-lived signed URL. What decides whether any of that works is the DEPLOYMENT. Each one must name its two buckets (PROPMGMT_DOCUMENT_BUCKET and PROPMGMT_ATTACHMENT_BUCKET), and it must name BOTH: the service wires all of its storage or none of it, because one set would mean documents worked and ticket attachments answered 503, which reads as a bug in attachments rather than as a deployment configured halfway. Where they are unset, every upload is still refused before anything is stored, and the console library, the resident library, publish, supersede and download are all operating on an empty collection.
- What to do instead
- On a deployment with its buckets set, nothing: upload the CC&Rs and publish them. Where they are not set, distribute governing documents the way the association distributes them today, and say so in the announcement rather than letting residents hunt through an empty page. The refusal names the reason.
Checked against the code on 2026-09-09. Next review 2026-10-15.
A resident who lands on the console library is redirected
Rather than being refused, they are sent to their own copy of the library. There was somewhere better to send them, so they get sent there.
Each record carries a title, a type, an effective date and a version. The types are fixed: CC&Rs, bylaws, ARC guidelines, a fee schedule, a policy, minutes, or other. Files are PDFs.
An upload lands published by default. An operator or a manager uploading a document is the review, so there is nothing for a draft state to mean.
A board member’s upload lands as a draft only if the association has turned on the setting that says board uploads need review. That setting is off unless somebody turns it on, so by default a board member’s upload is published immediately, exactly like anyone else’s. If that is not what your association wants, it is a setting to change, not a behaviour to assume.
| What | Who can | Route |
|---|---|---|
| See every record, drafts included | OperatorManagerBoardResident | GET /manage/settings/documents |
| Upload a document Depends on the deployment naming its document bucket: see below. | OperatorManagerBoard | POST /manage/settings/documents |
| Publish a draft | OperatorManagerBoard | POST /manage/settings/documents/{id}/publish |
| Mark a version superseded Wider than publish. A board member can supersede a document they cannot publish. | OperatorManagerBoard | POST /manage/settings/documents/{id}/supersede |
None of this can be exercised yet
Publish and supersede both work, and there is no document for them to work on, because no upload can create a record while storage is unconfigured. Treat this section as the rule that will apply rather than as something to try today.
Publish and supersede do not admit the same roles
Publishing is operator and manager. Superseding is operator, manager and board. That asymmetry is in the service as deployed. It is recorded here rather than smoothed over, because a reader who assumed the board was refused on both would be wrong in the direction that matters.
Marking a version superseded points it at the version that replaces it. The old version stops being offered to residents and is not deleted. The association’s record of what its rules were in 2023 is part of the record, and deleting it to tidy the list would remove the one thing somebody will eventually need.
Current, published versions only, with the title, type, effective date and version. Opening one produces a short-lived link to the file. Every open is recorded before the link is produced, so there is no way to read a document without the read being logged.
Today a resident opening this page sees an empty list, and would see a refusal if there were anything to open. That is the document storage entry at the top of this article, and it is one cause rather than two.
The knowledge base and the reindex button
Contains operator-only stepsThe documents page carries a "Reindex now" button. It is meant to rebuild a searchable index of the association’s documents, which is what a future assistant would answer from.
Rebuilding the knowledge base
Shipped, not configured- What people expect
- The 'Reindex now' button on the documents page rebuilds a searchable index of the association's governing documents.
- Why it does not work today
- The button is real and the route behind it is real, and pressing it today returns an error rather than starting anything. The service has no Cloud Run Jobs runner installed, so there is nothing for it to start. Half of what the job itself would need has since arrived: the object storage client that reads the stored files is now installed and wired, so a job could at last open a document. The other half has not: nothing produces the embeddings, so there is still no route to a built index. The button refuses on purpose. A button that answered 'started' and started nothing would be worse.
- What to do instead
- Expect the error and read it: it names the reason. Nothing is damaged by pressing it, and any index that already exists is untouched. The service's own error message ends "An operator can still run the job directly against Cloud Run", and that sentence is still wrong, though for one reason now rather than two: the job can read the documents, and cannot turn them into vectors.
Checked against the code on 2026-09-09. Next review 2026-12-01.
Operator only: reading the index state
The page and the health endpoint report the last index state this process observed, and "unobserved" is the ordinary answer on a freshly started instance rather than a sign that a build vanished. The service runs with no minimum instances, so the instance answering the health check need not be the one that rendered the page. To get a fresh answer, load the documents page.
How long documents are kept
Contains operator-only stepsGoverning documents are kept indefinitely. That is their retention class, and it is different from every other kind of document the platform is designed to accept: deed uploads are transient evidence, leases are kept for the tenancy plus a short tail, and bank statements are kept for seven years.
Operator only: running retention
Retention enforcement is an operator endpoint and it is a dry run unless you say otherwise. With no catalog registered it says so in as many words, because a report of zero deletions from a job that had nothing to walk is indistinguishable from zero deletions from a job that walked everything.
Still stuck?
That is a fair place to be, and it is usually faster to ask than to keep reading. Your association's management office can tell you whether what you are hitting is a permission, a setup step or a fault. Say what you were trying to do and what the screen said. If it needs changing at the service level, they will bring Vara in.