Projects

Projects are structured workspaces for complex multi-step engagements — due diligence, audits, strategic assessments, cross-department initiatives. Where situations are reactive and ideas are proactive, projects are deliberate: a bounded engagement with members, deliverables, and a defined scope.

Anatomy of a project

• Members. Who has access. Members can be internal, or you can grant external collaborators scoped access.
• Data room. File uploads that scope the project’s reasoning context — financial statements, contracts, org charts, due-diligence exhibits. Processed by the document intelligence pipeline.
• Deliverables. The output artefacts the project produces. Each deliverable is a wiki page with a committed manifest, produced by the reasoning engine with required reflection.
• Chat. A conversational interface scoped to the project. The AI has access to the data room, deliverables, and project wiki context.
• Connectors. Project-scoped connectors can be added — e.g. a client’s data-room SFTP or a target company’s Google Drive — without polluting the operator-wide wiki.
• Notifications. Activity on project events is broadcast to members.

Project templates

Project templates encode domain expertise for specific engagement types. A PE due-diligence template ships with a predefined deliverable tree (commercial DD, financial DD, operational DD), default investigation hypotheses, and canonical source expectations. A compliance-audit template ships with a different structure.

Templates are a concrete form of the practitioner-reference layer — captured expertise from how these engagements actually run, usable as the scaffolding for each new project of that type.

Required reflection for deliverables

Project deliverables are the high-stakes output where reflection tools earn their keep. At the end of each deliverable’s Produce stage, at least one verification-class call (citation check) and one skepticism-class call (strongest case against the committed deliverable) are required before commit. This is where projects differ from routine situations — the quality bar justifies the compute.

Nested projects

Projects can nest for multi-workstream engagements. A “Acme Acquisition” parent project might contain separate “Commercial DD,” “Financial DD,” and “Integration Planning” children, each with their own members, data room, and deliverables, inheriting from the parent’s context where appropriate.