Skip to main content
The Dashboard answers for one project. All Projects answers for all of them at once, which are blocked, which have never been scanned, and which are missing the evidence you’re about to be asked for. Get there by opening the control at the top left and choosing All Projects, or by selecting it at the top of the sidebar. This is also where projects are created, renamed, and archived: the table on this page is the project list, carrying each project’s standing.

​
Getting Around: Two Levels

Earnie has exactly two levels, and the control at the top left always tells you which one you’re on:
  • All Projects — the whole organisation at once. Cards and a ranked table covering every project.
  • A project’s name — one project. This is where Review, Activity, SBOMs, Policies, and Scan Configuration live, because each of them is about one codebase.
Open that control to move between the two. Switching from one project to another keeps you on the same page, if you were reading Review, you land on the new project’s Review. The sidebar doesn’t change between the two: All Projects sits at the top, that project’s own pages sit below it, and Settings anchors the bottom, the same entries in the same order wherever you are, with only the highlight moving.
Opening Settings from inside a project leaves that project in place, so the sidebar is unchanged when you come back out. Settings is organisation administration, members, roles, API keys, the audit log, and it never belongs to one project.

​
Filter Is Not Location

The control beside the page title is a Filter Projects chip. It narrows what this page counts, cards, table, bulk actions, without moving you into a project. The control at the top left is your location, and it keeps saying All Projects while you’re here.
  • Every project — the default. The page counts everything you can see.
  • A selection — tick two or more projects. The menu stays open while you choose, and the chip reads In scope: 4 (or the one project’s name). Tick a project again to drop it, or choose Every Project to start over.
Named groups, a saved, shared set of projects with an owner, aren’t built yet. A selection is the same idea without the name: you can filter to two projects today, you just can’t save that choice for your colleagues.

​
Lenses, Not Tabs

This view has breadth rather than depth, so there’s no tab strip. One lens recomposes both the cards and the table’s metric columns. Every lens opens the same way, attention, then the list, so changing lens recomposes what’s below the table without moving the row you were reading. A lens for a scanner your organisation doesn’t have isn’t offered, and its cards are absent rather than empty. The trend card stays in Customize, it can’t draw a slope for an arbitrary scope, so there’s no organisation-wide trend line: Earnie has no history to recompute against a scope you assembled this morning, the same rule as Baseline Established on a single project, no fabricated history, ever.
If estate posture can’t load, the canvas shows Could not load project posture with a Retry action. A failed posture request is never presented as an empty estate.
The Overview cards are the cross-project version of the project ones: Needs Attention (organisation-wide conditions, one verb each), Gate State (projects by verdict), and Evidence Readiness (how much of the scope can be handed over, split into Ready, No Notice File, and No SBOM, each project counted once, since the two gaps need different work). Customize works exactly as it does on a project (see Making the Canvas Your Own), keyboard reordering included, and this layout is saved per person too.

​
The Project Table

One row per project, and it’s ranked, not alphabetical: projects with blocking verdicts first, then by how many conditions need attention, then by how stale the last scan is. The first screenful is therefore the work. What counts toward “needs attention”: exactly the conditions Needs Attention lists, a blocked verdict, a policy never applied, a scan that never ran or has gone stale, components with no licence assigned, or evidence (a notice file or an SBOM) that’s missing. A policy that only warns, a scan that covered part of the codebase, and weak cryptography all stay visible in their own cards, but none of them has a project-wide action to take, so none of them raises the count here. Each row carries the project and its repository, the gate badge (Block, Warn, Pass, or Not Evaluated), the lens’s metric columns, coverage, and how long ago it was scanned. Column headers sort, by click, or by focusing one and pressing Enter or Space. Above them, a search field and Any Gate / Any Coverage filters and a Show Archived toggle.
The same reading rules apply, column by column. A cell reading — means that measurement doesn’t exist for that project; not scanned means the domain never ran there; never scanned in the coverage column means the project has no completed scan at all. None of the three is a zero, and none can be added up with the projects that do have numbers. A project with — under Weak crypto hasn’t been shown to be free of weak cryptography; it hasn’t been looked at.

​
Acting on Many Projects at Once

There’s no bulk bar on the table, and no row ticking, ticking rows to “use as scope” was the same job Filter Projects already does, so it was never built as a second control. Instead, five of the seven Needs Attention verbs act directly on whatever the page is currently showing, every project in view, or the narrower set Filter Projects selected:
  • Apply a Policy, Request Scans, Generate Notice Files, and Generate SBOMs run the action against every project that row is counting, then report each project’s own outcome, never one pass/fail banner for the whole batch. Three succeeded and two failed is reported as exactly that, with each failure named.
  • Review Blocks and Assign Licenses still work the way every other verb here used to: a single matching project opens that project directly; several matching projects become the page filter instead, since resolving either one is still a per-project decision, not a batch action.
If some projects turn out not to be eligible, a scan request needs a connected repository, for instance, the card says so before anything runs (3 of 5 eligible) and reports the rest as skipped, rather than silently leaving them out or pretending the whole batch went through. Request Scans and Apply a Policy finish while you wait; Generate Notice Files and Generate SBOMs run in the background and the dialog updates itself as each project finishes.
Narrow the filters far enough and the empty message appears inside the table, under its headers, rather than replacing it, the columns stay where they were so you can see which filter to widen.