Configure a phantom, preview the plan, then apply it
One file holds the site's own settings and its editorial settings. Read it, patch it, and re-run the configuration job with a dry run first.
A phantom has two halves, and one pair of tools covers both. get_phantom_config reads them joined; set_phantom_config patches either, or both, in one call.
| Half | What is in it |
|---|---|
The site (config) | Name (the masthead), tagline, theme, your own customer reference, the collection it renders |
The collection (collection) | Everything about what it publishes: content settings, cadence, publishing, ranking targets, measurement |
The editorial half is the same one-file document every collection has, hosted or not (KB-202), which is why a phantom and a client blog are configured the same way.
Read it
"Show me the Ledger Room's configuration." → get_phantom_config { phantom_id }
CLI: letterstory phantom config <phantom-id>.
You get the site's identity and theme, the collection's whole file, and the status of the latest configuration job.
Patch it
Send only what you mean to change. Everything you leave out is kept.
"Post four times a week and turn shred on."
{
"phantom_id": "…",
"collection": {
"cadence": { "posts_per_week": 4 },
"content": { "shred": true }
}
}
"Rename the masthead and switch the theme."
{ "phantom_id": "…", "config": { "name": "The Ledger Room", "theme": "ledger" } }
The six sections of the editorial file:
| Section | Holds |
|---|---|
identity | Whether the publication carries your brand, and how it publishes. On a phantom this is fixed: independent, hosted here. |
content | Research depth, writing kernel, verify / shred / visuals, cover style, brand mention, template |
cadence | On or off, posts per week, timezone, how topics are sourced, approval posture, the steering direction |
publishing | Publish locally, push to a CMS, rebuild the site |
targets | Whether your organization's ranking targets are pressed on this publication, and at what tier |
measurement | Whether AI-answer probing runs for it |
content.mention_degree has to stay off on a phantom: an independent publication does not name the client, and the platform refuses a value that would break that.
Re-run the configuration job
A site created by hand is bare: no strategy, no topic map, no guaranteed passes, no writing voice. configure: true runs the job that brings it to the same spec the one-call onboarding produces: strategy, visuals, the guaranteed passes off the site's own sitemap, the writing kernel, cadence, and the topic map.
Preview it first. dry_run: true returns the plan that job would apply and persists nothing:
"Show me the configuration plan for the Ledger Room, don't apply it." → set_phantom_config { phantom_id, configure: true, dry_run: true }
The plan lists each stage with a decided value, a source, and a one-line why:
| Source | Meaning |
|---|---|
assembly | Chosen for this site by reading its strategy and subject |
caller | You pinned it (a value you patched) |
fallback | AI wasn't available; a standing default was used |
Then apply it with dry_run dropped. The job runs stage by stage (strategy → visuals → enhance → kernel → planner → map → done), and get_phantom_config reports its status as it goes:
- review: items a person should check, an inferred strategy, a drafted topic map.
- applied: the configuration read back from what was actually written (effective cadence, cover canvas, kernel, pillar and spoke counts). Verify from this, not from the plan.
A stage that can't complete records a plain-English note instead of failing the whole job, such as "No kernel matched, pick one by hand", so you finish with a working site and a short list.
Strategy still won't overwrite what your organization already has; the collection's sitemap is replaced only if it points at the wrong site.