Create Your First Project
Set up a focused project so MARCUS retrieves from the right source set.
A project is the main container for documents, chat history, briefings, and retrieval scope in MARCUS. If the project scope is clean, answers tend to be easier to trust. If the project scope is mixed, the answer quality usually looks mixed too.
Think of a project as the answer to one practical question: "Which documents should MARCUS be allowed to consult together?" If the answer is unclear, the project probably needs to be split or renamed.
What A Project Includes
Each project is more than a folder name. It becomes the home for:
- The source inventory you upload
- The project chat that retrieves only from that source set
- Source briefings generated from individual documents
- Advanced knowledge views such as themes, matrices, or knowledge pages when enabled
- The history of how your team uses that corpus over time
For that reason, creating a project is one of the most important quality decisions you make in MARCUS.
When To Create A New Project
Create a new project when you are separating one of the following:
- A clinical service line, such as colorectal surgery, trauma, or wound care
- A workflow domain, such as discharge criteria, resident coverage, or triage escalation
- A different audience, such as clinician-facing protocols versus residency handbook material
- A source set with a different authority profile, such as local policy versus outside literature review
A Simple Scope Test
Before you create the project, ask yourself:
- If someone asked a question inside this project, would I be comfortable with every document in the project being considered as possible evidence?
- If MARCUS cited two arbitrary documents from this set together, would that combination still make sense?
- Would I name the answer to "what belongs here?" in one sentence?
If the answer to any of these is "not really," the scope is probably too broad.
Practical Examples
| Good project scope | Why it works | Scope that is usually too broad |
|---|---|---|
Postoperative Wound Care | All sources support one clinical workflow | General Surgery Docs |
Appendicitis Pathway | Questions will likely target one pathway and related decisions | Floor Protocols |
Resident Call Policies | Shared audience, shared policy context, shared decision types | Residency Stuff |
Discharge Criteria - Colorectal | One service, one operational decision family | Discharge + Postop + Clinic |
Step By Step
- Sign in and open the Projects area from the app rail.
- Select New Project.
- Enter a clear project name that describes the source set, not your mood while creating it.
- Add a short description that explains what belongs in the project and what does not.
- Choose the project kind if MARCUS asks for one.
- Select Create Project.
- Before uploading anything, pause for a moment and ask whether the title still makes sense if the project grows over time.
Naming Guidance
Good project names tell you what should be retrieved and what should be ignored.
| Better | Why it is better | Weaker |
|---|---|---|
Postoperative Wound Care | Names the clinical workflow directly | General Surgery Docs |
Appendicitis Pathway | Signals a specific decision framework | Service Stuff |
Resident Call Policies | Tells you the audience and content type | Policies |
Breast Service Discharge Criteria | Names the service and the operational task | Discharge |
As a rule, a good project name should answer both:
- What kind of question is this project meant to answer?
- What kind of document does not belong here?
What Happens After Creation
After the project is created, MARCUS gives you an empty workspace with:
- A project-level source list
- Upload actions such as Add Sources or Upload Files
- A project-scoped chat surface
- Empty states for briefings and knowledge tools that will populate after ingestion
An empty project is not a problem. It is a clean starting point. The problem is an unclear project that starts collecting unrelated material.
Access And Permissions
Project membership controls who can view and edit the source set. Depending on your organization's configuration, the people who can see a project may include:
- The person who created it
- A shared team or organization membership group
- Additional project members added later
Before loading a sensitive or operationally important corpus, confirm that the intended audience is correct. This matters because a project is not just a storage area. It becomes a shared decision-support surface.
A Safe First Project Strategy
If you are unsure how to scope the first project, start smaller than you think you need.
Good first-project pattern:
- Choose one workflow.
- Upload three to five trusted documents.
- Ask two or three realistic questions.
- Decide whether the answers feel internally coherent.
- Expand only after that test succeeds.
This is better than loading twenty documents and discovering later that half of them should have lived somewhere else.
Signs The Project Scope Is Drifting
Watch for these early warnings:
- Questions require constant clarification because the project covers too many unrelated situations.
- The retrieved citations feel surprising in a bad way.
- The briefings show very different document types that do not belong in one shared decision context.
- Team members start saying things like "ignore those other files" or "that answer is from the wrong kind of source."
- You keep adding topic-specific prefixes to questions just to force the system toward the right material.
When those signs appear, the fix is usually not to prompt harder. The fix is to clean the project structure.
What To Do If You Picked The Wrong Scope
You do not need to live with a poorly scoped project forever. A practical recovery approach is:
- Stop adding more files.
- Identify the dominant topics or audiences that got mixed together.
- Create one new project for each clean topic.
- Move forward with uploads and questions in the new projects.
- Keep the old project only as a temporary reference until the replacement is stable.
If you are deciding between "split now" and "clean up later," splitting now is usually cheaper.
Common Mistakes
- Putting unrelated operational policies and clinical evidence in the same project
- Using a vague title that makes later retrieval hard to interpret
- Creating one giant "everything" project for convenience
- Starting chat before any source reaches an indexed state
- Assuming better prompting will fix a poor project boundary
A Good Rule Of Thumb
If you would not hand the same packet of documents to a colleague and say "these all belong together for answering this kind of question," they probably should not live in the same MARCUS project either.