Project structure
A project in Lunar Paper is a container with opinions. It owns the management record: schedule, milestones, risks, issues, budget, stakeholders, and team. It borrows the execution detail from task boards. Understanding which half is which explains most of what the module does.
What a project owns
Section titled “What a project owns”These live on the project and exist nowhere else: the dates and milestones, the risk register and issue log, the expense ledger, the stakeholder register, change requests, lessons learned, baselines, and the team allocations.
Each has its own section in the left navigation, grouped as Overview, Execution, Management, and Insights.
What it borrows
Section titled “What it borrows”Tasks are not a project concept. They belong to Task Boards, and a board carries a link to one project.
Five things are computed from those linked boards rather than stored on the project:
- percentage complete,
- the task bars on the timeline,
- logged time and its budget comparison,
- earned value,
- workload per person.
This is why a project with no linked board looks empty however much work is happening. It also means the project’s progress figure is a consequence of how people use their board, not something a manager types in.
The lifecycle
Section titled “The lifecycle”Status moves through Draft, Planning, Active, On Hold, Completed, and Cancelled. Nothing enforces the order; it is a label you set, and it drives the filter on the project list.
Projects are archived rather than deleted. The settings screen says so plainly, and permanent delete is deliberately not offered, so audit history survives.
Health is a judgement, not a calculation
Section titled “Health is a judgement, not a calculation”Health is On Track, At Risk, or Critical, and a person sets it. No rule derives it from schedule slippage or budget burn.
That is a reasonable design — a project can be behind on paper and genuinely fine — but it has a consequence worth stating: the health filter on the project list is only as current as the last time somebody updated it. Treat a wall of green with the same suspicion you would treat a risk register where everything is medium.
One rough edge to expect: the project list shows health as a proper label, while the project header shows the stored code instead. A project set to At Risk reads “At_risk” in the header. It is the same value displayed two ways.
Sections are per project
Section titled “Sections are per project”Features in Project Settings decides which sections a project shows. Dashboard, Tasks, Timeline, and Settings are always present; everything else can be hidden.
Earned Value, Workload, and Dependencies start switched off on every new project, which is why a project that should have them looks like it does not support them.
Custom fields are per service
Section titled “Custom fields are per service”Custom fields are defined once for the whole service, per entity type: project, milestone, risk, issue, and document. They apply to every entity of that type across every project in that service. A field marked required blocks saving until it is filled, including on entities in projects that have nothing to do with why the field was added.
Where a project sits
Section titled “Where a project sits”Projects can belong to a program or a portfolio, both of which are held back behind feature flags and are not generally available. Without them, a project’s only parent is its service.
For the mechanics of each section, see the project views reference. For how the team half works, see Allocation and utilisation.