How to use Corevia Delivery

Ten minutes of reading. Written for someone who joined this week.

On this page

What this app is for Your first ten minutes How work moves: five columns Writing a good item The three milestones What each screen is for The wiki Roles and permissions What comes from the NCP tool Shortcuts When something looks wrong

What this app is for

Corevia Delivery is where the team agrees what is being built, who is doing it, and whether it is really finished. Specifications, screen designs, test cases and builds live on the NCP tool; this app plans the work around them and records what happened.

One rule explains most of the design: a thing is done when someone other than its author can see that it is done. That is why items carry acceptance criteria, why reviews have a different person on them, and why a milestone needs a signature.

Your first ten minutes

Open My day. It is empty until work is assigned to you — that is normal on day one.
Open Projects and go into the project you were told to join. Read the Overview, then the Board.
Read one item end to end: title, description, acceptance criteria, comments, history. That is the shape of everything here.
Open Wiki and read the process handbook and the glossary.
If a screen is empty or a button is missing, it is almost always a permission. Ask your delivery manager to open Settings → Roles & permissions.

How work moves: five columns

Every project uses the same five columns. A column is where work really stands; a gate is the short list of conditions that lets it move on.

BacklogAgreed it is worth doing; nobody has started. An item without a description cannot leave this column.

ReadyDescribed, estimated, with acceptance criteria and an assignee. Anyone could pick it up and know when it is done.

In progressSomeone is working on it right now. One person, one item — if it is waiting on somebody else, mark it blocked and say why.

In reviewThe work exists and a second pair of eyes is checking it against the acceptance criteria. The reviewer is never the assignee.

DoneThe criteria are met and the exit gate is ticked. Done means a customer could use it, not that the code was written.

Bugs use the same five columns with their own labels — New, Triaged, In progress, Fixed·verify, Verified — and a resolution when they close.

Blocked is not a column. An item stays where it is, marked blocked, with the reason written down. That keeps the board honest about where the work really is.

Writing a good item

Title: what changes, from the user’s side. "Order list: filter by status and date", not "fix list".
Description: what, why, and what must be observable when it is done. Use the template in the editor toolbar.
Acceptance criteria: one line per check, written so that someone else can tick it.
Type: epic / feature / task / bug / sub-task / risk / tech debt / spike. Feature and epic are customer scope; the rest is how we get there.
Relates to: a requirement (it counts as coverage), a parent item (it is a sub-task), or nothing (internal work).
Labels: pick from the chips, or add a new one — it joins the catalogue so the next person can reuse it instead of inventing a synonym.
Attachments: screenshots, logs, recordings. You can paste a screenshot straight into the description with Ctrl+V.
Estimate: hours, honestly. It is capacity planning, not a promise.

The three milestones

M1 · Scope freezeWhat we are building is agreed and written down. After M1 a change is a change request, not a correction.

M2 · Ready for acceptanceThe build is testable and UAT opens. Test results and open severities decide whether this gate opens.

M3 · Acceptance & handoverThe customer accepts. The delivery manager signs first; the customer countersigns on their portal.

A milestone opens only when its conditions are met. A waiver is possible, it is recorded, and it names who granted it.

What each screen is for

My dayWhat is on you today: your items, reviews waiting for you, what you must unblock, meetings. Start here each morning.

ProjectsEvery workspace and project. Inside a project: Overview, Board, Sprints, Requirements, Tests, Milestones, Quality, Docs, Team, Triage and the Customer portal.

BoardThe five columns for one project. Drag a card to move it; the gate on the column decides whether it may move.

SprintsPlan the next sprint against real capacity, start it, close it with a snapshot. One sprint is active at a time.

RequirementsEvery SRS requirement from the NCP tool and what covers it here: items, design, test cases, results, open bugs. This is where "done" is measured.

TestsTest cases per requirement, who runs them, on which build, with evidence. Results feed the M2 gate.

MilestonesM1/M2/M3: the conditions, the signature of the delivery manager, the customer countersignature.

QualityBug lifecycle, DORA numbers, root causes, releases. Read it when you want to know whether we are getting better.

DocsThe project’s own wiki: charter, decisions, minutes, UAT log, lessons.

TeamWho owns which area, how loaded they are, the numbers behind the 1-1. Never a ranking.

TriageInternal work and bugs proposed below lead level wait here until a lead accepts, declines or marks them duplicate.

Customer portalWhat the customer sees: progress, what waits for their signature, UAT, shared documents.

PortfolioEvery project at once, risk first: completion, budget burn, timeline, team load.

PeopleStaff, load per sprint, performance per project, evaluations, 1-1 notes.

WikiCompany knowledge: handbook, glossary, onboarding, runbooks, decisions, retros.

ProcessThe columns, gates, rules and metrics themselves. Changing them is logged and versioned.

OKRWhat the company is trying to make true this quarter and the numbers that prove it.

SettingsRoles and permissions, users and agents, the NCP tool connection, notification rules.

The wiki

The wiki is the long-lived memory of the team: handbooks, decisions, runbooks, meeting notes, retrospectives, onboarding. If something was explained twice in chat, it belongs here.

Pages nest. Use "+ Child page" to put a page under the one you are reading; the navigator on the left shows the tree.
Start from a template in the editor toolbar — meeting notes, decision (ADR), runbook, how-to, retro, incident review, onboarding.
Every save keeps the previous text as a version. History shows who changed what and lets you restore any version.
Star the pages you return to; they sit at the top of your navigator.
Comment on a page instead of correcting it silently when you are not sure.
Mark a page Draft while it is half-written — the tree says so, and nobody quotes it as settled.
Labels work the same as on items, so "runbook" or "japan-side" finds everything at once.

Roles and permissions

A role is a set of capabilities, each at one of four levels. The level is what the screen checks before it shows you a button.

—Not your business. The screen or the action is hidden.

viewYou can read it.

editYou can change it.

manageYou can change how it works for everybody — process, roles, settings.

Roles are grouped: Leadership, Delivery, Japan bridge, Analysis & design, Engineering, Quality, Operations, Corporate and External. System roles keep a permission floor and cannot be deleted, so the project can never lock everyone out.

What comes from the NCP tool

Workspaces, projects, SRS requirements, screen designs, test suites and cases, apps, builds and test results are read from the NCP tool and mirrored here, refreshed every few minutes. Corevia Delivery never edits them — with one exception, pushing a new test case up to a suite.

So if a requirement or a test case looks wrong, fix it on the NCP tool; the correction arrives here by itself.

Shortcuts

⌘K / Ctrl+KSearch items, projects and wiki pages from anywhere.

CNew item, inside the project you are looking at.

EscClose the search palette or the side drawer.

Ctrl+VPaste a screenshot straight into a description, a comment or a wiki page.

When something looks wrong

A screen is empty or a button is missing → almost always a permission. Settings → Roles & permissions.
A requirement, test case or build looks stale → it is mirrored from the NCP tool; check there, and the sync pill in the project bar.
An item is in the wrong column → move it and say why in a comment. Every move is in the item history anyway.
You deleted something you needed → wiki pages keep every version; items keep their full history. Ask before anyone recreates by hand.
Something here is wrong or missing → write it on a wiki page and tell your delivery manager. This guide is a wiki page away from being out of date.