Managing Projects

Project quality drives answer quality. A clean project gives MARCUS a coherent retrieval scope. A mixed project creates mixed answers, surprising citations, and uncertainty about what the system is really allowed to use.

This guide is for anyone responsible for a shared corpus, not just for creating a project once.

Why Project Management Matters So Much

MARCUS answers questions from the documents you place together. That means project management is not just administrative housekeeping. It is part of the evidence pipeline.

When a project is managed well:

• retrieval is more focused
• citations are easier to interpret
• conflicts are easier to resolve
• team trust in the product increases

When a project is managed poorly:

• the system can still look impressive, but the answers become harder to trust
• low-value or outdated documents compete with the important ones
• users start compensating with increasingly elaborate prompts

Recommended Structure

Use separate projects when these differ materially:

• clinical topic
• service line
• institution or department
• audience, such as resident onboarding versus protocol execution
• policy layer, such as local procedure versus general background reference

Keep sources together only when clinicians actually need them together at retrieval time.

A Practical Governance Pattern

For many teams, this pattern works well:

1. Assign a clear project owner.
2. Start with a small, curated source set.
3. Add documents intentionally instead of continuously dumping files into the project.
4. Review project quality on a schedule.
5. Remove or replace outdated material promptly.

This does not require a large governance committee. It requires someone owning the question: "Should this document participate in answer generation for this corpus?"

Version Control In Plain Language

You do not need software-style version control to manage a project well. You do need version discipline.

Practical rules:

• Prefer the current approved version of a document.
• Do not keep multiple drafts in active retrieval unless there is a deliberate reason.
• If a document is superseded, replace it rather than allowing both versions to compete silently.
• If older material still matters historically, isolate it or label it clearly in your own workflow.

Conflicting versions are one of the fastest ways to make a project feel untrustworthy.

Project Maintenance Checklist

Run this checklist whenever a project starts behaving strangely or on a recurring schedule:

1. Remove outdated or superseded files.
2. Keep document titles clear and human-readable.
3. Review authority labels for obviously misplaced sources.
4. Re-upload corrected protocols rather than leaving conflicting drafts in place.
5. Use briefings to spot sources that are missing summary or concept enrichment.
6. Ask a few core questions and confirm the expected sources are still cited.

When To Split A Project

Split a project when:

• search results keep mixing policies and clinical guidance
• the same question can refer to two different workflows
• a single chat thread is serving two unrelated audiences
• one service line's documents keep overshadowing another's
• users have to keep adding clarifying prefixes just to aim the system toward the right content

If the real answer to "what belongs here?" starts sounding like a paragraph, you probably need more than one project.

When To Keep A Project Unified

Keep sources together when clinicians actually need them together at retrieval time. Examples:

• a protocol plus its local escalation policy
• a pathway plus a service-specific discharge note
• a handbook page plus an operational escalation appendix used in the same workflow

The key test is not whether the documents are related in a broad sense. The test is whether a realistic question should retrieve them together.

Access Control And Sharing

Project membership is the right layer for sharing a source set with a smaller team inside a larger organization. Use organization-level membership for broad access and project-level membership for focused access.

Think through access in operational terms:

• Who should be allowed to ask questions against this corpus?
• Who should be allowed to add or remove documents?
• Who is responsible for keeping the project current?

Those roles do not always have to be the same.

Soft Signals That A Project Is Drifting

Project drift usually appears gradually. Watch for:

• repeated low-coverage answers for common questions
• contradictory citations from old and new versions of the same protocol
• difficulty explaining to a new user what belongs in the project
• briefings that show very different document types without a clear reason
• users saying the project feels "messy" even if they cannot name one specific bug

These are usually governance problems before they are product problems.

A Good Quarterly Review Pattern

For stable shared projects, a periodic review can be simple:

1. Review the source list.
2. Remove obsolete versions.
3. Confirm the highest-value documents are still present.
4. Skim several briefings.
5. Ask the top three recurring user questions.
6. Note whether answer quality, citation quality, and coverage still feel appropriate.

This gives you a lightweight way to preserve quality without turning the project into a major administrative burden.

One Working Rule

If a document makes the answer set more confusing than helpful for the main project use case, it probably does not belong in that project, even if the document is valuable somewhere else.