PROPOSED PROJECT
Product Comparison Content
Help communities compare your programs side by side, with checked facts and clear answers about the differences that matter.
A better choice starts with comparable facts.
Fictional bag range
Same method, your product records

What this could look like
for your business.
A council needs to explain different community-room booking options.
WHAT IS USUALLY DONE
Comparison pages are often assembled by copying specifications into a table. Important differences remain buried, and updates become a manual search across old pages.
WHAT SOVRUN CAN DO FOR YOU
Sovrun would structure approved information about your programs into comparable records, then explain the differences that matter to communities. The content would help make vital information accessible and participation easier. The pilot covers one product family, a reviewed comparison page template, and a queue for missing or contradictory data.
“Fits my laptop”
needs more than a screen size.
The example device measures 34 × 25 × 2.2 cm. Comparing its dimensions with the recorded sleeve limits rules out Day and makes Weekender a candidate for a physical check. Screen diagonal alone would not answer this question.
device
Exceeds the listed limits.
The example device exceeds the listed height, width, and depth. Do not describe this bag as compatible with that device.
P20 / sheet 03device
Within the listed limits.
The recorded sleeve is larger in all three dimensions. Check the opening, closure, padding, and usable shape before confirming fit.
P28 / sheet 02Normalize the units.
Keep the evidence gaps.
A source sheet says 0.72 kg; the comparison displays 720 g. That conversion is exact. Calling a bag waterproof because it looks like coated fabric would be an unsupported claim.
0.72 kg → 720 g
P20 / sheet 03 supplies the original weight. Store the source value and display unit so later updates can be checked.
Unknown stays unknown.
Neither example sheet supplies a waterproof rating. Mark the field as not supplied and ask the product owner; do not infer it from the material or image.
A comparison that helps decide.
A record you can maintain.
The first build covers one defined product family and an approved page template. The same visual example explains the service across sectors; your comparison uses the attributes that matter to your own customers.

Check the usable space.
- Day sleeve
- Exceeds listed limits
- Weekender sleeve
- Within listed limits
- Final fit
- Physical check needed
- Sources
- P20 / 03 + P28 / 02
Facts stay attached.
- Source weight
- 0.72 kg
- Display weight
- 720 g
- Waterproof rating
- Not supplied
- Approval
- Product-owner review
How we’d make it happen.
Choose the decision and the source records
Identify the product family, current variants, and the customer question. Agree the attributes that matter and the designated source documents for each product.
Build comparable facts and clear explanations
Normalize units without losing original values. Draft the comparison from reviewed records and keep missing fields, contradictory sources, and uncertain compatibility in a visible queue.
Review the page and its update process
Product specialists verify every difference and practical conclusion. Test comprehension with readers, then hand over the approved template, source register, and review process for future changes.
Where AI helps
Document and language models map inconsistent product-field wording, find relevant source passages, and draft plain-language explanations from the supplied records. Code converts units and checks quantities against those reviewed records. Missing or conflicting facts remain exceptions; an attractive product image is not evidence of dimensions, compatibility, or performance.
What people approve
A product specialist approves comparable attributes, source revisions, unit conversions, compatibility wording, and limitations. Missing facts remain marked as not supplied until supported. Editors check whether the page answers the actual buying question, and the content owner approves publication and later updates.
What we’d need to start
- Specifications, terms, and identifiers for your programs
- Approved descriptions and comparison criteria
- Frequent comparison questions from communities
How we’d test it
Independently check unit conversions, source revisions, like-for-like dimensions, and missing-data behavior. Test a concrete purchase question and ensure a reader can explain the supported differences without guessing. Change a source field and verify that affected comparisons are flagged for review before publishing. Do not infer compatibility from a screen diagonal or a photo alone.
Prepared for Public sector & social impact. We would agree on the work after reviewing your brief, materials, and requirements.
This is a proposed project, not completed client work. The visuals and numbers show example outputs, not measured results.