The remaining tools are smaller, but each hides exactly one judgment call. Here they are, one page at a time. Mechanics for all of them: in-app Field Guide, section by section.
Flags, RFIs, and Notes - three shapes of "something needs saying"
A flag is a problem with a lifecycle - it stays open until someone resolves it, and it nags by existing. An RFI is a question with an official answer - it exists to get a response on the record from whoever owes it. A note is knowledge with no demand attached - it informs whoever finds it. The test is what "done" looks like: fixed → flag; answered → RFI; read → note. Cost of choosing wrong: problems filed as notes die quietly; questions filed as flags never capture who answered what; knowledge filed as RFIs demands answers nobody owes. Place all three on their elements (Part 1) - pre-filled automatically when you create from an element page.
Typed notes: if your company defines note types (site visit report, client call summary), a typed note carries structured fields worth querying later; an untyped note is a page. Same rule as log entries - structure only where the data pays rent.
Meetings - agendas that become minutes
A meeting here is a lifecycle, not a calendar invite: build the agenda in advance, send it (attendees get the PDF and a calendar file - external guests participate by email without accounts), run the session with roll call and per-topic notes and decisions, then issue the minutes - sealed, numbered, distributed. Amendments after issue are explicit revisions, never quiet edits - the same sealed-record ethic as logs. A series carries open and persistent topics forward with their numbering intact, so item 3.01 means meeting 3, topic 1, forever (recurring project rhythms deserve a series; everything else doesn't). Action items raised in a meeting are real tasks on real plates - see next.
Tasks - one plate, many sources
Tasks flow in from everywhere - created by hand, raised in meetings, spun out of rallies, generated by review requests - and land on one plate per person. The judgment: a manual task stands alone; an action item created inside a meeting or rally stays traceable to its origin. Prefer raising work inside its context so the container's record shows what it produced; reach for a manual task when the work has no container. An unplaced task means "whole project" by design - that is a meaning, not an omission.
Library vs Pocket - filing vs catching
The project library is deliberate filing: durable documents in a folder taxonomy, uploaded because someone will need them. Pocket is the catch-all in your pocket: photos and captures grabbed in the moment, sorted later. The crucial asymmetry: placing from Pocket is destructive and final - the capture moves to its destination (a flag, a spark, a sandbox, a rally post, a log entry) and unplaced captures expire. Pocket is a funnel, not storage. Cost of choosing wrong: treat Pocket as an archive and your photos evaporate; treat the library as a dumping ground and the signal drowns.
Submittals - the formal yes
When work needs a documented approval chain - samples, shop drawings, cut sheets - a submittal runs the review, records each reviewer's verdict, and distributes the outcome. It overlaps studio reviews (Part 2) on purpose; the difference is formality and audience: studio reviews pressure-test creative work in progress; submittals certify deliverables to stakeholders. If the result belongs in a contract file, it is a submittal.
Discussions, mentions, and #links
Every item carries its discussion, and the whole project has one. Two habits multiply their value: @mention the person you need (that is what pings them - writing their name does not), and #link the item you reference - the chip carries readers straight to the flag, rally, or schedule item you mean. #links never notify anyone; @mentions do. Threads support replies-on-replies rendered flat - jump chips carry you to the parent.
When the whole topic needs to hear it, @team notifies everyone on the item - its creator, its assignees, and its collaborators, the same people you see in the avatar stack on the detail page. It deliberately does not ping project or company admins who aren't otherwise involved, so it is safe to use without spamming leadership. The judgment: @team is for the moments the item's whole cast must act or know - a decision made, a direction changed, a deadline moved. Used as a louder @mention it trains everyone to ignore it, and an ignored @team is worse than none.
Notifications and watching
You are notified for what you are part of - assignments, mentions, replies, reviews, meetings - and you can watch anything to opt into its life. The discipline is pruning: watch what you would act on, unwatch what you were merely curious about, and tune per-channel (push vs. bell vs. daily digest) in your profile settings rather than learning to ignore the bell. An ignored bell is no bell.
Programs and statuses - the portfolio lenses
Projects can belong to programs (a season, a client, a campus - many-to-many, so one project can sit in several) and carry a company-defined status whose names and colors are your company's vocabulary. Neither changes anything inside a project - they are lenses for reading across projects. Use programs for belonging, statuses for state.
Company Sparks
⚑ Company users only. Project-invited collaborators do not see the company Sparks pool - their window starts at project sparks inside sandboxes they can access.
The porch from Part 2, company-wide: ideas with owners, waiting for their project. The rhythm that keeps it alive (convert, keep, or archive - on a schedule) is described there.
Company contacts
⚑ Company users only - and visible only to members whose contacts permission allows it.
The company rolodex: people and businesses, faces and logos, tags, attachments, and an activity log of dated interactions. Project contact lists draw from it; a contact who becomes a real user links to their profile automatically. Log interactions when they happen - a rolodex without history is a phone book.
Your profile, your phone, your theme
Push preferences, digest timing, avatar, pronouns, timezone - and appearance: the web app ships a light mode built for readers who live in documents (Settings → appearance). The mobile app is a first-class citizen for the field half of the platform - capture, logs, completing schedule items, reading everything - while heavy construction (schedule logic, markup, issuing) stays on the web.
⚙ Make it yours - nearly everything in this part is shaped by company settings: note types, flag types, submittal setup, contact categories, program and status vocabularies, and the per-project permission grids that decide who sees which tabs at all. The Company Admin edition walks each knob.
The admin's half
Every "⚙ Make it yours" note in this part resolves to a company-settings page you own: template families (note types, flag types, spark categories, asset types), programs, project statuses, contact categories, and the permission templates that stamp new members' grids. The pattern across all of them is the same one this manual keeps repeating: short vocabularies chosen so fast nobody mis-files, templates that carry the sketch rather than the answer, and defaults that make the right habit the lazy habit. The dedicated chapters that follow walk each settings surface in setup order.