Four steps
From your priorities to your decision
A program is an agreed issue area with written priorities, and it has its own named approver.
- 01Agree your prioritiesWith Byline, you write down what matters, who matters, what is excluded and who approves decisions.
- 02Receive the morning briefEach morning, Byline reads public sources against those priorities and sends a short brief. Every item shows what changed, why it matters and one call: Monitor, Note, Prepare or Respond.
- 03Inspect the evidence and the review statusEach item links to the documents it rests on. It also shows, as two separate facts, whether a person reviewed it and what the automated evidence check found.
- 04Record your decisionYour team accepts the call, or chooses another and says why. Byline records the decision in the name of the person who made it, beside the call it answers.
One item
One item, as you would read it
One invented item, as a reader sees it, with the call, the evidence and the review status. The review shown is invented too.
The association is fictional; the document is real and linked.
USDA plans to extend and revise the forms for fruit marketing orders; comments close November 23
- What changed
- On September 23, the Agricultural Marketing Service said it will ask to extend and revise its approved information collection for federal marketing orders covering fruit crops.
- Why it matters
- It may matter because the forms shape what members report under the marketing orders on the association’s priority list.
- Date
- Comment deadline: November 23, 2026
- Evidence
- “Comments on this notice must be received by November 23, 2026.”Federal Register · September 23, 2026 · Fruit Crops; Notice of Request for Extension and Revision of a Currently Approved Information Collection
- Human review
- Reviewed by Reviewer 01
- Evidence check
- One primary source supports the headline claim.
What each call asks of you
The call is one word, and it says what the item asks of you.
- MonitorA real development; wait for the next trigger before committing.
- NoteUseful context; no action expected.
- PrepareGet a position ready before the next trigger.
- RespondA specific action is called for.
Review and the record
How review, coverage gaps and the record work
Three things are kept apart so you can see what stands behind each item: an automated check of the evidence, a person’s review and your own decision.
Three separate facts
- AutomatedEvidence checkHow many independent sources report the item’s main claim, whether one of them is a primary source, and whether any disagree.
- A named reviewerHuman reviewWho signed off on this version and when, or a plain statement that no person reviewed it.
- Your teamYour decisionMade by your team and recorded in the name of the person who made it. It is separate from the evidence check and from the review.
Every Respond and Prepare item is reviewed by a named Byline reviewer before it reaches you. Note and Monitor items are set by the rules and say whether a person reviewed them. Your approver’s decision on Respond and Prepare items is separate, and Byline’s staff cannot give it.
When a morning is quiet or a source is unavailable
- A quiet morning
- The brief says what was read and what became of it. Each item set aside is accounted for by its reason: it named no party you watch, named one but met no stated priority, had been seen before, matched an exclusion you set, or could not be checked.
- A source that was unavailable
- Its feed could not be read that morning. The brief counts the sources successfully checked, lists this one under “Sources unavailable” with its last successful check, and says that what it published that morning is not in the brief.
- A source your priorities rely on
- If one of those was unavailable, the brief is marked “Coverage gap”: not an all-clear on that priority. Its subject line names the source and the priority, and it does not say that nothing needs action or call the morning quiet. The same label marks a morning when no source could be checked, and one when Byline could not read which sources your priorities rely on and a source was unavailable.
- Not counted as unavailable
- An item that could not be assessed is listed under “Found but not assessed”. Items screened out are counted under “Outside this program’s priorities” or “Outside this program’s watch list”, and items that wait for your approver’s decision under “Waiting for your approver”.
Why the record can be trusted
Every version is sealed when it is made, with a content hash. The email and the app show the sealed version you received, and it does not change, even when working data does.
A review applies to one exact version. A change to reviewed content becomes a new version, and the earlier review does not carry over to it.
That is why the record can be trusted: the version you received is the version that was sealed, and any review is bound to it.
How the rules decide
- What a rule reads
- Your written priorities, the source’s own record of what happened and when, and the passage the item cites.
- What a rule may do
- The rules set each item’s call from your priorities and the evidence. After that, a rule can only lower a call or set an item aside, never raise it. The model drafts the wording and proposes; it does not choose the call, the type of event or the certainty.
- If a call is wrong for you
- The decision is still yours. Choose another call and give your reason, and Byline records both the call it made and your decision. The record is kept.
Technical detail
For readers who want the mechanism
Optional. Each part below opens on its own.
From public source to sealed version
Eight steps, and the rule that can stop each stage
- 01Public sourcesPublic feeds and official registers.
- 02ClaimsExtracted by a model, each cited.
- 03Item draftsRelated reports joined by fixed rules, then drafted by a model.
- 04Rule checksType and certainty set in code; a deadline only when the source states it.
- 05Morning briefBuilt on written priorities, with a fixed item limit.
- 06Reviewer sign-offA named reviewer reads one exact version.
- 07Sealed versionFixed with a content hash; the version that goes out.
- 08Inbox and appEmail rendered and checked before sending; the app shows the same version.
The run repeats each morning for each program. Each stage does one job, and each has a fixed rule that can stop it.
| Number | Stage | What happens | Guardrail |
|---|---|---|---|
| 01 | Collect | Reads each source on a fixed schedule and records what it read. | A site that refuses automated reading is not retried or worked around by collection. The refusal is recorded, and a person decides whether to use an official feed or pause the source. |
| 02 | Draft | A language model extracts claims and drafts the text of each item. | The event type, the call and the certainty rating are set in code, not by the model. A deadline is kept only when the source states it. |
| 03 | Check | Compares specific points in each new item, such as status words and claims of independent confirmation, with the passage it cites. | A new item that its source does not support on those points is not written. |
| 04 | Compose | Builds each program’s brief at that program’s local hour, around its written priorities. | The brief has a fixed item limit. Items from a brief that was held and never sent move into the next morning’s brief and are marked as carried. |
| 05 | Review | A named reviewer reads and signs off one exact version. | A brief with a Respond or Prepare item is held until a named Byline reviewer has attested it; a brief with only Note and Monitor items may go out marked as not reviewed. Any change to reviewed content becomes a new version, and the earlier sign-off does not carry over to it. |
| 06 | Deliver | Renders the email from the sealed version, after verifying it against its hash, and checks the result. | An email that fails a blocking check on its rendered content is not sent. Lesser findings are recorded. |
| 07 | Monitor | Records an operator alert when a source run fails, a morning is late or missing, a brief is held, or a delivery is refused. | Alerts that need action are sent at once; the rest are gathered into one daily summary for the operator. |
Safeguards in the application and the database
Three layers, checked in turn
For a signed-in person’s request, the application checks permissions and the database checks them again, so a request that passes one layer still has to pass the next.
Checks the member’s role and scope before rendering a page or running an action.
Confines a signed-in member’s program records to the programs they were invited to. The writes that make the record (sealing a version, a sign-off, a recorded decision) run only through database functions that re-check role and scope.
Sign-offs and recorded decisions are insert-only. They cannot be edited, and they cannot be deleted on their own. Each sign-off is bound to one exact version, and a change to reviewed content withdraws it before release. Each sealed version carries a content hash.
How a change reaches production
Automated checks, and the two steps a person does
Every proposed change runs the same automated checks, and a merged change is released only after the full set passes again. Two steps are done by a person: merging the change and applying database changes to production.
- 01Proposed changeProposed as a pull request, usually as a draft first, with its own tests.
- 02Static checksTypes, lint, unit and evaluation tests.
- 03Full local stackA fresh database with every security policy, end-to-end tests and a production build.
- A personMerges the changeA person decides when a change merges.
- 04Hosted stagingSecurity policies tested against a real hosted database.
- A personApplies database changesProduction schema changes are applied by hand.
- 05ReleaseThe automated release step refuses unless production already has every database change it needs.
Under the hood
Application, data, schedule and website
- Application
- Server-rendered. A client’s team has its own pages, Byline’s reviewers and operators work in another set, and administrators have a third; a person’s role decides which they can open.
- Data
- Postgres. The record rules are enforced here, in the database, and not only in the application.
- Pipeline
- A scheduled clock runs every fifteen minutes through the morning window. Each program composes and releases at its own local times.
- Website
- Generated from committed content. A deploy is refused unless every file it uploads is identical to its committed copy, and the published files can then be audited against the commit.
Start with one morning.
A first brief is complimentary, on one issue you follow.