You can do this with a small permitted text sample in a conversation. This workflow does not require connecting Notion to ChatGPT, and a proposed explanation is not a change to your workspace.
Compare the intended membership with the actual relation
This original fictional setup has Projects and Tasks databases. Each task belongs to one project. Estimated hours is a number on Tasks; the project total should sum the hours of its related tasks.
| Task page | Estimated hours | Intended project | Actual Project relation |
|---|---|---|---|
| T1: Draft labels | 3 | Exhibit A | Exhibit A |
| T2: Check dimensions | 4 | Exhibit A | Empty |
| T3: Pack signs | 2 | Exhibit B | Exhibit B |
For Exhibit A, the current related set contains only T1. Its sum of three is consistent with that set. The intended set is T1 and T2, totaling seven. Editing the total to seven would conceal the missing relation rather than repair it.
Notion's relations and rollups documentation, checked October 24, 2026, describes selecting the relation, the related property and the calculation. Check that the project rollup uses the Tasks relation, Estimated hours and Sum. A count calculation would answer a different question.
Ask for a configuration trace
Help diagnose this Notion rollup without editing anything.
Databases and one-row meanings: [ENTER]
Relation properties, direction and allowed number of related pages: [ENTER]
Actual related task pages and their numeric values: [PASTE]
Expected membership with the source of that expectation: [PASTE]
Rollup relation, property, calculation and displayed value: [ENTER]
Trace which pages contribute to the displayed result. Separate an
incorrect relation from the wrong property or aggregation. Compare
actual membership with intended membership. Do not invent missing
hours, silently add relations or replace the rollup with a constant.
Return the smallest proposed correction and expected before/after
values. List anything the supplied sample cannot establish. I will
check the properties and apply an approved change inside Notion.
This follows OpenAI's prompting guidance: supply the relevant context and the result you need. Keep screenshots or copied settings limited to material you are permitted to share.
Correct membership before changing arithmetic
Open T2 and confirm with the project owner that it belongs to Exhibit A. Add the actual Exhibit A page to its relation. If a corresponding relation is enabled on Projects, inspect that related-page list too. A text field containing the same project name is not a substitute for selecting the related page.
The expected totals are now Exhibit A=7 and Exhibit B=2. Those are fixture arithmetic, not observed results in your workspace. Read the native values after your change and inspect the contributing task pages if the totals differ.
In a disposable test copy, move T2's relation from Exhibit A to Exhibit B. Expected totals become A=3 and B=6. Restore its original relation and confirm A=7, B=2 again. This checks whether the total follows membership rather than a manually entered number.
Keep this property specification beside the databases. For a broader model question about what belongs in each table, the database-design guide addresses record meaning and references. Here, finish by checking the actual pages contributing to each rollup; a plausible number alone is insufficient.