Governing documents (org-side)

The Documents module is the home for governing documents: constitutions, bylaws, standing rules, policy memos, and other reference material a chapter or organization needs to keep at hand. Org admins author and upload from the org Documents page; chapter officers can edit chapter-scoped documents from the chapter Documents page.

This page describes what org admins can do here — the five document types, the three visibility tiers, version history, search, and the limits of the current implementation.

Who can use this

Document creation is restricted to org admins and regional admins. Chapter officers can edit and delete chapter-scoped documents that already exist, but they cannot author new ones from the chapter Documents page. If a chapter needs a new policy document, an admin creates the record; the officer then can iterate on the content.

The org Documents page

From the org sidebar, open Documents. The page is split into two sections:

1. National Documents — documents created without a chapter assignment. These belong to the org as a whole.
2. Chapter Documents — documents scoped to a specific chapter, grouped by chapter. Every chapter that has at least one document gets a sub-section.

Filters at the top of the page narrow the table by document type and visibility tier. Both default to "All."

the org Documents page with the National and Chapter sections, type/visibility filters, and Create buttons

Document types

Every document is tagged with one of five types. The type drives the badge color and is the primary axis members use to find what they're looking for.

Type	Use for
Constitution	Founding document, governance structure, fundamental rules
Bylaws	Operational rules, officer responsibilities, meeting procedures
Standing Rules	Recurring rules of order, voting thresholds, committee charters
Policy	Specific policies — risk management, social events, alcohol, dress code
Other	Everything that doesn't fit the four above

Types are not enforced — Policy and Bylaws documents have identical fields and behavior. The label is for navigation and filtering only.

Visibility tiers

The most important admin decision per document is the visibility tier. There are three:

Tier	Who can read
Public	All members of the organization, regardless of chapter or role
Chapter	Members of the specific chapter the document is scoped to
Officers	Chapter officers and chapter presidents of the scoped chapter, plus org admins

Visibility is enforced on every read. A member browsing the chapter Documents page sees only documents whose visibility includes them — public documents from the org, chapter-tier documents for their chapter, and officer-tier documents if they have an officer or president role in that chapter.

Org admins and regional admins always see everything in scope (org-wide for org admins; their region's chapters for regional admins).

When chapter is required

If you set a document to Chapter visibility, you must pick a chapter. The platform refuses to save without one — the visibility tier wouldn't have anything to scope to.

Public documents can be org-wide or chapter-scoped. A chapter-scoped public document is still visible to all org members (visibility is the dominant control) but is filed under the chapter.

Officers visibility ties the document to a specific chapter — only officers of that chapter can see it. Use for internal financial memos, incident reports, or anything not yet ready for general membership.

Uploading and content

There are two ways to put content into a document:

1. Inline content. Type the body directly into the content textarea on the create form. This is the easy path for short policies, standing rules, and anything that's primarily prose.
2. File attachment. Upload a PDF, DOCX, or similar file. The platform stores the file and tracks its filename, size, and MIME type. Members open the file from the document detail dialog.

The two are not mutually exclusive — a document can have both inline content (a summary or table of contents) and an attached file (the full document).

A real limitation around file downloads

The document detail dialog renders the inline content body verbatim. It currently does NOT surface a download button or link for the attached file. Members who view a document with a file attachment can read the inline content but cannot retrieve the file from the UI today.

The download endpoint exists on the backend (a proxied, authenticated file download), but no frontend control wires up to it. The practical workaround is to paste the file's text content into the inline content field, or include an external storage URL in the content. Wiring a Download button into the read dialog is on the team's backlog. If you uploaded a file expecting members to download it and the download isn't surfacing, this is why.

Search

The documents page has filters (type, visibility, chapter) but no dedicated search bar.

There IS a backend keyword search exposed via the AI Services chatbot. When asked a document-related question ("what do our bylaws say about quorum?"), the chatbot:

• Matches on the title and the inline content field — case-insensitive substring matching, not full-text with stemming.
• Falls back to semantic similarity if AI embeddings are configured (see AI Services content scope).

The takeaway: if you want a document discoverable by the chatbot's body content, paste the key text into the inline content field. PDFs and DOCX files attached to documents are NOT indexed for content — only their titles.

Version history

Every document has a versions collection. When the inline content changes via the edit dialog, a snapshot of the previous content is recorded with a version number, the user who made the change, and an optional change summary.

The current document state is always the "latest" — when you open a document, you see the most recent version inline. Earlier versions are visible via the Versions button on the detail dialog.

A few facts to know:

• Versions are content-only. History captures the inline content body, not the attached file, title, or metadata. Title changes do not create new versions; file replacements do not either.
• There's no rollback button. Versions are a record, not a checkpoint system. To revert, copy the older version's body and paste it back on a fresh edit.
• Version numbers monotonically increase. Version 1, 2, 3, and so on — never reused.

Flat model — no folders

The Documents module is intentionally flat. Documents are organized by:

• Visibility tier (public / chapter / officers)
• Document type (constitution / bylaws / standing rules / policy / other)
• Chapter scope (org-wide or assigned to a specific chapter)

There is no folder hierarchy. You cannot create "Policies → Risk Management → Social Events" as a path; everything is filed at the top level and filtered via type, chapter, and visibility.

For organizations with hundreds of documents, this becomes a navigation challenge. The common workaround is to encode a path in the document title ("Risk Mgmt - Social Events Policy") and rely on the filters and type badges for discovery. If you find yourself wanting folders, you're hitting a known limit of the current design.

The requires_approval and is_current flags

Two boolean fields on every document — Requires approval and Is current — are reserved for future features. Neither is currently wired into a workflow. The document is immediately visible to whoever the visibility tier permits, approval flag or not, and the is-current toggle has no UI control. Ignore both for now.

Deleting

Org admins delete documents via the trash icon on the document row. Deletion is permanent — no recycle bin, and version history is removed alongside the document. The attached file is also removed from storage. Any link to the document from a forum post, bulletin, or chatbot conversation will dead-end.

The safer alternative for outdated content is to edit the document — replace the body with a note that it's been superseded, optionally linking to the replacement. This preserves the history and the URL.

Notification on document publish

Members are not notified when a document is created or edited. The Documents module does not push notifications today. If you publish an important policy update, send a bulletin or in-app announcement to direct members to it.

Related

• AI Services content scope — when documents are indexed for chatbot search
• Module enablement — the Documents module is core and always available
• Chapter documents (officers) — the officer-side perspective on editing chapter-scoped docs
• Permissions matrix

Last verified against v0.62.1 (2026-05-11).