Organise Recurring Journal Reports
Recurring Journal reports are entries created on a regular basis.
They may be written:
- daily;
- on weekdays;
- weekly;
- monthly;
- after a repeated workflow;
- after a monitoring check; or
- whenever a defined event occurs.
A consistent organisation system makes these entries easier to find, compare, review, and trust.
Without clear titles and structures, recurring reports can become a long list of similar entries that are difficult to use.
What recurring reports can contain
Recurring Journal reports may include:
- project updates;
- daily briefings;
- weekly team summaries;
- research findings;
- monitoring results;
- customer-support reviews;
- content reports;
- operational notes;
- risk summaries; or
- scheduled workflow results.
The exact content can change from one reporting period to the next.
The title, structure, source information, and review process should remain consistent enough for readers to compare entries.
Start with one clear purpose
Each recurring report should answer one main question.
For example:
- What changed today?
- What work was completed this week?
- Which issues require attention?
- What new findings were collected?
- Which deadlines are approaching?
- What risks appeared during the reporting period?
Avoid combining several unrelated reports into one entry.
A focused report is easier to produce and review.
Use a consistent naming pattern
Choose one title pattern and reuse it.
A useful pattern is:
[Report Name] — [Reporting Period]
Examples include:
- Daily Operations Briefing — 2026-06-08;
- Weekly Project Review — 2026-W23;
- Monthly Research Summary — June 2026;
- Support Quality Review — 1–7 June 2026; or
- Security Monitoring Report — 2026-06-08.
Consistent names make sorting and browsing more useful.
Include the reporting period
The reporting period tells the reader what time the entry covers.
Use a format that matches the schedule.
| Frequency | Suggested title format |
|---|---|
| Daily | 2026-06-08 |
| Weekly | 2026-W23 or 1–7 June 2026 |
| Monthly | June 2026 |
| Quarterly | Q2 2026 |
| One-time review | 8 June 2026 |
Choose one format and use it consistently.
Do not switch between several date styles unless there is a clear reason.
Distinguish report date from creation time
The report date and entry timestamp may not be the same.
For example, a report covering Friday may be created on Saturday morning.
Include the reporting period in the title or content.
For example:
**Reporting period:** 1–7 June 2026
The Journal timestamp shows when the entry was created.
The reporting-period field shows which information it covers.
Use a consistent entry structure
Repeated reports should use the same main sections.
For example:
# Weekly Project Review
**Reporting period:** 1–7 June 2026
**Status:** Needs Review
## Summary
## Completed Work
## Current Blockers
## Upcoming Deadlines
## Decisions Needed
## Unanswered Questions
## Sources
A consistent structure helps readers find the same type of information in every entry.
Keep the structure useful
Do not add sections only because they appeared in an older template.
Every section should serve a real purpose.
Remove sections that remain empty across many reports.
Add a new section when a recurring information need becomes clear.
When you change the structure, record the change so later comparisons remain understandable.
Use a short summary first
Begin with a brief overview.
The summary should explain:
- the most important change;
- the current situation;
- the main risk or opportunity; and
- what needs attention next.
Keep the summary shorter than the detailed sections.
A reader should understand the overall report before reviewing the details.
Separate facts from recommendations
Keep source-based findings separate from AI suggestions.
For example:
## Confirmed Findings
[Information supported by the source]
## Suggested Next Steps
[Recommendations for human review]
This prevents suggestions from being mistaken for confirmed decisions.
Use tables for repeated fields
Tables are useful when every report contains the same fields.
For example:
| Owner | Action | Deadline | Status |
|---|---|---|---|
| Sam | Prepare design files | 12 June 2026 | In progress |
| Mia | Confirm interviews | Not provided | Open |
Tables make it easier to compare:
- owners;
- actions;
- deadlines;
- status;
- amounts;
- categories; or
- source records.
Keep long explanations outside the table.
Mark missing information clearly
Do not leave important fields empty.
Use a visible value such as:
Not provided
Other useful values may include:
- Not available;
- Not applicable;
- Pending confirmation; or
- No change.
Choose the value that best explains the situation.
Do not let the model guess missing facts.
Record the source
Include enough source information for later verification.
A source section may contain:
- workflow name;
- source filename;
- source date;
- reporting period;
- approved website or service;
- Journal entry reference; or
- connected tool name.
For example:
## Sources
* Workflow: Prepare Weekly Project Review
* Reporting period: 1–7 June 2026
* Source file: project-status.md
* Review meeting: 8 June 2026
Do not include private credentials or connection values.
Add a review status
A review status helps readers understand whether the report is ready.
Useful values include:
- Draft;
- Needs Review;
- Reviewed;
- Approved;
- Superseded; or
- Archived.
For example:
**Status:** Needs Review
Use a status only when its meaning is clear.
Do not let an automated workflow mark a report Approved unless a real approval process supports that change.
Identify the reviewer
Important recurring reports should have an owner or reviewer.
You may include:
**Reviewer:** Project lead
Or:
**Review owner:** Operations team
The reviewer should know:
- when the report is expected;
- where it appears;
- what a normal result looks like;
- which warnings require action;
- how to correct errors; and
- when the workflow or schedule should be paused.
Use unique titles
Every recurring entry should be distinguishable.
Avoid creating several entries named:
Weekly Report
Prefer:
Weekly Project Review — 2026-W23
A unique title helps you:
- find the correct report;
- identify duplicates;
- compare reporting periods;
- confirm missing runs; and
- match the entry with Schedule Manager history.
Prevent duplicate reports
Duplicate reports may be caused by:
- the same schedule existing twice;
- overlapping scheduled runs;
- a manual run and scheduled run;
- an immediate retry after a timeout;
- two workflows writing to the same journal; or
- a delayed confirmation.
Before retrying a write:
- open the Journal;
- check the expected title;
- compare timestamps;
- review RunFlows or Schedule Manager history; and
- confirm whether the first action completed.
Identify missing reports
A consistent title pattern makes missing periods easier to notice.
For example:
- Weekly Project Review — 2026-W21;
- Weekly Project Review — 2026-W22;
- Weekly Project Review — 2026-W24.
The missing Week 23 entry is immediately visible.
When a report is missing, review:
- the schedule status;
- recent run history;
- Feluda availability;
- provider and model availability;
- source availability;
- Journal tool activity; and
- the configured destination.
Do not recreate every missed report automatically
A late report may no longer be useful.
Before recreating it, ask:
- Is the source still valid?
- Is the result still needed?
- Could the late report cause confusion?
- Has a later report already covered the same period?
- Would the write create a duplicate?
- Should the report use the original period or the current date?
Record a missed period when that is more useful than recreating outdated content.
Compare reports over time
Recurring reports become valuable when they reveal change.
Compare:
- new findings;
- resolved issues;
- repeated blockers;
- approaching deadlines;
- changed risks;
- recurring questions;
- output length;
- source coverage; and
- workflow warnings.
Use the same section names and field formats to make comparisons easier.
Compare like with like
Make sure two reports cover comparable periods and sources.
A report based on one day of data should not be compared directly with a full week without explaining the difference.
Check:
- reporting period;
- source list;
- workflow version;
- provider and model;
- missing source information; and
- any changes to the template.
Record important changes
When a recurring report changes structure, add a note.
For example:
## Report Change
From 8 June 2026, this report includes a separate Decisions Needed
section.
This helps readers understand why older entries look different.
Record workflow changes
A model, prompt, tool, or workflow change may affect the report.
When the change is important, include a brief note such as:
**Workflow update:** The summary step now uses a new output structure.
Or record the change in a separate maintenance entry.
This makes unexpected differences easier to explain.
Keep stable field names
Use the same labels across entries.
Prefer:
- Completed Work;
- Current Blockers;
- Upcoming Deadlines;
- Decisions Needed; and
- Unanswered Questions.
Avoid changing the same field between:
- Problems;
- Issues;
- Risks;
- Concerns; and
- Blockers
unless those terms truly mean different things.
Stable labels make comparison more reliable.
Use a clear value for no change
A report may have nothing new in one section.
Write:
No change
Or:
No new blockers were identified during this period.
Do not remove the section when its absence could be misunderstood.
A visible no-change result confirms that the section was checked.
Keep report length under control
Recurring reports can become longer over time.
Keep them focused by:
- limiting the summary;
- listing only current actions;
- moving completed items to an archive section;
- removing repeated background information;
- linking to detailed sources;
- separating facts from commentary; and
- including only the current reporting period.
A recurring report should not repeat the complete project history each time.
Carry forward only what remains relevant
Some information must continue into the next report.
Examples include:
- unresolved blockers;
- open actions;
- upcoming deadlines;
- pending decisions; and
- unresolved questions.
Carry these forward until they are resolved.
Mark their current status so the report does not look unchanged by accident.
Close completed actions
Do not leave completed items in the active-action list forever.
Mark them as completed or move them into a Completed Work section.
For example:
| Owner | Action | Deadline | Status |
|---|---|---|---|
| Sam | Prepare design files | 12 June 2026 | Completed |
This keeps open work separate from finished work.
Mark superseded reports
A report may be replaced because it contained an error or incomplete source information.
Add a visible note:
**Status:** Superseded
This report was replaced by:
Weekly Project Review — 2026-W23 — Corrected
Do not silently delete or rewrite important historical reports when the original result may need to remain visible.
Create corrected versions carefully
Use a title such as:
Weekly Project Review — 2026-W23 — Corrected
Explain what changed.
For example:
## Correction
The original report used an incomplete source file. This version includes
the missing project updates.
Link or refer back to the original entry when possible.
Organise reports by project or area
Use a naming prefix when one Journal contains several report series.
Examples include:
- Project Atlas — Weekly Review — 2026-W23;
- Support — Daily Handover — 2026-06-08;
- Research — Monthly Findings — June 2026;
- Security — Monitoring Summary — 2026-06-08.
The prefix helps group related entries when sorting by title or browsing.
Consider separate journals
Separate journals may help when:
- projects are unrelated;
- different teams review the reports;
- access needs differ;
- one journal becomes too busy;
- sensitive content should remain separate; or
- Journal Monitor needs a focused destination.
Do not create a new journal for every small report.
Use separation when it improves clarity or control.
Use Journal Monitor for recurring reports
Journal Monitor can show new entries as they arrive.
It is useful for:
- daily briefings;
- weekly reports;
- monitoring summaries;
- long-running research;
- multi-agent workflows; or
- scheduled Journal writes.
Select the journal used by the recurring workflow.
When the entry appears:
- confirm the title;
- confirm the timestamp;
- open the report;
- review the content;
- check for duplicates; and
- compare it with the expected reporting period.
Match reports with Schedule Manager
For scheduled reports, compare the Journal entry with Schedule Manager.
Confirm:
- the planned run time;
- the actual run;
- the completion state;
- the runtime;
- warnings or errors;
- the Journal title; and
- the entry timestamp.
This helps distinguish a delayed run from a duplicate or manually created report.
Match reports with RunFlows
For manually started workflows, use RunFlows to confirm:
- the selected workflow;
- the input;
- the path taken;
- intermediate output;
- the Journal tool call;
- the final result; and
- the run time.
Then open the Journal and compare the saved entry.
Review source consistency
Recurring reports should use the intended sources every time.
Check whether:
- a source was missing;
- a file moved;
- an external service changed;
- a tool returned less information;
- the reporting period was incomplete; or
- an old source was reused.
Make missing source information visible in the report.
Review recurring warnings
Repeated warnings may show that the process needs improvement.
Examples include:
- missing fields;
- incomplete sources;
- repeated fallback paths;
- tool timeouts;
- inconsistent classification;
- long runtime;
- duplicate titles; or
- reports that always need major correction.
Pause the schedule or workflow when repeated warnings affect trust.
Review report quality regularly
Do not review only whether the entry exists.
Check whether the report remains:
- accurate;
- complete;
- concise;
- useful;
- current;
- correctly structured;
- supported by the source; and
- appropriate for the reader.
A workflow can continue writing reports that no longer serve a useful purpose.
Remove outdated sections
A recurring template may become outdated when the project or process changes.
Review the structure periodically.
Remove sections that no longer matter.
Add sections only when they support a repeated need.
Test the updated workflow manually before restoring a schedule.
Keep privacy checks current
A recurring report may collect more information over time.
Review:
- which sources are used;
- which model processes them;
- whether the model is local or cloud-based;
- which tools receive information;
- what is written to the Journal;
- whether personal details can be removed; and
- who can access the device and journal.
Do not include API keys, passwords, access tokens, or other credentials.
Decide how long reports should remain
Retention depends on the purpose of the report and your own requirements.
Consider:
- whether the information remains useful;
- whether a newer report replaces it;
- whether it forms part of a project history;
- whether it contains sensitive information;
- whether an approved archive is required; and
- whether another system is the official record.
The Journal is a working space.
It may not replace formal record storage required by your organisation.
Archive or mark older reports
When older reports should remain available but are no longer active, mark them clearly.
You may use:
**Status:** Archived
Or move them according to the available Journal and file-management practices.
Keep active reports easy to distinguish from historical records.
Back up important report series
Do not rely on one device as the only copy of information that must be kept.
Follow your normal backup practices.
Important recurring reports may need to be exported, copied, or preserved in an approved record system.
A practical recurring-report template
Use this template as a starting point:
# [Report Name]
**Reporting period:** [Date, week, or month]
**Status:** Needs Review
**Review owner:** [Person or team]
## Summary
[Short overview]
## Main Findings
* [Finding]
## Changes Since the Previous Report
* [Change]
## Open Actions
| Owner | Action | Deadline | Status |
|---|---|---|---|
## Risks or Blockers
* [Item]
## Decisions Needed
* [Decision]
## Missing Information
* [Missing detail]
## Sources
* [Source]
## Human Review
* [Correction or approval note]
Remove any section that does not help the report.
A practical organisation routine
Use this process:
- Define one report purpose.
- Choose a consistent title pattern.
- Include the reporting period.
- Use the same main sections.
- Make missing information visible.
- Record sources.
- Separate facts from suggestions.
- Assign a review owner.
- Confirm each new entry in the Journal.
- Compare reports over time.
- Check for missing or duplicate periods.
- Record important workflow or template changes.
- Mark corrected, superseded, or archived reports.
- Review privacy and retention needs.
- Back up information that must be preserved.
Good organisation turns repeated Journal entries into a useful record of change over time.