Project Knowledge

Project Knowledge is the project’s brief: everything the workspace knows about the client, compiled into a structured, versioned document where every claim carries a citation back to the source it came from. The Blueprint is derived from it, generation is grounded in it, and Jetty treats it as the authority on the client.

Why Citations, Not Summaries

An AI-written summary is only as trustworthy as its sources — and a summary without citations gives you no way to tell which client statement a design decision rests on. Project Knowledge is therefore built from claims, not prose:

Each claim is a single factual statement (“Acme’s SDR team qualifies leads within 24 hours”).
Each claim carries evidence: a bounded excerpt from the actual source — a document passage, a chat message, an audit finding, or a portal observation.
Published knowledge versions are immutable. Updating the brief publishes a new version; history is never rewritten.

If a statement has no source, it does not become knowledge. Jetty is explicitly instructed not to treat unattributed context as fact.

What the Brief Covers

Claims are organised into a fixed set of categories:

Category	What lands here
Company	The business itself — model, market, motion
People	The client team and stakeholders (see the roster below)
Processes	How work actually flows today
Requirements	What the engagement must deliver
Current systems	The portal and the tools around it
Open decisions	Questions that need a human answer before design can proceed
Conflicts	Places where two sources disagree

Where Knowledge Comes From

Four source types feed the brief:

Documents — files in the project’s Documents library are analyzed and their content becomes citable. Upload new files via the chat paperclip, or reference an already-analyzed document without re-uploading it.
Chat — you can publish knowledge straight from the conversation. When you state something worth keeping (“their fiscal year starts in February”), Jetty can capture it as a cited claim whose evidence is your own message — the system verifies the source message itself, so chat-captured knowledge is as attributable as document-sourced knowledge.
Audits — findings from portal audits contribute observations about the current setup.
The portal — the scanned portal itself is a source for claims about current systems.

The People Roster

The People category is more than a list of names. Contacts discovered across documents, chat, and the portal are resolved into a roster with explicit buckets:

Active client team
External stakeholders
On leave or former
Needs review — identities the system could not confidently resolve

Ambiguous identities (is “J. Smith” the same person as “Jane Smith”?) go to an identity review queue for a human decision rather than being merged on a guess.

Reviewing Conflicts and Open Questions

When sources disagree — a transcript says the sales cycle is 30 days, a process doc says 90 — the workspace does not pick a winner silently. The conflict lands in the Knowledge review workspace:

Each conflict shows the competing claims side by side, with their evidence.
You resolve it by choosing a value, supplying your own, or removing the disputed claims.
Let AI Choose is available for one-click resolution — it only ever selects from the candidate answers already on the table, never invents a new one.

Open decisions work the same way: questions the design genuinely depends on are queued for you, and the answer is published as cited knowledge.

Versions and Integrity

The brief is versioned: every publish creates a new immutable version, and the project always points at exactly one published version.
Downstream consumers — the Blueprint, Release planning, generation — only ever read a published, verified version. A brief that is mid-edit, or whose integrity is in doubt, is not silently substituted; the consumer tells you what is needed instead.

Next Steps

Solution Blueprint — The design document derived from the brief
Quickstart — Building your first brief