How to use it

Three steps to a build you are working towards.

1 Open the Ships tab. Your fleet is already there.

Open the Ships tab.

Your fleet is listed from the journal, the ship you are flying outlined and a ship you only mean to buy faded.

Ships Ptarmigan (Anaconda) Solati Sparrow (Krait Mk II) Jameson Memorial Python wanted Read out of the journal. The one you are flying is outlined; a ship you only mean to buy is faded.

2 Open one and change a module.

Open a ship and change a module.

The gauges, such as jump range, move as you change it, before you commit.

Ptarmigan Power plant 7A Guardian Hybrid FSD 6A — dirty drive grade 5 Jump range 62.4 ly The gauges move as you change things, so you see the cost before you commit.

3 Accept the plan, and it lands on your checklist.

Accept the plan, or say "what do I still need for the Ptarmigan".

The shortfall lands on your checklist and the Gap page, with one build per ship.

what do I still need for the Ptarmigan Ask The shortfall goes to the Gap page with everything else. One build per ship, kept per Commander.

! The one that stops people.

Read the modifications as D47's own working out.

They come from the modules themselves, because Elite does not write a loadout after engineering.

Elite never writes a loadout after engineering. D47 works your modifications out from the modules themselves, because the game does not tell it.
Why it works this way

Your fleet, the hulls you mean to buy, and one build per ship.

1 The build owns what. The checklist owns when.

THE BUILD what a ship should be one entry per slot you promote it and accept it THE CHECKLIST what you are doing next in the order you put it in Nothing crosses between them unasked. So a build can be rearranged without your checklist reordering itself underneath you.

2 Changing your mind about a slot is an edit.

HARDPOINT 3 long range pulse laser you change your mind HARDPOINT 3 overcharged multi cannon The same slot, edited it keeps everything it had been through Not a delete and an add which used to bury the history beside it A slot holds one plan, because a slot holds one module.

3 You can plan a ship you have not bought.

you buy one D47 notices CORSAIR intended, not bought yet CORSAIR yours now THE PLAN points at it “That Corsair is yours now, and the plan you had for one is pointed at it.” Only when exactly one intended build matches. Two planned and one bought is a question.

Buying the hull is the plan's first step rather than something you have to do before planning at all — which is also why a hull you own is a derived line and one you only intend is an authored one. That is the same rule the checklist draws, because it is the same rule.

The details

Your fleet, the hulls you intend to buy, and one build per ship.

Ask for it

“what have I planned” “plan grade 5 dirty drives on the thrusters” “plan an overcharged multi-cannon on the third hardpoint of my Corsair” “put that on my checklist”

The first and the last need no AI configured at all.

The plan owns what. The checklist owns when.

These are two different questions and Directive 47 keeps them apart:

  • A build is what a ship should be. It lives in data/ships.json, it has one entry per slot, and changing it disturbs nothing else.
  • Your checklist is what you are working on next, in the order you put it in.

Nothing crosses between them unasked. Planning a slot writes the build and stops. It reaches your checklist when you promote it — and even then it arrives as a proposal you accept, the same way every other suggestion does.

Double-clicking a slot row on a ship’s page opens the same prompt as Plan this slot (or Change the plan).

That separation is what lets you rearrange a build without your checklist reordering itself under you, and reorder your checklist without the build forgetting what you decided.

What is fitted, remembered

What is actually fitted is a third thing, in a third file. data/loadouts.json holds what each of your ships was last seen carrying, straight from the game — every ship you have sat in, not just the one you are in now. Intent is authored and a loadout is derived, so the two never borrow from each other.

It is a cache and nothing depends on it surviving. Delete it and Directive 47 rebuilds what it can from your journals; it exists so that a ship you last flew a year ago is still answerable today, which reading the newest journals alone could never manage. A ship you sell is dropped from it at the sale — and dropped again if the game ever hands its id to something new, because Elite reuses ship ids and an inherited module list would be worse than knowing nothing.

A sale you made while Directive 47 was closed still lands. The file records how far through your journals it has been read, so the next start picks up exactly where it left off — however long that is. Come back after a year away and the first start takes a few seconds longer while it reads the gap, and says so in the log.

Not look right? Rescan. Asset Mgmt › Ships’ own “Page settings” strip says how many ships are remembered and how stale the oldest of them is, and offers Rescan my journals: it reads every journal on disk again and rebuilds the lot from scratch. A ship nothing in your journals supports stops existing, and one that has been sitting there wrong is put back the way the game described it. It takes a few seconds — about three on a year of flying — and you can do it as often as you like.

Nothing else is touched. Your plans, your checklist and your settings are not read and not written, and a rescan that finds no journals at all changes nothing rather than emptying the file: a journal folder that has moved reads exactly like a fleet that has been sold, and only one of those should be believed.

Copying a ship out

An owned ship’s page has a Copy as SLEF press beside Promote. It puts the ship as it is fitted now on the clipboard, for pasting into an outfitting website’s import: the loadout live while you are aboard, the one last remembered otherwise. A hull you only intend has no press, since a plan can leave slots open and a site needs every slot filled. A ship whose modules d47 has not seen says so on the line under the heading and leaves the clipboard alone. Nothing is sent anywhere; the clipboard is local.

The text is a one-element SLEF array whose data has the shape of the journal’s Loadout event:

public static string Write(ShipLoadout loadout, string appVersion)

One build per ship

Comparing a combat fit against an exploration fit for the same hull is a planner feature this deliberately does not have. A slot holds one plan, because a slot holds one module.

A build is deleted with its ship. Sell the ship, or come back to find its id reporting a different hull — Elite gives a sold ship’s id to the next one you buy — and the build is deleted, with every line it put on your checklist. Nothing is said about it, and it cannot be undone. Notes you wrote yourself on that ship’s list are left where they are.

Changing your mind about a slot is an edit, not a delete and an add. Swapping a long-range pulse laser for an overcharged multi-cannon leaves you with the same third hardpoint on the same hull — with whatever history it had.

The fleet, and the fleet you intend

The Asset Mgmt tab opens on your fleet and answers where each ship is before you drill into anything.

A hull you do not own is not in the fleet. It is its own thing, with no ship id, because Elite’s id is what a ship list is keyed by and a Corsair nobody has bought has none. So acquiring the hull is the plan’s first step rather than a precondition sitting outside it:

Corsair, intended — not bought yet

Buying one adopts the plan rather than making you re-point it. When the journal reports a new hull of a type you had planned for, Directive 47 binds the plan to it and says so:

That Corsair is yours now, and the plan you had for one is pointed at it.

Only when exactly one intended build matches the hull. Two Corsairs planned and one bought is a question rather than a guess.

The pictures

Every card carries a drawing of the hull, and it is a render of Elite’s own geometry rather than artwork somebody drew: the shipyard preview, captured, posed in the game’s camera and drawn as orange lines over a dark hull.

The small one came with Directive 47. All forty-seven fit in eleven megabytes, so a fresh installation has a fleet with pictures on it before anything is downloaded.

The large ones did not, and there are three of them per hull. A ship’s own page shows the same drawing at 3840 by 2160 — rendered again at that size rather than blown up, so the lines are the weight they always were — and opening a ship plays its turntable once through on the card you came from. The third is the hull’s 3D mesh, for the hull viewer. Together those are about 850 MB for the fleet, which is not something to hand a Commander who flies a Sidewinder. So the first time you open a ship, Directive 47 fetches the three files for that hull, from the same GitHub release it updates itself from, and keeps them in data/ships. Each hull is asked for once.

The hull symbol is all that is sent. Not your Commander name, not which ships you own, not where you are, nothing from your journal.

One switch, and turning it off puts every picture away. Asset Mgmt › Ships’ own settings strip has Hull pictures; off, fleet cards are text only, a ship’s own page shows no picture and plays no turntable, and nothing is fetched — even for a hull whose files are already in data/ships. The files themselves stay on disk; the setting only stops them being shown. Offline behaves the same way without the setting: nothing new arrives, and the log says why.

Three sizes, above the picture. Half the pane with the ship’s own figures beside it, which is where it opens; the width of the pane, with the figures under it; and the whole window. The size you last chose is the size the next ship opens at.

The whole window is a picture you can get into. The wheel zooms where you are pointing, dragging moves it, a double click fits it again, and Escape puts it back. It stops at one image pixel to one screen pixel — on a 4K monitor that is the whole ship, and on a 1080p monitor the canopy fills the screen. Clicking the picture does the same thing.

A hull with no picture is an ordinary thing. The card is the card it always was and the page reads exactly as it did before — the figures on their own, no marks and no gap. This is a picture, not a viewer: one pose, no orbit, no lighting and no model — anything you can do to a photograph and nothing you could only do to a mesh.

The ship you are flying wears a badge. It used to be an outlined card, which is what every list everywhere uses for the row you have selected — so the fleet opened looking as though Directive 47 had already picked a ship for you. CURRENT SHIP on the drawing says the one thing it means.

The hull viewer on the graphics card

A hull with a mesh is drawn by the processor unless Hull viewer on the graphics card is on, in Asset Mgmt › Ships’ own settings strip. On, the viewer and its whole-window size are drawn through OpenGL, multisampled, so a large window turns smoothly. It is off unless you turn it on.

Best with Elite not running, since the two share the graphics card. The window already draws through the graphics card, so this adds work to it rather than starting it. The viewer draws only while it is being moved; a still viewer costs nothing. The case where the sharing matters is a whole-window viewer left open while you play.

With no graphics card path, the processor draws. Where the window has no GPU interop — software rendering, or a driver that cannot set the viewer up or loses it — the viewer is drawn by the processor at the same pose, and the log says why, once a session.

Owned is derived. Intended is authored.

The same rule your checklist already draws between a line the journal settles and a line a person does — so it looks like the same rule, because it is one.

Dropping a build keeps what it already produced

Delete a plan and whatever it already put on your checklist stays there. You ordered your list around those lines, and silently removing them makes the history wrong.

Importing a build from the clipboard

Copy a SLEF loadout from an outfitting site, open the build’s page and press Import from clipboard. The press is on the page of an owned ship and of an intended hull, and it is a panel action only: the model has no tool for it and nothing is said aloud. The loadout must be for the same hull as the build. Where the build already plans slots, d47 asks first, saying how many slots it plans now, how many the import plans and how many could not be read. Replace it replaces the plan; Keep this plan changes nothing.

if (mode.ImportLabel(item) is { Length: > 0 } importLabel)
{
    actions.Children.Add(LoadoutPages.Press(importLabel, ImportFromClipboard));
}

Talking through a build

A ship’s own page opens with Talk through this build. It is answered by the catalog’s high model for your provider (Claude Opus 5.5 or GPT-6 Astra) at High effort, or by your conversation model when you use a custom endpoint. Type a remark into the field, or say it:

  • a question about one slot, such as “why that thruster”;
  • a critique, such as “is this build any good”;
  • a goal, such as “make it jump further”.

A question or a critique gets an answer. A goal gets a proposal: one row per slot that would change, each with the slot’s plan now, the plan proposed and a one-line reason, and Accept and Reject beside it. Above the rows is what the proposal costs with every change accepted: the engineer ranks it is locked behind and each material, held against needed.

Nothing reaches the plan until you accept it. Accepting a row writes that slot’s plan, exactly as editing the slot yourself would, and the checklist and the gap follow. Rejecting writes nothing. Neither can be undone from the row; to change your mind, edit the slot or ask again. Accept all and Reject all decide every row still open.

If you edit a slot after the proposal was made, its row says Plan changed since and can only be rejected: the proposal was made against a plan that is no longer there, so ask again.

By voice, the remark is about the ship open on the Ships page, or the ship you are flying when no ship’s page is open. The reply names at most three modules; the full proposal is on the page.

The exchange is kept for each ship until you press Clear, and is forgotten when Directive 47 closes. Advice comes from your language model, so it needs one configured, and each remark costs one request, two where a proposed change is refused by the outfitting tables and sent back once.

The tool surface, for contributors

This capability advertises one tool, and the reason is cost as much as safety. Every tool a mode advertises is sent, and billed, on every turn in that mode, whether or not the model uses it.

So the routes that genuinely need a model to understand free English are plan_ship_build, which writes to the build, and talk_about_build, which proposes and writes nothing. Everything else below is Protected: reachable from the panel and from a phrase, and never from the model.

talk_about_build

Pass the Commander’s remark about a ship’s build to the build adviser: a question about a slot, a request for a critique, or a goal such as making it jump further. It answers for the ship open on the Ships page, else the one being flown, and proposes changes on that ship’s page without applying any.

{"type":"object","properties":{"remark":{"type":"string","description":"The Commander\u0027s words."}},"required":["remark"],"additionalProperties":false}

The reply is relayed as written, so the three-module limit holds. The proposal is held in BuildTalk, and only BuildTalk.Accept writes it, one slot at a time through ShipPlanService.Plan.

get_ship_plans

Every ship the Commander owns and every hull they intend to buy, with where each one is and how many slots its build has an opinion about.

{"type":"object","properties":{},"required":[],"additionalProperties":false}

Not get_fleet, which JournalCapability already has and which answers a different question: that one reports what the journal saw in the racks, and this one reports what the Commander means to do about it.

promote_ship_plan

Offer a ship’s build to the checklist. It is a proposal: the Commander accepts, and each planned slot becomes a line for its blueprint and grade, plus a second line when the slot names an experimental effect.

{"type":"object","properties":{"ship":{"type":"string","description":"Which ship, by name or hull. Omit for the one the Commander is flying."}},"required":[],"additionalProperties":false}

Promotion is one-to-many. A slot produces a blueprint line and, when it names an experimental effect, an experimental line. These are the only two kinds. Each carries its slot in its intent, which is what lets a later revision find them again. Promotion adds no engineer unlock or rank lines.

drop_ship_plan

Drop a ship’s build. The Commander’s own act: not offered to the model, and refused if it asks. What the plan already put on the checklist is kept.

{"type":"object","properties":{"ship":{"type":"string","description":"Which ship, by name or hull. Omit for the one the Commander is flying."}},"required":[],"additionalProperties":false}

The file

{
  "ships": [
    {
      "id": "ship-1",
      "hull": "python",
      "shipId": 12,
      "name": "Bad Idea",
      "slots": [
        {
          "slot": "MainEngines",
          "blueprint": "Dirty Drive Tuning",
          "grade": 5,
          "engineer": "Felicity Farseer",
          "experimental": "Drag Drives"
        }
      ]
    }
  ]
}

id is the build’s own identity and is independent of shipId from the moment it is created — that independence is what there is to rebind when the hull is bought. A build with no shipId is an intended one.

Hand-edited, it takes effect without a restart, and a line the file gets wrong is reported rather than silently dropped.