A list of links is not yet a research brief. The useful connection is between a question the reader needs answered, a claim the article intends to make and evidence that supports that claim.
A source manifest makes that connection explicit before a model starts writing. In this project's first implementation, a small validator checks the recorded relationships and rejects incomplete inputs. It does not browse the sources or determine whether they are true.
Start with the claims you need
Write the minimum set of factual claims required for the article. For an article about scheduling, one claim might concern which timezone controls a workflow. Another might concern the conditions for activating its schedule.
Keep each claim narrow enough to verify. A statement such as “this is the best automation platform” combines opinion, comparison criteria and evidence that a product manual is unlikely to settle.
Use official documentation for product behaviour and a real demonstration for claims about what your own workflow did. An execution screenshot and a documentation page answer different questions.
Record the review, not merely the URL
Each manifest entry contains a clean HTTPS URL, a source title, the claim it supports, its classification as a primary source, the reviewer and the time of review. The reviewer records whether the source has actually been checked.
In the tested module, the reviewed state is named verified. It is an input supplied by the reviewing process. The validator does not turn an unreviewed page into a verified source, and a typed reviewer name does not authenticate the person who typed it.
Do not fill those fields with reassuring defaults when a page is unavailable. Keep the source pending and let the gate block the brief until the uncertainty is resolved.
What the implemented validator checks
The Source Manifest Validator requires a content identifier, at least one required claim and at least one source. Every required claim must match a reviewed source entry. The current contract associates one claim with each source entry, so keep the required claims appropriately scoped.
It rejects missing reviewers, future review timestamps, unreviewed or non-primary entries and repeated source URLs. It also rejects URLs containing credentials, query strings or fragments. Its portable parser accepts DNS hostnames and plain ASCII paths only; it also excludes ports, IP literals, percent encoding and dot segments. This narrow template contract may reject legitimate source URLs and is not a general URL parser. Adapt it deliberately if a primary source needs those features.
A trailing slash does not make the same source count twice. The validator normalises that distinction when checking duplicate URLs.
The output reports source_manifest_valid and includes factual_accuracy_verified_by_code set to false. The distinction is deliberate: the code has checked the manifest, not the truth of the article.
Reproduce the tests
The implementation includes a fictional review record and local JavaScript tests. The successful case returns a valid manifest. Negative cases cover an uncovered claim, a source still pending, duplicate URLs, embedded credentials, query parameters, a future date, a missing reviewer and invalid field types.
A separate test executes the code embedded in the exported n8n workflow and compares its result with the shared validator. All 21 local tests passed after the live compatibility fix, including execution without URL or module globals and rejection of unsupported URL forms. The first live attempt exposed a URL-parsing dependency that failed in the Code node. The revised implementation uses a narrow, self-contained parser.
The workflow export is manual and inactive. Its sample reviewer is fictional and must be replaced by evidence of an actual review before using the input for production.
Real n8n result from the fictional demo manifest. factual_accuracy_verified_by_code remains false.
Changing the review state to pending stops execution. These images demonstrate the validation boundary, not the truth of the sample scheduling claim.
Give the model a bounded research packet
After the manifest passes, prepare short source notes that explain what each page supports. Keep quotations limited and distinguish a source's statement from your interpretation.
Ask the model to propose a title, audience, objective and outline from those notes. Require it to identify gaps rather than invent a citation. Then apply the existing Brief Readiness Validator to the response structure.
Keep the source manifest attached to the brief through review. If a reviewer changes the central claim, revisit its supporting evidence rather than keeping the previous sources merely because the file already passed validation.
Make the final decision editorial
A structurally complete brief may still overstate its evidence or repeat an existing article. The editor should inspect the claim-to-source mapping, the proposed angle and the image plan together.
The Source Manifest Validator is available in the project's development proposal, not yet as a public download. It has now been imported and tested in a new manual n8n workflow: the valid sample passed, changing verification_status to pending produced “Source has not been reviewed”, and restoring the valid sample passed again. The workflow remains manual and unpublished. The internal review copy of the JSON is attached to the development proposal; it is not yet a public download on the website.
References
- n8n Schedule Trigger: primary documentation for the example scheduling claim; consulted during preparation on 29 September 2026.
- n8n Execute Sub-workflow: integration boundary for a reusable validation module.
- The project's source-manifest implementation and local test suite: reproducible evidence for the specific checks described above, not an independent factual-review service.