Help desk

Four steps. On the desk, press + New piece, give it a headline, choose News or Blog, and press Create; it opens as a draft. Click the byline to pick the writer. Open the Corpus tab on the right, search the fact record, and press Cite on each fact you want the piece to stand on. Then open the Copilot tab, press Write from my sources, and Apply to the page. Edit, and publish when it is ready.
The desk →

Open Desk settings. On the Writing card set automatic writing to Daily and choose who approves: publish as written, or hold each piece for you; on the Coverage card pick the sections and how many stories each. Press Write news now for a batch straight away. Drafts land on the desk; the ones that clear the fact check publish, or wait for your approval.
Writing settings →

Paste your site's address in the one field on the landing page, or, signed in, open New paper (the card on Home, or + New desk in the desk menu) and choose From your website. The floor reads your site, shows the masthead it proposes with dropdowns for theme, type, language, mark and colour, and after you sign in it builds the desk, the writers and the first stories. A site that refuses automated readers still gets a paper drawn from its name and mark. An agent does the same over the API or MCP: create_desk with a website reads the site and sets the new paper's nameplate, mark, colours, type and language from it.
Build from my site →

The floor writes your first stories from the fact record, facts at least two newsrooms carry, files them as drafts you read first, and paints portraits if you ticked that. Nothing reaches readers until you go public. On your first day, read the drafts on The desk, open Settings to see what the paper covers, then switch it public under How it publishes.
The desk →

Three things. Read the first drafts on The desk and approve or edit them. Open Settings and check What it covers: the sections and subjects drafted from your site. Then go public under How it publishes, Reach. Everything else has a sensible default; charging readers, your own domain and a logo can all wait.
Settings →

Settings opens on six cards. What it covers, Where the facts come from, How it publishes, How it looks, Who can work on it, and Developers. Each opens into its own cards. The strict rules, how many newsrooms must carry a story and how long a lone story waits, have their own Strictness card under What it covers. The defaults are right for almost every paper.
Settings →

From the fact record, claims read from thousands of sources and kept only when at least two independent newsrooms carry them. Your paper draws the facts its subjects and sections claim. To add a source of your own, paste an RSS link or your own links under Where the facts come from.
The sources →

Yes. Under How it publishes, Language and units, switch Spanish on, pick the register (Colombian, Mexican and more) and set what the paper opens in. Every piece is rendered into Spanish beside the English record, and the subtitle is translated for the other view when you save. To use the console itself in Spanish, pick Spanish in the footer; the choice follows your account.
Language and units →

In rings, and you step inward. Home lists every paper you work on, with the numbers for all of them together. Open a paper and you are on its floor: that one paper's numbers and its rooms. The rooms are the desk (write, edit, publish, take off air), the masthead (your writers), Live, Readers, Members and files, Settings, and Credits and costs. Everything that configures the paper is inside Settings. The line under the header always says where you are, for example Home / your paper / Settings / Brand and images: click any part to go back up, or the small arrow beside a part to jump to its neighbours.
Home →

They moved inside the paper they belong to. The old tabs opened the desk or the settings of whichever paper you had used last, which was easy to get wrong with more than one paper. Now you pick the paper first on Home, and its desk and its settings are rooms on that paper's floor. What used to be called the floor, the page with all your papers, is Home. Old links and bookmarks still work and land on the new address. Help is in the menu under your name.
Home →

Yes, on an admin seat. Open a story in the preview and press Edit this article at the bottom left. Change the headline, standfirst or body, then press Review changes: the preview shows the new version and asks before it goes live. Readers keep seeing the current article until you press Publish this live, which files a new signed revision. Press Discard changes to drop the edit and go back to what is on air.
The preview →

Open Desk settings and open the Writing card. Under Who approves, pick Hold each piece for my approval. The newsroom keeps writing on its schedule, and every piece waits on your desk as a draft. Approve, edit or reject it from the desk home or the docket.
Writing settings →

Under Who approves on the Writing card, choose what happens when you do not get to a piece: wait for you, park it after a set number of hours, or publish it after a set number of hours. Publish-after only sends a piece that already cleared the fact check.
Writing settings →

Yes. Set automatic writing to Off. Press + New piece on the desk, write, place your sources in the Record tab, and press Publish. Or press Write news now and the newsroom drafts pieces for you to finish.
The desk →

A news piece must stand on sources you placed. If it is your own writing, an opinion or a company post, click the small chip next to the headline that says news and flip it to blog. A blog piece publishes without a source floor and carries the Opinion label.
The desk →

Open the piece. In the right pane pick Record to see the facts behind it, or Corpus to search the whole fact record. Search with the magnifier, press + Cite on a fact to place it, or tick the results you want and press Summarize in Copilot to get a short grounded briefing you can cite from. The Copilot can then write the piece from what you placed.
The desk →

Yes. Open the piece and press the clock next to Publish to schedule it. It goes live at that time with a signed receipt.
The desk →

Open it and press Off air. Readers see nothing; the story and every version are kept, and you can put it back on air any time. To record that a story was wrong, use Redact instead: it stays on the record with your reason.
The desk →

Open the piece and click the byline card to reassign it to any writer on the masthead. Add writers under The masthead.
The masthead →

The newsroom already shares the byline among the writers who fit a piece, so no one writer takes them all. To weight it, open The masthead, edit a writer, and set a byline share: a number where a higher value means more of the pieces they are eligible for, and 0 means never assign them automatically (you can still pick them by hand). Leave it blank for an equal share. Each writer's card shows how many pieces they put on air this week, so you can see the spread.
The masthead →

Yes. Under Settings, then Strictness, turn on Hold a lone-witness piece until a second source confirms it. From then on an engine-written piece that stands on one source (one publisher or one instrument reading) is not put on air: it waits in the approval queue, marked waiting for a second source. The newsroom keeps reading the record, and the moment a second independent source confirms the same story it publishes the waiting piece itself, with a signed receipt, and notes on the piece's history why it was held and what released it. You can approve it sooner from the queue, or archive or reject it; nothing is ever deleted. A piece with two sources publishes as before, and the switch only acts on a paper that allows labelled single-source publishes. Over the API and MCP the field is hold_for_corroboration on the paper's configuration.
Strictness →

Open Desk settings and open the Paywall card. Set a monthly price, an annual price, or both, and how many articles a reader gets free; leave one term blank to not offer it. Tick Turn the paywall on and save. Readers past the free count see a wall and pick the term at checkout, the same checkout your own plan uses.
Paywall settings →

You keep 90% of every payment, every billing cycle. It lands in your DRM3 wallet as credits by default, or you can connect your own bank to be paid in cash. DRM3 collects the reader's payment, is the seller of record, and pays your share to you. Choose credits or cash on the Payouts page.
Payouts →

An ad-free read if you offer it (a switch in your subscription settings, on by default; turn it off to keep your own ads in front of subscribers), the whole archive past the first seven days (to read and through the API), the full feed with the reader's own API key, and any files you post for subscribers. Today's paper stays free for everyone. The full guide is at newsroomfloor.com/subscriptions.
The subscriptions guide →

Yes. Add your own sponsors in Desk settings, The Space: a banner or a promo with a link, on your paper and in every briefing, and you keep every dollar. Subscribers read ad-free by default, a switch in your subscription settings. The DRM3 ad network, where DRM3 sells ads across papers and you keep 70 percent, is being built. The full guide is at newsroomfloor.com/ads.
The ads guide →

Yes. The free-article count on the Paywall card decides how many articles a reader opens before the wall. Set it to 0 to wall every article, or 3 to let them read three.
Paywall settings →

Writing spends your daily credits; the credit chip in the header shows the balance and links to every cost. A paid plan raises the daily allowance. You can also bring your own inference key on any plan.
The costs →

Every paper has one owner: the account that carries its plan and credits. Writing and the automation spend the owner's credits, whoever on the masthead starts the run. Readers pay for their own questions on the Signal Desk from their own credits, never yours. Admins you add can run the paper but do not pay for it. To move the plan and credits to another person, transfer the paper.
Admin →

You do. An admin runs the paper on your behalf, so every piece they write and every run the automation makes spends the owner's credits, never the admin's. The one thing an admin pays for is their own reading: a question they ask on a Signal Desk comes from their own credits. Adding a seat never moves the bill; only a transfer does.
Admin →

Open the Payouts page and choose Email the owner a setup link. We send the paper's owner a secure link; they open it from their own inbox, connect their bank and pass a one-time identity check on Stripe's own page, once. Only the owner can finish it, so nobody else can point the money at the wrong account. DRM3 never sees or stores the bank details and stays the seller of record on your readers' statements. Once Stripe clears the bank, the 90% share is paid there each cycle instead of in credits. The payout method is your account's, so it applies to every paper you own, and you can switch back to credits at any time.
Payouts →

On your paper's channel page, at /subscribe on its address. When the paywall is on, the page leads with the price, the free articles a reader gets first, your one line, and the Subscribe button. Set the price on the Paywall card in Desk settings.
Channel page →

On their own, online, with no login. Their receipt email carries a link to their subscription page: the price, the next charge and a Cancel button. The paywall, their RSS feed page and the Members page each carry a Manage or cancel link to the same page. A reader who lost the email enters the address they paid with at drm3.network/account/subscribe/newsroom-floor/manage and gets a new link by mail. Cancelling keeps their access through the period they paid for, stops every later charge, and can be taken back until that date. You do nothing, and your share of the payments already made is unchanged.
The reader's manage page →

Both follow your plan. Support tickets: the Free plan files none, Starter five a month, Publisher ten, Network thirty, and Managed unlimited. Every plan, Managed included, also has a safety limit of twenty tickets a day, so unlimited never becomes a runaway; the daily limit resets at midnight UTC. If you reach your monthly tickets we show you the next plan up, we never lock you out of reaching the team, and the tickets reset on the first of the month. Priority follows your plan too, so a higher plan's ticket is handled sooner; you do not set your own priority. The API, the MCP server and the agent cockpit, where you point your own bot or an AI harness at your paper to build, write and publish it, are on the Publisher plan and up; the Free and Starter plans run the paper from the console. Reading your own paper's data with a read key is open on every plan. See your plan and move up any time from the plans page.
See plans →

A promo is an advertisement: a title, a short line of copy, a picture, a button, and a link. The first promo with a link also rides the email briefing, labelled as an advertisement with your publisher name. The partners block is a row of partner or sponsor names and logos, each with a link, for crediting the organisations you work with. The links block is up to eight links to your own pages, such as About or Contact, each a label and an https address. The CTA link is the address the promo button opens. Upload your own picture, or leave it empty and a promo with a link borrows the linked page's share image. Subscribers read ad-free by default. The full guide is at newsroomfloor.com/ads.
The Space →

No flat fee. A push spends the paper owner's credits on two metered model calls: the safety screen and the distill that turns the material into checkable facts. Measured across the floor, a page costs about 1 credit (the screen about a third of a credit, never more than half; the distill about half a credit), and a long document read in full with depth full costs up to about 6. A push the screen refuses is billed for the screen alone; a page DRM3Bot cannot read is billed nothing. 1 credit is 1 cent. Every push answer carries the price and the credits the owner has left, so an agent can quote the cost before it acts; the credit chip in the header shows the same balance.
The costs →

Yes. An admin key reads GET /api/v1/papers/{paper}/credits, and the MCP tool get_credits returns the same: the balance (credits available, 1 credit = 1 cent), what this paper spent today and over 30 days, the daily allowance, the plan, and the own-key draw order. own-key-first means your own inference key is drawn BEFORE your DRM3 credits, for every billed call including the forge's safety screen and distill; credits spend only when your key is unavailable. Bringing your own key is a Network-tier capability. A push already returns the balance in its own answer, so a pipeline can pace from either.
The costs →

Open Desk settings and open the Writing card. Set automatic writing to Daily and choose how many pieces a day. Then choose who approves: publish as written, or hold each piece for you.
Writing settings →

Up to the number you set on the Writing card, within your daily credits. A story only prints when two independent outlets carry it, unless you allow labelled single-source pieces on the Strictness card.
Writing settings →

Open Desk settings, then the Coverage card. Subjects and themes are exact words. A fact that carries one is yours. Keep them to the one or two words the news prints. A sentence never matches. Tick a topic and the desk reads only facts tagged with it. The brief is matched by meaning, so say in it what the desk does not cover. Click any word on that page to test it against today's record.
Coverage →

The Voice card holds the standing instruction for every piece and the structure of a piece. It sets tone and angle; it can never add facts. Each section can carry its own angle too.
Voice settings →

The Voice card shows the model bench. Pick the one that writes here; your plan decides which are open to you. The fact check always runs on a strong model.
Voice settings →

The status chip in the title band says why in a sentence. Usually the beat found stories from one outlet only, and the newsroom waits for a second independent outlet. Widen the beat, or allow labelled single-source pieces on the Strictness card.
Today's facts →

Open Desk settings, then the Coverage card. Under Subjects, list your towns, agencies, teams and people. The desk takes them wherever they appear, even in a story that never names your region. Do not list your region or country as a subject. A place name claims every story that mentions it. Put the place in the brief. If one of your names is also somewhere else (San Juan is a county in Utah; Carolina and Florida are US states), add it under Places with a marker that only means your desk, such as Puerto Rico or boricua. The name then counts only beside a marker. Turn on Ask the desk to judge a borderline fact against this brief and an unclaimed fact gets a short yes or no against your brief instead of a score. Write the brief as you would brief a reporter. Say what the desk does not cover.
Coverage →

Yes. Open Desk settings, then the Coverage card, open the section and use Pause section. While it is paused the line writes nothing into that section and no piece publishes there, and the rest of the paper keeps running, so a touchy column is held while the news carries on. You can add an optional note on why, kept for tuning. Resume section brings it back and the line covers it again from the next run. Pieces already on air stay up; take one down on its own with Off air if you want it held too.
Coverage →

They group themselves. Your floor and the desk menu shelve your papers by who shares the admin seat: a section for each set of people you share admin with (You and Amanda), and Only you admin for the rest. You make a group by seating an admin on a paper's Admin card, not by building one, so a section can never drift from who actually admins. Who admins what, the full table behind those sections, is under Desk settings.
Who admins what →

Open Desk settings and open the Admin card, then Seats. Invite by email or @handle as an editor, an approver or an admin. The seat activates on their first DRM3 sign-in.
Seats →

Yes. Desk settings, Admin, Transfer ownership. They accept by email and take over the plan and billing. The name and address never change.
Admin →

Invite them as an Editor from Desk settings, under Admin, by their email or DRM3 handle. They create their DRM3 account with the invited address, or sign in if they have one, and the seat activates. Then add them on the Masthead tab as a writer with their name, their face and, if they have one, a verified credential. They write their columns by hand and you, the editor-in-chief, publish each one, so the automated newsroom never writes under their name. The step-by-step guide walks through it.
Add a human editor →

Open Desk settings and open the Reach card. Sign the publisher agreements once, then switch the paper public. It serves at your-id.newsroomfloor.com. Until then only your seats can see it.
Reach →

On the Publisher plan and above. Open Your own domain and type the address under Your own address; the page shows the one record to add at your registrar. A subdomain such as news.example.org is one CNAME record pointing at connect.newsroomfloor.com, set to DNS only. A whole domain such as example.org is one A record pointing at 168.220.82.194 (and, for IPv6, one AAAA record pointing at 2a09:8280:1::19b:e7ac:0). Add that one record and nothing else on your side changes: you keep your own DNS and your own email. The certificate is issued on its own within a few minutes of the record pointing at us, the page reads serving, and one email confirms it is live. Your newsroomfloor.com address keeps working throughout.
Your own domain →

Open Your own domain. Each domain you added shows its live state (waiting on your record, the record seen and the certificate on its way, serving, or stopped with the reason) and a Check now button; the floor re-reads every pending domain every five minutes on its own, so you never have to come back. Above that, every address shows what DNS says a moment ago and how many readers arrived on it today.
Your own domain →

Open Brand. Upload a logo, paint one from a description, or keep the seal. The masthead, share cards and emails use it.
Brand →

Open Brand, go to the Masthead banner card, pick a style (Scene, Art Deco, Vintage poster, Blueprint, Engraving or Minimal) and your core colours (your brand colours by default), then Generate. It paints your paper's own subject in that style, wordless, with your wordmark laid over it. Generate again for a new take, pick another style, or remove it. You can also edit it in place on the paper preview: the pencil over the banner opens the same picker.
Brand →

Open your paper and press the gear at the bottom right. Pick a theme, type size and face, and press Make these the live defaults. Layout and accent colour are under Desk settings, Appearance.
Your paper →

Under Reach, add a link, a label and one line. They ride the foot of every page of your paper.
Reach →

Yes. Under Language and units, switch Also publish in Spanish on and pick which Spanish. Then choose what the paper opens in: a Spanish paper opens in Spanish, and a reader's own pick or the language in the address wins over that. The subtitle you wrote under Identity is translated into the other language when you save, and you can reword either line; the nameplate stays one brand on both views unless you set one per language. Neither view ever shows the other language's line.
Desk settings →

Yes. The subscribe box on your front page collects addresses. On days you publish, subscribers get a digest in your paper's colours. Nothing to switch on.
Your paper →

Yes. Under Settings, then Strictness, Shortest engine piece sets a floor: off (the default), 300, 450, 600 or 800 characters. A piece the newsroom writes shorter than that gets one pass to expand from the facts it already stands on: the second source's own detail, the numbers, the when and the where. It never pads and never adds a fact. The longer version is kept only when it is still fully sourced; otherwise the original stands. A short piece is never held for being short, because a thin record still makes a true story. Over the API or MCP it is min_length on set_config, any whole number from 100 to 5000, or null to turn it off.
Strictness →

Each row in the approval queue has Archive and Reject. Reject asks for an optional reason, kept for tuning, then removes the draft from the queue and the lists so it can never publish on a lapse. Archive banks a piece that is true but not for today, such as a reservoir level you may run again. Tick several rows to reject or archive them together. Archived pieces wait under Archived pieces on the desk home; Restore puts one back on your working list, off the paper, to open and publish when it is ready. An agent does the same with reject_draft, archive_draft and restore_archived, or action reject, archive or restore on the stories actions door.
Open the queue →

Yes. Under Settings, then Sections, open the section or the column (a series column also on Editorial) and set Publishing: Paper default follows the paper's own setting, Auto publishes that section's pieces on its own, Approve holds them in the approval queue for a person. So an opinion column can wait for you on a paper that otherwise publishes itself, or one news section can run on its own on a paper that holds everything else. Saving the section's other fields never changes it. An agent sets the same thing with publish_policy on add_section or on a column in set_config.
Sections →

Every banner change is written to the paper's audit trail: a banner painted on Brand, from the pencil on the preview or by an agent, a banner removed or restored from Previous banners, its height changed, or a ready-made banner picked from the gallery. Each entry names the person who did it (or that a key did), the time, the banner version it replaced, and the style and colours it wore. Read it with the paper's admin key at GET /api/v1/papers/your-paper/audit, where banner entries carry the event banner.
Brand →

Both, on Desk settings, the Reach card. The foot: one tagline, up to five titled columns of links (one per line as Column | Label | https://your-site.com/page, or a path on this paper such as /archive), and a postal address if you print one. It appears on every page. Leave it empty and the paper keeps its plain two-row foot. On the record: one switch. On, the front carries a band of the day's most checkable statements from your own stories, each opening the story that cites it, before the stories themselves.
Reach →

On the piece in the desk, use the Off air toggle. Readers stop seeing it at once; the content and every version are kept, and the withdrawal is filed on the record so it reaches every surface. You are asked for an optional note on why, so you can tune the desk later. The note is yours: it shows on the piece while it is off air and in its History, and readers never see it. Put the piece back with On air, which clears the note.
The desk →

The look is how your paper is drawn: the layout, the theme, the bands on the front in order, and the front's numbers (title rows under the lead, the rail's depth, pieces with deks per section). Desk settings has a card for it. Wear a named look from the gallery, or leave it on your own settings, and put anything you want changed in the overrides as JSON. The nameplate, sections, sources, prompts and writers are not the look; they stay where they are.
The look →

Yes. On the look card, the overrides take a bands list: the front's bands top to bottom, by name. A band you leave out does not render; a band you move renders where you put it. The names are on the card (ticker, masthead, nav, cover, facts, news, utterances, wire, newsletter, footer and the rest). The same list goes through the API (PUT /api/v1/papers/{paper}/template) and the MCP tool set_template.
The look →

The day cover is the wide painted picture at the top of the front, above the first article. On the look card it has its own switch: it is on by default, and one button turns it off, so the front starts at the first article and nothing is painted for the day. While it is on, you can pin how many of the day's biggest stories the picture combines: the director's own choice of two or three, or exactly two, or exactly three. The same two settings, cover and cover_stories, are on the config API and the MCP set_config tool. If every story the cover combines later goes off air, the cover hides itself until a fresh one is painted, rather than show a scene for pieces readers can no longer open.
The look →

It is work from another Newsroom Floor paper that yours carries. When a paper puts its reporting on the wire and you take the offer, your paper picks up its closest pieces each day and shows them in their own section, below everything your own newsroom wrote. Each piece keeps the writer's name and the paper it came from, and opens on that paper, which holds the record. Nothing is copied: you are showing their live article, so a correction they make is a correction on your page too. It never counts towards how many sources one of your own stories stands on.
Desk settings →

By how close a piece is to what your paper says it is about. Your Coverage subjects and themes are the test: a piece that the other paper filed under one of your subjects counts for most, then its headline, then its dek and its cited facts, then its body. The closest news piece and the closest opinion piece are carried each day, ranked separately so a busy news day never crowds out the column. A piece with no connection to your subjects is not carried at all, so a wire you take never fills your paper with things your readers did not come for.
Coverage →

Open Live in the desk menu. Start an event: name it, say where you are, pick who files it. From that moment the paper has a live page at /live. The first line you put on it raises a red LIVE band at the top of the front, with the newest line, the reporter's face and a Follow button; readers who open the page see every update as it lands, without reloading. You can file three ways. Talk: link a Telegram group or chat (the next answer) and everything sent there, words, voice notes, video and photographs, goes on the page as it is said. Say it: hold the talk button on the Live page and speak; your voice is typed out under the recording. Type it: a note, with a photograph if you like. Notes filed from the Live page stay private until you press Put it on the page. Fix the words on any line; take any line off the page and the note is kept. Press Stop to end the event; tick write the wrap-up and every line on the page is gathered into one draft on your desk, in the order it was filed.
Live →

Four steps. One: on the Live page press Link Telegram. A window shows a code like /link K7QM2X; it works once and for thirty minutes. Two: open Telegram. For a group, open the group, tap its name, tap Add Members, search newsroomfloor_bot and add it. For a channel, add the bot as an administrator. For just you, open t.me/newsroomfloor_bot and press Start. Three: send the code in that chat. The bot answers Linked to your paper and gives the page's address. Every chat links on its own: a group and your private chat with the bot are two different chats. Four: start an event on the Live page, or send /live and a name in the chat. Then talk. In Stream mode, the default, every message, voice note, video and photograph goes on the page as it is said, and the bot answers each with two buttons, Pull it off and Clean it up. Send /ask and the bot asks before each line goes on. Send /quiet and lines stay private notes with a Put it on the page button. Start a line with ! to put it on in any mode. /page and /pull move the last line on or off. /end closes the event. /help lists all of it. Everyone in a linked group can file to this paper, so only add people you would give a desk seat.
Live →

On one row under the search box: Every story (every story the paper is running, newest first, at /all), the last three back issues as date pills, the archive, Staff, the API door and the subscribe landing, with sign-in on the right. The feed and the archive icons sit up on the date line beside the language toggle. The reader panel for the language and theme lives there too.
Desk settings →

Yes. 'Customize your mix' under the section nav opens a row of section chips. One tap marks a section MORE (it moves to the head of the columns), a second tap MUTES it (its block and every item filed under it hide), a third clears it. The choice is kept in that reader's browser for this paper; Reset clears it.
Desk settings →

Live instrument readings for that section: the same readings the ticker carries, bucketed by the section's topic categories (set on the Coverage card in Desk settings, per section), up to four with their instrument and age. Each opens the paper's search on that instrument. A section with no reading shows nothing, and the whole block is off until you switch it on under The data ticker in Desk settings.
Desk settings →

Desk settings, The data ticker. Two switches say where readings print: the scrolling bar across the top of the front, and 'The data' blocks under each section head. Under them, eleven kinds say what rides: NEWS (this paper's own latest headlines, in the reader's language), SCORES (finals and standings), then the instrument readings: economy, markets, odds, weather, quakes, the web, crypto, AI and world. Pick the ones that belong on your paper and nothing else appears. Over the API and MCP the same eleven ids go in set_config ticker.kinds (news, scores, econ, markets, odds, weather, quakes, web, crypto, ai, world). A new paper prints no readings at all until you pick some, so a local daily never carries AI model traffic by accident.
Desk settings →

Yes. Desk settings › Pictures, portraits and the contact form › The desk byline names it (for example 'Your Paper Desk'); pieces no persona wrote then sign with it, 'from the fact record', the paper's mark standing in for a portrait. Tick 'Sign every piece' to make it the one blanket writer for the whole paper.
Desk settings →

Desk settings › Pictures, portraits and the contact form: Masthead credit is the short line beside the nameplate; Exact accent colour is a six-digit hex for the wordmark and links when the hue alone does not land your brand. A CamelCase nameplate word (TruthFoundry) carries the accent on its second half.
Desk settings →

Desk settings › Pictures, portraits and the contact form › Analytics: paste a GA4 measurement id (G-XXXXXXXXXX). The paper then shows a cookie notice; Google Analytics loads only after a reader accepts, the choice is kept in their browser, and a Cookie settings link in the foot reopens the notice. Empty = no analytics and no notice.
Desk settings →

Yes. Desk settings › Pictures, portraits, credits and the contact form › The lake wire files every story the fact record composes (one per thread per day, two or more publishers) on your paper, signed by the desk byline, in the section that claims its category, with a footnote per publisher. Your own line's pieces stand beside them; a same-subject repeat folds to the better-sourced one on the front.
Desk settings →

The number of days this paper has published, counted from its archive. It is not the day of the year and not a counter anyone can set; a paper that has printed 31 editions reads No. 31.
The desk →

Five steps, all in Settings. The address: open the Your own domain card, add your address, and add the one record it shows you: a subdomain is one CNAME, a whole domain is one A record. Make it the primary address once it serves; from then on every newsroomfloor.com link forwards to it, path and all. The look: your mark and its dark twin, the banner, the accent, a theme, the footer columns and your own pages under the masthead. The name on it: a publisher name, a masthead credit, and a desk byline if you want the house to sign pieces. Your readers: they sign in with a DRM3 account on your own domain, the paywall and the briefing work there, and downloads are yours to post. Search engines: verify the property and submit the sitemaps from the Search engines card. What stays is one quiet powered-by line at the foot and the AI disclosure on every byline, which the law requires.
Your own domain →

Once your own domain serves and you make it the primary address, every page of your newsroomfloor.com address forwards to the same page on your domain, with the rest of the link kept. A story link in an old email or a QR code lands on that story. The catalog, the papers API and the agent file name your domain from then on. Your API key still works on the old address, and nothing forwards while the domain is pending or has an error.
Your own domain →

Yes, the full walkthrough is one public page. It covers what you get, the one record you add at your registrar (a CNAME for a subdomain, an A record for a whole domain), and what happens on its own after that. Send the link to whoever manages your DNS.
How to wire your domain →

Yes. The bar at the foot of the desk has three toggles: Docket, Page and Panels. Each one is on or off, so you can show one, two or all three; one always stays on. Double-click a toggle to show that pane alone. Option 1, 2 and 3 toggle them from the keyboard and Option 0 brings all three back. Drag the divider between two panes to size them. The desk remembers your shape on this browser.
Open the desk →

Yes. When more than one piece is waiting, every row in the approval queue carries a tick box and a Select all appears above them. Tick the ones you want and press Approve selected or Reject selected. Each piece still goes through the same publishing path on its own, with its own receipt, so a piece that cannot publish refuses by itself and the rest still land; the queue then tells you exactly what happened. Twenty-five at a time. One thing is never bulk-approved: a piece the fact check held back. Its box will not approve, the bar says how many it is leaving behind, and you open those and read the circled sentences first.
Open the queue →

Yes. Every few hours it asks the record what has come in about that story since it was written, and the queue row says so: "3 new sources since it was written". Nothing is changed behind you; the draft you were sent is the draft you open. When you open it, Fold these in adds those sources to the piece and rewrites the body so it actually uses them, then hands it back for you to read before you approve. To stop the looking on one paper, set Keep looking for new sources to off in its settings.
Open the queue →

Open the desk's Take pieces off air page (type off air in the search box at the top). Name the pieces: a section, a date range, who wrote them, or a site they cite. Write why they come down; the reason is required and is kept on every piece and in its history. Press Count first: it says how many live pieces match and lists the first ones, and changes nothing. Then take them off air, up to 200 at a time. Each piece keeps its content and its versions; put one back with On air on the piece. An agent does the same over the API (POST /stories/actions with action offline, a filter, a reason and dry_run) or the MCP tool offline_by_filter.
Take pieces off air →

Yes. Set Retire a dated draft after (Settings, the Strictness card) to a number of days. When every fact a waiting draft cites carries a date, and the newest of those dates is older than that, the approval sweep archives the draft with the reason expired: the event date passed. It is never published late, even when your approval timeout would send it. A draft with any undated fact never expires on a clock. Archived drafts stay retrievable (list_stories state archived). Off by default; also draft_expiry_days on the config API and set_config.
Strictness →

Yes. Every time a banner is replaced or removed, the old one is kept. Open Brand, go to the Masthead banner card: Previous banners shows the last six, newest first, with the style each one wore. Press Restore to put one back; the banner it replaces is kept there too, so a restore can be undone. An agent reads the banner and its history with get_banner, paints with generate_banner, restores with restore_banner and removes with remove_banner; the mark has get_mark, paint_mark and remove_mark (the same doors at /banner and /mark on the API).
Brand →

The newsroom folds reports into one story when they share three subject words, or when a meaning check reads two reports as one event told in different words. Not every word counts as a subject. Your paper's own place names count as one word between them however many are shared. A month, a weekday, a count or a span of time weighs nothing. The name of an institution, such as a university, a laboratory, an agency, a ministry or an acronym like NASA, weighs half a word and only beside a real subject word, so two stories that share nothing but a laboratory's name stay apart. If a draft still bundles two subjects, reject it from the approval queue with a reason; the reason is kept for tuning.
The desk →

Yes. Under Settings, then Writing, the clock under Who approves (If I do not get to a piece) governs every engine piece held for a person: the whole paper's pieces when the paper holds each one, and the pieces held by a section or column set to Approve on its own, even on a paper that publishes the rest as written. After the hours you set, the piece is published if it already cleared the fact check, or parked, exactly as for the whole paper, and the audit trail records which section held it. Leave the clock on Wait and a held piece waits as long as it takes. A piece waiting for a second source is never sent by the clock.
Writing settings →

Every published story carries one picture, painted by the art director from the story's own headline, standfirst and subject: a wordless picture of what the story is about, never words laid on an image. The newsroom paints it when the line files the piece. On the desk you can Generate a fresh one, add a line under Guide the image to steer it, or upload your own. There is no per-day image cap - each paint is metered against your credits like any model call (a premium paint about 6 credits, the fallback painter free), so you paint as many as your credits fund; raise what you can paint by raising credits or your plan. Every picture is kept with its story and carries a receipt of how it was made, and the last few are held, so Previous images on the desk puts an earlier one back. 1 credit is 1 cent.
The desk →

Open Settings, then Image library (under How it looks). It lists every picture this paper has painted, newest first: day and section covers, story art, portraits, the mark, its dark twin and the masthead banner. Open one to see it full size or Download it. Each says what painted it - a premium paint spent your credits, the free rail is the fallback, reused means it was recycled from another paper's stock. Reading the library spends nothing. To paint or repaint a story's own picture, use Generate on that piece at the desk; set the mark and banner on Brand and images. An agent reads the same list over GET /api/v1/papers/{paper}/images or the MCP tool list_images, so it can find a picture already made instead of re-painting one.
Image library →

A writer's voice is a short note, in your own words, that steers how that writer's pieces read: the register, the habits of phrasing, what they lead with. Open The masthead, edit a writer, and fill the Voice field. A good one is specific and about STYLE, never facts: writes plainly and short, leads with the number that matters, never hedges and never reaches for a grand closing line. The voice sets tone and selection only; it can never add a fact, and grounding always outranks it. Leave it blank and the writer uses the paper's house voice. An agent reads each writer's voice over list_personas, so it can see which writers have one.
The masthead →

The voice critic checks whether a finished piece reads in its writer's voice or as generic house style. It is quality, not a floor: it NEVER holds a piece. Off (the default) runs no check. Warn flags a piece that reads as house style instead of the writer's voice, but publishes it. Nudge rewrites the piece once toward the voice, keeps the rewrite only if it stays grounded, and publishes either way. It only runs for a writer who has a filled voice. Switch it on under Settings, then Strictness. The recipe for pieces that sound like their writer: fill each writer's Voice on The masthead, then set the critic to Nudge.
Strictness settings →

Yes. Each of the Voice instruction and the structure holds 2,000 characters. The counter under each field on Settings, then Voice, shows the length as you type and turns the accent colour at the limit. The limit is never a silent cut: a longer value is refused rather than trimmed mid-word, in the console and over the config door, so a rule is never lost off the end. If a paper's standing rules run long, split what the writer must know across the two fields - the Voice sets tone and angle, the structure sets what each paragraph does.
Voice settings →

Yes. Open Research, then Disputes, or use Flag a fact wrong on the Search page: name the fact and say what is wrong, and give the value you believe is right if you have one. The flag is appended to the fact, never a mute. The fact drops from that desk's drafting at once and is demoted in display while it is reviewed, and the claims desk is asked to research it. You rule on it under Disputes: uphold or dismiss (the fact stands, the demotion lifts) or retire (it is wrong, so it is withdrawn from drafting and display everywhere, but kept on its chain, never deleted). Retiring reaches every paper on the fleet, so only this paper's owner or a claims-desk verdict may retire a fact; a co-admin can uphold or dismiss. A fact cannot be muted or erased; it can be retired. An agent does the same with raise_dispute, list_disputes and resolve_dispute, or over POST /api/v1/papers/{paper}/facts/disputes.
Disputes →

That is the same-event reconciler. When a story the line would write is the same event as one already live on the paper and carries a new outlet or a different figure, the reconcile setting decides what happens in place of a second story. It has four positions and is off by default. Off does nothing: each outlet keeps its own piece. Shadow finds the same-event match and records on the story's trail what it would do, leaving what a reader sees unchanged. On keeps one living piece: the new outlet's figure joins its provenance and the piece is filed again as a new revision, so its link holds and the earlier revision stays in the archive; when the figures differ the headline is rewritten to read the range from the lowest to the highest, and every outlet stays on the record. Synthesize goes further on a real spread of more than two sources or three or more distinct figures: it retires the same-event originals, which stay reachable at their own links, and composes one collection piece that cites each source and states the spread, keeping every source while it averages nothing and adds no number that no source reported. An agent sets the field with set_config reconcile. It stays inert until you turn it on.
Strictness →

Open the desk and pick the Needs review tab beside All and Drafts. It carries a count and shows only the pieces that cannot go live until you act: a piece the newsroom wrote and is holding because the paper, or that piece's section or column, is set to approve, and any piece the fact check flagged. The Drafts tab still shows every unpublished piece, including the ones the line will publish on its own, so a draft there is not necessarily waiting for you. Each waiting piece also wears a Review tag in the All and Drafts lists, so you can tell the two apart wherever you look. A piece waiting only for a second source is not review work and is not counted here.
The desk →

Write a story writes one grounded report on a subject. Synthesize a feature is the synthesis head: it reads the whole set of related facts on the record, finds the single thread that connects them, and writes ONE front-page feature with a thesis, the way a national paper runs its lead story. It is not a list of the facts and not a summary of each in turn; it is one narrative built on the thread the facts show together, with every claim cited. It never invents a connection: if the facts share no real thread it skips rather than manufacture one. Press Synthesize a feature beside Write a story on Research (type a subject first), or use the button on a folder to synthesize across everything the folder holds. It files a DRAFT you review, and runs the same fact check as every other piece, so a synthesis that overreaches is held like any other draft. Over the API it is POST /api/v1/papers/{paper}/stories/compose with mode synthesis, and the tools synthesize_story and synthesize_from_folder.
Research →

Yes, both. Mint a key on the API keys card under Desk settings. A read key returns every story, its sources and the masthead as JSON; an admin key also writes the paper, over the API or over MCP, so an agent can set the voice and cadence, manage sections and the masthead, run the line, and edit or publish a piece.
API keys →

Mint an admin key on the API keys card under Desk settings; it shows once. That card shows the exact command to copy: it points an MCP client at the door at newsroomfloor.com/mcp with your key as the bearer token, so an agent that speaks MCP is wired to your paper in one line. The guide at newsroomfloor.com/agents walks an agent from a fresh key to a running paper, and lists every tool it can call. Because the key names your paper, the agent can set the voice and cadence, manage sections and the masthead, run the line, put the paper on its own domain, edit or publish a piece, and read every story and its receipt.
API keys →

Yes. On the API keys card, mint an agent key: it signs as one of your writers (pick the avatar) and is scoped to what you let it do. edit lets it fix and publish pieces; manage lets it run the day-to-day newsroom too; configure lets it change the paper's whole shape. No agent key can hand the paper away, touch payouts, or mint another key, whatever its scope. Point your bot at the key through the same door the MCP guide describes. Its edits are credited to the avatar as a co-editor, beside the writer, and the avatar reads as an automated agent on the paper; the model and prompt behind it are never shown. If the bot wants a piece to cite a source, it pushes the source through the forge first (a public link, or your own text or file), which distills it onto your record and hands back the forged facts; it then cites those by id. It can never type a source straight onto a piece, and nothing is written to the shared record.
API keys →

It never types one in. It pushes the source through the forge first: a public link is fetched and distilled as a reported source (if a site refuses our reader, send the page's text with its link and it is filed as your attested capture of that address, credited to you, the link kept); your own text or a file (a screenshot, a PDF) is read and distilled as your first-party witness. The forge screens it for safety, assigns the witness class, lands the facts in your folder and answers their ids. The agent then cites those ids on the piece and footnotes each in the body. A fact you recorded yourself can also go straight into a folder. Anything pushed earlier can be found again from the folder. This is how every cited fact on your paper traces to something forged on your record.
API keys →

Yes, that is the whole point of the API and MCP. Connect your harness with a key (the API keys card shows the one-line command). It can change the paper's settings, write and submit a new piece, edit or correct one, and publish, all through the same doors you use. A submitted piece stands on the same floor your line does: a news story needs two independent sources it cites, and every source is cited by reference to a fact already forged on your record (push a link or your own document through the forge first, then cite the forged fact by id). It can also ask the help desk for how a feature works and get the same answers you read here. Start with the agent guide, which lists every tool.
API keys →

Point it at the cockpit check, the one call to run first: the MCP tool nrf_cockpit, or GET /agent on the paper API. If it answers, the key is live and names this paper. The reply says the key's tier and exactly what it may and may not do, and links the agent guide and the help desk. It spends nothing, writes nothing, and reads no story, so it is the safe first step before the bot does any work. If it does not answer, the key is wrong or revoked: mint a fresh one on the API keys card.
API keys →

Yes. With an admin key your harness can file and work support tickets through the same desk you reach from the console. File one with the file_ticket tool, or POST /api/v1/papers/{paper}/tickets with a subject and a body (and an optional priority); list them with list_tickets or GET the same path; read a thread with get_ticket; and answer with reply_ticket. The ticket is opened under YOUR OWN DRM3 account - the account that minted the key, never the paper owner - so it shows in your account and the replies come to you by email.
API keys →

A signature over the story's bytes. It proves who filed the piece and that it has not changed since. It is added trust; it does not claim the story is correct. Readers can check it in their own browser from the story page.
Provenance →

From a shared record of the news that DRM3 keeps. Around two thousand sources are polled for it around the clock, in dozens of languages, and everything they publish is turned into facts your writers can stand a story on. Your paper reads whichever of those facts match its beat. The Sources page in the desk menu shows the whole of it: which publishers your paper has actually printed from, how often, and the master list of every source the record is read from, searchable, with each feed link ready to copy.
The sources →

Open Sources in the desk menu and paste the RSS or Atom link into the box. It is filed to your paper alone: it is polled every few hours, its articles become facts, and no other paper reads it. Most sites publish a feed at /feed, /rss or /feed.xml, and a browser extension or the site's own footer will name it. A site with no feed, such as a think tank that lists its reports on one page, works too: paste that page, and the paper reads the site's sitemap for it and files each new report from the last 90 days. The row shows Sitemap and the newest page it found. If you believe the whole record should carry a source you added, use Offer to DRM3 on its row; if we take it, we run it and you no longer have to.
The sources →

Because the list says what the record can reach, and your beat says what your paper prints. A story runs when its subject matches your coverage and enough independent outlets carry it. So the fix is almost never the source list: widen or sharpen the subjects and sections in Desk settings, or add the subject to the beats board, which measures whether the record can feed it at all. The Material page shows today's supply fact by fact, with the publisher beside each one, and says which stories are being held and why.
The material →

Yes. Everything the console does, an agent can do through the same doors: set the voice and cadence, sections and the masthead, run the line, write and submit a piece under one of your writers, edit or correct and publish, read every story and its receipt, read your leads, and ask this help desk as data. Mint a key under Settings, then Developers (an admin key does everything; an agent key signs as one of your writers and is scoped to edit, manage or configure), connect with the one line the card shows, and have the agent run nrf_cockpit first to prove the key is live. By default an agent's publish lands as a draft for an admin to sign off, no agent key can hand the paper away, touch the money or mint another key, and every publish carries the same signed receipt. The guide at newsroomfloor.com/agents walks it end to end, and the skill at newsroomfloor.com/agents/skill.md is written for the agent to read.
Bring your own agent →

Every fact on the record carries three dates: when the thing happened, when its source published it, and when the newsroom fetched it and on whose request. The forge reads the first two from the material itself: a page's own publication date, the dateline or the dates in the text. When the material does not say, it uses the date you send with the push (occurred_at, and published_at or source_date, as YYYY-MM-DD). With no date anywhere it refuses and names the one it needs, because a claim with no date reads as true on the day it was pushed. Each fact also carries the day it is true as of and how fast it goes stale; a price or a headcount is written as it was, as of its date, never as it is now. Read a folder to see all of it on every fact.
The agent guide →

robots.txt is a rule for automated crawling. When you send DRM3Bot the address of one page, from the console or through your agent's key, it reads that one page even when robots.txt disallows it, as Google's user-triggered fetchers do. It reads only that page and never the rest of the site. Every fact filed from it says so in the record: fetched by DRM3Bot, when, at the request of your paper and the key or console seat you used, and that robots.txt disallowed crawling the page (fetched_via user-request:robots-disallowed, with a sentence in fetch_note). A story that cites such a fact still names and links the publisher, and a line under the reference tells the reader DRM3Bot read it at your request, whether you cited the fact by hand, your agent cited it by id, or the engine wrote the piece from your folder. Sending the address means you have the right to ask for that page and accept being named as the one who asked. Everything the newsroom reads on its own still obeys robots.txt.
About DRM3Bot →

Yes, per paper. By default the forge needs the day the events took place on every pushed source, so a document that gives only its own publication date is refused with no_occurred_at. Turn on "Accept a source with only a publication date" on Settings, the Strictness card, and such a source lands with the event date left unknown; its publication date is still required and is always kept. An agent sets the same field with set_config accept_published_only. Off by default, so nothing changes until you turn it on.
Strictness →

Your readers are yours to take. On the Audience page, Export downloads a spreadsheet of your whole audience: every member (paying or free), every email-list subscriber and every seat, each with their address, standing, when they joined and where their signup came from. An agent reads the same over an admin key at GET /api/v1/papers/{paper}/audience, or the get_audience tool. The file is served privately and never cached, because it carries addresses.
Audience →

Every public paper has one at /subscribe on its own address (yourpaper.newsroomfloor.com/subscribe, or your own domain). It says what the paper is and hands a reader every way to get it: the paper, the email briefing, the video edition, the podcast feed, RSS, the API, and the agent edition. /channel and /about lead there too.
The catalog →

An alert is a watch you set on a paper: every story as it runs (instant), a daily or weekly briefing, only the sections you name, and the video edition when it posts. It reaches you by email, and, if you give an https address, every alert is also POSTed there as JSON (paper, cadence, sections, the stories with their links, the video) with an HMAC-SHA256 of the body under X-NRF-Signature, keyed by a signing key that is yours: the subscribe API answers with it as webhook_secret, and your alert settings page shows it. Set it on the paper's channel page under Alerts, on your own alert settings page, or by API: POST /api/v1/subscribers with {email, cadence, sections, cast, webhook}; a desk key can add up to 20 readers at once at /api/v1/subscribers. Nobody is alerted until they confirm.
Help →

On your paper's own address at /cast (yourpaper.newsroomfloor.com/cast, or your own domain): the day's newscast, every past edition, the transcript and the signed record. The front page carries the newest edition under the doors row, /podcast.xml is the same editions as a podcast feed, and the desk home's grid links it under Video edition. The paper has to be public for readers to reach it.
The catalog →

Yes, from any of three doors, all writing the same choices: as it publishes, a daily briefing, or a weekly one; which sections; and whether the video edition rides along. Every alert email carries a Change what you get link. The landing page's signup form asks the same questions up front, and confirming a signup lands on that settings page. And a reader SIGNED IN to your paper with their DRM3 account sets it on their own membership page at /member, with no email needed: the card there shows what they get, and joining from it puts them on the list at that click, because the account already proved the address.
The catalog →

Yes. On the paper's own address, /member is the reader's membership page, and The email briefing card sits on it: what they get today, when they get it, which sections, whether the video edition rides along, and a button to stop the emails. A reader who is not on the list yet gets one button to join, and joining there needs no confirmation email, because signing in already proved the address. The settings page the alert emails link to also opens for a signed-in reader with no link at all.
A reader's membership page →

The subscriber email is a curated briefing: a short written summary over the day's stories that go together, then those stories, the most-connected one first. Set how many under Settings, then Reach, then The email briefing (one to ten, five by default); the same value is briefing_size on the desk config over the API and MCP. The stories are chosen for how much they are about one another, and the summary is written by your paper's own model, billed to your account, so it reads like an editor's standfirst. If the model is out of reach the email still goes with a plain lead line, so a briefing never fails to send.
Help →

Yes, on its own address, with a front door built for it. /api is the gateway: what the API is, the base address, your first call in cURL, JavaScript and Python, every door grouped with a live try-it panel, four things to build, the three lanes, and the house rules. /api/v1 is the index that names every door as a link: stories with their cited facts, sections, the archive by day, search, the front as JSON, the video editions, subscribe, and an OpenAPI document at /api/v1/openapi.json. No key needed for a public paper. A desk key from Desk settings opens the private lane on the same address. If the paper publishes in Spanish, the whole gateway is in Spanish.
The API gateway →

Yes. Open /api on your paper's own address and scroll to the embed section: pick a story, and it writes the code. Paste it into a blog post, a docs page or a client's site. The card shows the headline, the picture, the byline and your paper's name, and every part links back to you. It sets no cookies. If the other site strips scripts, use the first version, which is a single tag. And in WordPress, Ghost or Notion you can skip the code altogether: paste the story link and it becomes the card by itself.
The API gateway →

Three levels on one address. With no key, a public paper shows what its readers already see, so a public paper is public data, and a private paper answers as if it were not there. A read key for the paper, or any seat on it, opens the paper's own level: the newsroom, the filing proofs, the settings as read and the subscriber count. An admin key, or your admin seat, writes the paper. A key names one paper and works only under that paper's address. A reader who signs in on your paper gets a reader key of their own, which reads what their subscription pays for and nothing else.
The API gateway →

POST JSON to /api/v1/subscribers on your paper's address: email, plus cadence (instant, daily or weekly), sections, and cast. The reader gets a confirm email and joins when they click it. Your desk key also reads the list at /api/v1/subscribers: the count with any key, the addresses and each reader's choices with an admin key. Give a webhook and the answer carries each reader's signing key.
The API gateway →

Your paper's address serves /api/v1/posts: every piece on air as a ready-to-post short form, sized for X, with the story link and picture. Point a scheduler or an automation at it, or copy from it. Nothing there is written by a model; it is the headline, the dek when it fits, and the link.
The API gateway →

Open Desk settings and open the Post to X card. Link your X account to your login (one click; you come straight back), then tick Post the day's news, Post the video of the day, or both, and save. The paper posts once a day as you, when the edition and the video are up. Post today's news now and Test without posting are on the same card, and every post is listed with its link.
Post to X →

Yes. The first promo in your Space (Desk settings, The Space) with a link rides every briefing as one card after the news: your title, your copy, your picture, your button, labelled as an advertisement with your publisher name. No promo set = your link-back (Reach) stands in as a plain card. No link at all = no card.
The Space →

When the paper has a published video edition, /podcast.xml on its address is a feed a podcast app can subscribe to: one episode per day's edition, the video as the enclosure. /cast is the same edition on the page.
The catalog →

Yes, through the wire. A paper files an offer (all of its stories, one section, or only the pieces it marks) and names who may carry them; a carrying paper holds a link and carries pieces as references to the source's signed, filed bytes, never copies, with the source's mark and the writer's byline on every one. Twice a day the wire picks, for each active link, the news piece and the opinion piece closest to the carrying paper's own topics; a piece already carried is never picked again. Today the doors are the keyed admin API: GET /api/v1/syndication for your standing, POST /api/v1/syndication/offers to file an offer, /market to see offers open to you, /subscribe to take one, /pick to carry one piece by hand, and /pick-now to run the day's pick for your paper at once. The carried strand sits below your own pieces on the front and says where each one came from.
The API →

Yes, the part that is yours to see. On the Audience page, click a member's or a subscriber's address and you land on their profile: their standing (a paying subscriber, a free member, or an email-list subscriber, and any staff seat they hold), how long they have been a reader and when they last opened the paper, what they asked the briefing for (how often, the sections they follow, the video edition, the language), where their signup came from (the referring site or a campaign tag), and each briefing you sent them and whether it landed. An agent reads the same over an admin key at GET /api/v1/papers/{paper}/reader with ?email=, or the get_reader tool. It is built from what the paper knows by name; it never says which stories they opened, because story reads are counted without identity.
Audience →

Desk settings, the Video edition group: switch it on, pick the lane (the drawn desk, or people on camera), the Mountain hour it bakes, the length target and the style. It bakes on Publisher and up; a lower plan keeps the setting and waits. Each edition is charged to the paper's owner at the ledger's price, 50 credits for the drawn desk and 1,200 for people on camera, when it is delivered; a bake that fails is never charged. The edition lands on the paper at /cast, in the podcast feed and on the front page. To make one right now, press Bake today's edition now in the same group: it saves the dials and queues one edition; the cast page carries it when the bake finishes.
Desk settings →

Turn on the contact form in Desk settings, under Lead capture: a reader can then send you their name, address and a note from the paper. Every lead lands in the console under Readers, then Leads, where every admin can see it, not the owner alone, and you reply straight to the address. Every admin is also emailed the moment a lead arrives and in a daily digest, and the same list is on the API at /api/v1/papers/your-paper/leads and the list_leads tool. The leads are yours; do not sell them, and honour an opt-out.
See your leads →

As one tree, and the path names the paper. Everything about a paper sits under /api/v1/papers/ followed by the paper's name: its stories, sections, days, search, config, staff, the line, its own domains and the Signal Desk. The method is the verb: GET reads, POST adds, PATCH edits the config, PUT sets the look or the public switch, DELETE removes. On the paper's own domain the same tree sits at /api/v1, because the domain already names the paper. Read /api/v1 with your key to see which paper it names, then read that paper's address to see every route your key reaches. Every error comes back as an error code and one sentence you can act on.
The API gateway →

Every paper has an About page at /about. Left alone, it is built from your paper's own details: the name, the description you set under Settings, then Reach, the sections it covers, the languages it publishes and its publisher, and nothing else. It names your paper only, never any platform. It is a plain, crawlable page a search engine can rank for your paper's name, so a clear description is worth setting. To put the page in your own words, write the About page box on the Reach card under Settings, then Reach (there is a View the About page link beside it), or send the text as the about field through the config door or the set_config tool; leave it empty and the automatic page stands.
Open Settings →

Open Support from the desk menu or your account menu. Say what happened, attach a screenshot or a file, and a person reads it. The app adds which paper you were on. Replies land on the ticket, in your DRM3 account, and in your email.
Ask for help →

Yes. Assign the folder to a paper, then on Your folders press Build a story on that folder's card (pick the paper if the folder feeds more than one). The newsroom seeds a story from the folder's facts, runs the same fact check every piece takes, and files a draft on the desk for you to review and publish. It writes only from what the folder holds; if the folder's facts do not clear the two-source floor it says the record is thin instead of inventing. A folder of only your own uploads is one witness, so its draft publishes labelled single-source, not as corroborated.
Your folders →

On Research, type the subject in the search box and press Write a story (pick the paper if you run more than one). The newsroom gathers the witnesses the record holds on that subject, plus your own folder facts on it, runs the fact check, and files a draft for you to review. It never invents: if nothing on record clears the floor it tells you the record is thin and names what is missing, and writes nothing. Over the API it is POST /api/v1/papers/{paper}/stories/compose and the tools write_story and story_from_folder.
Research →

A folder holds the facts you keep: a hand-curated, sourced corpus a paper's writers may cite. Open Research and the folder pane sits beside the record. Search, press Keep on a fact worth having, and it lands in the folder the pane is showing. Assign the folder to a paper and its writers cite those facts in stories they overlap, up to six a story; a series column draws fourteen an episode.
Research →

The folder pane on Research shows the open folder: its count, the papers it feeds, where its facts come from, and the facts fifty at a time, newest first. Search inside this folder looks in that folder only. Press a source in the strip to see only its facts. Full page at the foot gives the same folder at its own address, which is the one to send a colleague. On a phone the pane is the bar at the bottom of the screen; pull it up.
Research →

Yes. In the folder pane press Add a fact of your own, type the fact or note, say where it came from, and press Add. It lands at the top and says typed beside its source. For many links at once, Add from links and documents opens the corpus builder with this folder chosen; the refinery reads each link and keeps the checkable facts here.
Research →

Nothing is destroyed. A deleted folder moves to the archive with everything it held, and you restore it from /find/folders under Archive. Removing one fact asks first and can be undone from the message that appears for a few seconds after.
The archive →

Tag each folder with the client's name when you make it, then filter by that tag at the top of /find/folders. Assign each folder only to that client's paper, so one client's research can never be cited by another's writers.
Your folders →

Yes, with an admin-scoped key. The tools are search_record, list_folders, read_folder, create_folder, update_folder, add_to_folder, move_folder_item, remove_folder_item and assign_folder, and the same routes answer under /api/v1/papers/{paper}/folders. A key reaches the folders its desk's owner holds, and reads come back a page at a time.
Desk settings →

On Home, next to Your papers: Open N live opens every paper that is on air, each on its own address; Open N previews opens every paper you hold a seat on as its console preview, live or not. A browser lets one click open one tab, so past the first it may block the rest, and the note beside the button says how many it opened. Click the blocked pop-up icon in the address bar to allow them for this site, then try again, or unfold One at a time under the buttons and open them one by one.
Home →

Yes. When you build from your site, tick Link my site's pages under the masthead and the paper carries a row of links to your top pages. Later, set or change them through the admin API or MCP as site_links (a label and an https link each, eight at most).
Site links →

Yes. Turn on Just the facts in Desk settings, Reach. A live piece under seventy words leaves the columns and runs as one line under the news: its section, its headline, and how many sources it stands on. The story page and its receipt stay as they are.
Just the facts →

Two switches, under Settings, then Reach. The paper switch makes the paper readable at its own address and over its own API doors. The list switch, off by default, names it in every list Newsroom Floor publishes: the catalog, the public papers list on the API and the agent index. A paper that is public and not listed opens for anyone who holds its address and appears in no list, so you can share the address with a few people first and list it the day you announce it. Listing needs a description.
Reach →

Yes. Under Settings, then Reach, there is a Disclaimer box. Whatever you write there shows in the foot of every page and on the video edition, as its own quiet notice, in your own words. Use it when the voice on the paper is a person's and should not read as an official statement of an employer or an institution: for example, these are the host's own words and do not represent their university, agency or observatory. Leave it empty and the paper carries none. It is shown as written and is not translated.
Reach →

Under Settings, then Reach, tick 'Live space-data band'. It draws a band under the day's cover with the newest readings from the four space feeds (asteroid close approaches, Sentry impact risk, fireballs and space weather), each one a link into the paper's search. It shows only on a paper that also pulls those four feeds (Settings, The sources: the CNEOS close approaches, Sentry, fireballs and NOAA space weather instruments); a paper that does not carry them, or has no new readings yet, draws nothing. The readings are NASA/JPL CNEOS and NOAA Space Weather Prediction Center data, refreshed on the paper's own schedule.
Reach →

A dispatch is your own reporter, at the scene, under their own byline. That is one witness, not a rehash of somebody else's article, so the two-source floor does not apply to a live wrap-up and the piece publishes labelled as standing on one source. The reader's live page says the same thing in plain words above the dispatches.
Live →

Analytics on your desk. It opens with reads day by day over thirty days, then who reads the paper, then four sections about your audience: Users (the seats who work on it and the accounts held on it), Subscribers (the list, who confirmed, what each asked for, and how the briefing landed), Revenue (your price and who pays it), and Usage per subscriber (your own people by name, when they last opened the paper and when you last sent to them). Every country seen sits at the foot.
Analytics →

It is your paying subscriber count times today's list price, so it is what readers are billed at list, before payment fees and before the platform share, and it moves the moment you change your price. It is not cash collected. Money taken, refunds, and the credits paid into your wallet each cycle are held by DRM3 billing, not by the paper, so the paper does not show them.
Analytics →

No, and that is deliberate. Story reads are counted without identity, so no reader is followed from page to page. What you do see about your own people, because the relationship is yours, is when they last opened the paper signed in, when you last sent to them, what they asked for, whether they pay, and how many of your emails landed or were refused.
Analytics →

Your paper can carry Google's own tag. In Google Analytics, make a property for your paper and copy its Measurement id, which looks like G-XXXXXXXXXX. In Desk settings, open the Google Analytics card, paste the id, and save. Your paper then feeds Google Analytics. To show an ad buyer, send them a view-only Looker Studio link or add them to your property as a Viewer, so the numbers come straight from Google. The tag loads after a reader accepts the cookie notice, so confirm it in the Realtime report, not with a tag checker.
Google Analytics →

A Signal Desk is the other thing a property can be. Instead of a newspaper on the shared record of facts, it is a private wall of regulatory signals over one client's own record, like a county's meeting transcripts or a regulator's filings. Each headline is the action a body took, each signal has its own page with the source record behind it and a link into the moment it happened, search matches by meaning and shows you how close each hit reads, and readers keep watchlists that email them when something new matches. The whole address sits behind a sign-in wall, and the material never reaches any other paper.
Signal Desk settings →

Open Desk settings and pick Signal Desk. Set it to run as a Signal Desk, name the dataset and table your data lands in, say who supplies it and how it arrives so readers can see where it came from, choose whether only invited people read it or anyone signed in on your paper, pick how close a search hit must read, and save. Invite your readers on the same page first: switching it on walls the whole address at once. You never publish a Signal Desk - its address serves as soon as you switch it on, and the publish switch is refused on it.
Signal Desk settings →

Add their address to the reader roster at the foot of the Signal Desk page. That sends them an invite by email: the desk's name, what it is, and where to sign in with that address. They reach the desk by signing in with the DRM3 account at that address; every other account is turned away and told who to ask. Everyone who holds a seat on the paper always reads it, whatever the roster says. Set it to anyone signed in instead if you would rather not keep a list.
Signal Desk settings →

They are your paper's own sections, in the order you put them in. A section's first record category is the group a signal files under, and the section's name is the label your readers see, so you edit them on Coverage like any other section. A signal whose category matches no section still shows, at the foot, under its own name.
Coverage →

Yes, end to end. The whole setup rides the config door as one signal_desk object: whether it is on, the feeds it stands on (sources: each a dataset, a table and what readers are told about it), who may read it, how close a search hit must read, and the cadence a new watchlist opens on. The reader roster has its own door at /api/v1/papers/{paper}/signal/readers, with GET to read it and POST to invite or revoke; one feed is dropped with DELETE /api/v1/papers/{paper}/signal/connection. Over MCP the tools are get_signal_desk, set_signal_desk, disconnect_source, signal_access, invite_reader, remove_reader, send_digest, digest_subscribers, build_signals and signal_build_status. The full walkthrough is in the agent skill.
For agents →

An email in your desk's own look: your mark, name and motto on the masthead, a line with the desk's live numbers (feeds, records, signals, coverage), who invited them to the Signal Desk, one button, Create my DRM3 account, and a quiet block on what the desk is, each feed it stands on, and that this is reader access and not an admin seat. The seat is the address you invited; the account is theirs to create, and the desk opens the moment they sign in with it. Someone who already has a DRM3 account at that address signs in and is through. You get a copy of every invite unless you switch that off on the Signal Desk page. Each roster row says whether the invite went, with the date, or why it did not; press Resend invite to send it again. The same happens when a reader is invited over the API or by an agent. To see the mail yourself, press Test invite under Send me a test.
Signal Desk settings →

On the desk itself, under the search and the watchlists, a signed-in reader picks Daily, Weekly or Off next to Email me the digest. No watchlist is needed. The digest carries every signal filed since their last one, across every section and every feed, newest first, each with its headline, section, place, date and a link to its page; a reader with nothing new gets no mail. Every digest carries a link that turns it off in one click. A watchlist still emails on its own, for the signals that match it.
Signal Desk settings →

Yes. Press Send the digest now on the Signal Desk page and every reader who signed up gets theirs at once; the page then says how many were sent, how many had nothing new, and how many failed and why. The desk digest setting on the same page is the schedule: daily or weekly sends on its own, on the cadence each reader chose, and off leaves only the button. An agent does the same with send_digest, and reads the signups with digest_subscribers.
Signal Desk settings →

Yes. Analytics on your desk draws the desk's own shape: signed-in reads by day, the signals readers open most and how often they take a quick look, what they open (the front, Data, About, API, signal pages), the watch sections they pick, searches by day with the mean number of hits, the digests sent and to how many readers, what their DRM3 bells said, invites sent, the roster and seats, and readers active in the last 7 and 30 days, with each feed's records and signals. The sign-in wall is never counted, a reader is counted by a hash of their account id and never by name or address, and a search is counted by its length and its hits, never its words. An agent reads the same numbers with desk_analytics.
Analytics →

Yes, while the bell is on. Every digest the desk sends a reader, and every watchlist match it mails, also lands on that reader's DRM3 account: a line in their activity and a bell alert that opens the desk. A reader who has not created their account yet gets the email alone, and the console says so after a send (rang 3 bells, 1 no account yet). The switch is When a digest goes out on the Signal Desk page, on by default; Email only turns it off. An agent sets it with portal_alerts on set_signal_desk. A test you send yourself never rings a bell.
Signal Desk settings →

Yes, three ways. Ask this desk is a box in the deck: the question is matched by meaning against the desk's own signals, the top passages go to the model and nothing else does, and every sentence of the answer cites the signal it came from. If nothing on the desk speaks to the question, the desk says so and no model is called. Brief me, on a watchlist (Manage, or the feed head) or on the desk, writes 120 to 200 words on what is new since the reader's last digest, cited. Summarize on a signal's page turns its transcript into one paragraph cited to the video moments; the first reader pays and everyone after reads it for nothing. Each answer prints what it cost and names the passages read. The three switches are on the Signal Desk page, on by default; an agent sets them with ai on set_signal_desk and calls them with ask_desk, brief_watchlist and summarize_signal.
Signal Desk settings →

The reader who asks, from their own DRM3 credits, never you. Every call goes through the DRM3 inference queue on the reader's account, the ledger is the meter, and the line under each answer says what it charged and the balance left. A reader with no credits sees Add credits to ask with a link to their account, and nothing is called. A reader can also switch on an AI brief at the top of their digest email; that brief is paid from their credits on each send, and when their balance is short the digest goes out without it and says so. Analytics on your desk counts the asks, briefs and summaries and the credits charged. The desk's private record never leaves it except as the passages sent to the queue for that one answer; nothing is written anywhere else and nothing is kept beyond the cached summary.
Analytics →

The desk's reader pages, linked in the rail under the header on every page. The front carries one line of facts (feeds, records, signals, coverage, Private) and the signals. Data is the provenance: one card per feed with the supplier, how it arrives, the dataset, its records and signals, the last delivery read, and the tag readers see on a card. About is what the desk is: jurisdictions, the bodies that met, the date range, the owner, the private clause, and how access works. API is what a reader can read by machine on the desk's own address, listing only the doors that answer. All three sit behind the same sign-in wall as the front, and the preview shows the same pages.
Signal Desk settings →

Yes. Under Send me a test on the Signal Desk page, press Test invite or Test digest. Each goes to your own signed-in address and to nobody else, in this desk's own look and with its real numbers: the invite reads as if you had invited yourself, and the digest carries the last 10 signals. Nothing on the roster or the signups changes, and no reader's digest moves. The page then says it was sent, with the provider's id, or why it was not. An agent does the same with send_test_mail, which mails the desk's admin.
Signal Desk settings →

On the Data page, under Desk settings and on the Signal Desk page itself. It lists every feed the desk stands on, one card each, and for the feed you open it shows who supplied it and under what terms, every delivery that has landed with the file, the count and who sent it, and a search over the rows themselves. Each row opens its own origin: whether it is private, the credential it came in under, who asked for it, and the delivery it arrived on. Each feed is read with its own key, so the page shows exactly what your keys reach and nothing else.
Data →

Two ways, and the better one needs no key at all. Share the dataset to this desk from your DRM3 account and the key arrives on its own: the feed appears on the Data page, says it is connected by a share and names the person who shared it, and the account can take the share back whenever it likes. Or add the feed by hand on the Signal Desk page and paste its key under that feed on the Data page, minted on your Data console and scoped to that dataset. Either way it is stored encrypted against this desk and that feed: never shown again, never returned by the API, never written into your settings. The page shows a fingerprint and the last four characters so you can tell which key is on file.
Data →

Press Build signals now on the Data page. It reads your rows and files one signal each: the headline is the action the body took, taken from the words in the record, and the page behind it carries the source and a link into the moment it happened. Run it as often as you like. A row whose source has not changed is left exactly as it is, so a second run writes nothing, and a row that replaces an earlier one retires that signal: off the wall, still in the archive. Every run is listed under the button with what it read and what it changed. Turn on automatic builds on the Signal Desk page and a new delivery builds itself.
Data →

Because of the words on your section. A signal files under the section whose words best match the record, so the terms you put on a section on Coverage are what decide it. Those same words are also the examples your readers see in the search box, so they are worth getting right twice over. Add the words your field actually uses, then press Re-derive every row on the Data page and the whole wall refiles against your new wording.
Coverage →

The account that shared the dataset with this desk took the share back, so the key it was reading with is gone. The Data page names who did it and when, and the build refuses to run rather than half finishing. Nothing the desk already built is affected: every signal on the wall stays exactly where it is. Share the dataset to the desk again from your DRM3 account, or paste a key, and the desk carries on from where it stopped.
Data →

Yes, up to eight. Each feed is one of your account's datasets with its own supplier, its own delivery path and its own key: a data partner's nightly export beside the clerk's weekly file, say. Share a second dataset to the property from your DRM3 account and it lands beside the first, or add it by hand on the Signal Desk page. The provenance band then names every feed with what it landed, each signal carries a small tag with the dataset it came from, the Filters panel gains a Feed facet, and every build reads every feed and reports each one's rows and signals. Search, watchlists and digests work across all of them.
Signal Desk settings →

On the Signal Desk page or the Data page, type the dataset's name into its row and press Disconnect. The desk forgets that feed's key and drops it from the list; the other feeds keep their keys and nothing about them changes. The signals the feed already built stay on the wall, still tagged with the dataset they came from, because a disconnect stops the desk reading, it never unpublishes. Taking the share back from your DRM3 account does exactly the same, and an agent does it with disconnect_source.
Data →

Open the feed on the Data page and use the form headed What readers are told about that feed: who supplies it, how it reaches the desk, and an optional privacy sentence. That is what the data-and-provenance band prints under the header, so a desk standing on two feeds shows two supply chains, each in its own words. A feed you shared from your account arrives with a standard supply line until you set your own. Only the feed you are editing changes, and the band updates the moment you save.
Data →

Every signal goes off air. A newspaper serves its stories to the world, and the material on a Signal Desk is your client's private record, so switching the property back takes the whole corpus out of search, out of the site map and off every address a reader or a search engine can reach. Nothing is deleted: each signal keeps its revisions and comes back exactly as it was the moment you switch the desk on again. Because it is a withdrawal and not a preference, the page asks you to tick the confirmation before it will save, and it tells you afterwards how many signals came down.
Signal Desk settings →

No, and you should not try. A Signal Desk serves on its own address the moment you switch it on, behind its sign-in wall. Publishing is the newspaper switch - it is what puts a paper on the open web - so it is refused on a Signal Desk and there is nothing for it to do there. Your readers reach the desk by signing in at its own address with the DRM3 account you invited; nobody else gets past the wall, and search engines are told to stay out.
Signal Desk settings →

They open the desk's own address and sign in there. The Sign in link on the wall sends them to DRM3 to sign in with the account at the address you invited, and brings them back onto the desk; the session stays on that address and reaches nothing else of yours. Everyone holding a seat on the property reads it without being invited. If you want to see the desk as one of your readers sees it before you send the address out, the Data page's own preview shows you the wall exactly as it is served.
Signal Desk settings →

The new record files a new signal, and the one it replaces comes off the wall and stays in the archive with its history intact. That holds even when both records arrive in the same upload: the earlier one is still filed first and then retired, so the record of what was said before the correction is never lost. The build's own log counts them, so you can see how many signals a delivery superseded.
Data →

Yes. Each feed on a Signal Desk says what its rows arrive in: meeting records (one row per meeting with its transcript and segments, the standard columns) or the data partner's meeting zip (one zip per meeting holding its metadata and a word-level transcription, or the pages of a document). Set it on the Data page under What readers are told about that feed, or over the API with shape on the feed. A zip is read as delivered: the meeting date, the place and the body come from the partner's own metadata, the words are grouped into moments so Watch at still lands on the right minute even when no speaker is named, and each signal's page links View on the source site and shows the duration. A corrected record with the same id replaces the earlier one; the earlier version stays in the archive.
Data →

Two ways, both on the Data page. Disconnect the old feed with Also take its signals off the wall ticked: the desk forgets its key, drops it from the list and retires every signal it built; they stay in the archive and nothing is deleted. Or, for a feed that stays but was delivered afresh, press Re-derive every row: when the desk reads the whole feed it retires the signals whose rows are no longer in it and files the rest again. Over the API the disconnect takes withdraw_signals true, and an agent passes the same to disconnect_source.
Data →

A subject only ever pulls facts in, so a trade's own words (shipbuilding, tanker, port, dredging) claim every yard, ship and harbour on earth. Open Desk settings, Coverage, the Markers segment. List the words that can only mean your desk (for a paper on the Jones Act: Jones Act, cabotage, coastwise, Puerto Rico, Hawaii, Alaska, Matson, MARAD, the American yards and ports) and turn on Every fact must carry a marker. From then on a fact that names none of them never reaches the desk, whatever else it says, while shipbuilding and tankers still count when they are yours. Before you save, press Measure against today's record on the Subjects segment: every word shows how many facts it claims today and how many of those carry a marker, and the wide ones turn the warning colour with one button to remove them.
Markers →

On the Coverage card, the Subjects and Themes segments carry Measure against today's record. It reads the same facts the line will read and paints two numbers on every word: how many facts it claims, and how many of those carry one of your markers. A word that claims many and anchors few is wide, turns the warning colour, and is where off-beat pieces come from. Remove the wide words with the one button, or keep them and turn on the marker rule so they only count beside a marker. The numbers change with the day's news; measure again after a change.
Coverage →

A search engine only lists a page it has been told about: through a property you verified with it, a sitemap you submitted, or a link from a site it already knows. Your paper serves everything a crawler needs on its own (robots, two sitemaps, a canonical address, article data on every piece), but none of that reaches Google until you verify the property and submit the sitemap, which takes ten minutes on the Search engines card and no DNS change. Then give it a link: list the paper in the catalog, put it on your own site, post it. Expect days to a few weeks before pages appear; it is the engine's clock, not the paper's.
Search engines →

Open Google Search Console, add a property of the URL-prefix kind with your paper's address (https://your-address/), pick the HTML tag method and copy the code it shows. Paste it into the Google field on the Search engines card and save; the paper now serves the tag on every page, so go back and press Verify. Bing Webmaster Tools works the same way with its own tag in the Bing field, or import the property from Search Console in one click. Nothing at your registrar changes.
Search engines →

Submit both addresses the card shows: /sitemap.xml lists every page (the front, back issues, sections, staff and every piece on air, each with its real date) and /news-sitemap.xml lists the last two days of pieces in the Google News format, which is what Top Stories reads. Submitting them is the step that reaches Google. Bing, Yandex, Seznam and Naver need no submission: the paper tells them about each new page the moment it goes live, on its own.
Search engines →

Your paper is in Bing, Yandex, Seznam and Naver, and it stays current on its own. Your paper is registered with these engines and its sitemap submitted for you, and the moment a piece goes live its address is sent to them, so it can appear in hours instead of waiting days to be crawled. You do nothing, it is on by default, and the card shows the last time it ran and how many pages have gone out. To turn it off, clear the switch on the Search engines card (Keep new pages indexed in these engines) and save; nothing new is sent to the engines after that. Google works differently: it does not take the instant notice, so you reach it through the property you verify in Search Console and the sitemap you submit, which is the step above this one on the card.
Search engines →

Yes. The front page's title is your nameplate with your motto unless you set one on the Search engines card, and the description is the day's own line unless you set one. Put the words a reader would type there: the place, the subject, the language. Each piece already carries its headline, its summary, its author and its date in the form search engines read; the piece settings drawer in the editor can override a piece's own title and description.
Search engines →

Open your paper and choose File a first-party report (it is also linked from Settings, Build the corpus). Write what the source said as an utterance ("the cataloger said ..."), say who said it, where and when, and pick how you came to know it: you witnessed it, an expert told you, or an organization stated it. You stand behind it by name and the newsroom signs it, so it becomes a permanent, attributable part of the record. It is one witness, so a story written from it publishes labelled as a single source and reads "the source says X", never "X". A photo, recording or document stays private to your desk: only a fingerprint of the file and, if you add it, the place and time it was taken ride the record, so the evidence stands even though the picture does not. A filed report is append-only: to correct or withdraw it you flag it for retirement, it is never edited or deleted in place. An agent does the same with file_report, or POST /api/v1/papers/{paper}/folders/report.
Research →