Build a Source-Checked Competitor Table: A Computer Use Template
Build a traceable competitor research CSV with field-level sources, plan conditions and explicit unknowns. Includes a five-product template and partial worked example.
A useful competitor table lets another person check where each claim came from. The task in this tutorial is to compare Canva, Adobe Firefly, Leonardo.Ai, Ideogram and Recraft for a marketer preparing product images and social posts. The output is a comparison CSV plus a separate field-level evidence CSV. It is not an image quality ranking, and these five tools are not assumed to be direct substitutes for every part of Ofox.
Define the decision before opening five tabs
Write down the intended workflow: create a product image, change part of it, prepare readable text, keep recurring brand assets consistent and export a usable file. This gives the research a purpose. A long list of loosely related features would not tell the marketer which limitations need a follow-up test.
The table should distinguish image generation, selective image editing, background removal, text/layout, brand reuse, file formats, resolution, free-use restrictions and the unit used for paid usage. For commercial-use conditions, record the official source and applicable plan. Do not turn a marketing phrase into a legal guarantee.
Download the research kit: five-product comparison, field-level evidence, empty CSV templates and a reusable prompt. The prompt is a template, not an executed browser transcript.
Prepare the workspace and browser
Use a local Codex task with permission to create files in its workspace. Select the connected browser explicitly, since a built-in browser and an external browser can have different profiles and sign-in states. This exercise needs only public pages; it should not require a product subscription or a generation request.
Place targets.csv, both empty CSV templates and prompt.txt in the workspace. The targets contain the five selected official starting pages. They are entry points, not evidence that every requested field appears there. The agent should follow relevant official feature and documentation links that are visible on the page, recording the final URL for each fact.
If the browser is not available, consult the Computer Use permissions guide. An explicit access denial must be resolved through user controls; changing the tool or browser is not a research workaround.
Ask for evidence before the polished table
The prompt in the companion kit requests a row for each observed field. Each row contains product, field, value, source URL, source heading, a short supporting excerpt or paraphrase, collection time, plan/platform conditions and review status.
Use a two-stage prompt: “Return the evidence rows for review first; create the comparison table only after those rows are checked.” This reduces the temptation to compress uncertainty out of the final answer. It also makes mixed plan names and contradictory pages easier to notice.
A claim such as “exports SVG” must say which output or plan it describes. A feature page about vectors cannot establish that every generated raster image can be exported as editable vectors. Likewise, reading about text rendering does not measure spelling accuracy in a generated image.
Handle missing and conflicting information
Use explicit statuses; needs_clarification marks ambiguous quantities or units. not_verified means there is insufficient current evidence for the
requested field. access_denied means the page could not be accessed under current
permissions. conflict means the sources disagree. verified_vendor_statement
means the field agrees with its cited official page; it does not mean the product
was independently tested.
For prices, preserve currency, unit, billing period, plan and collection date. If annual and monthly billing controls are ambiguous, leave the amount unresolved. Never convert missing price information into a zero or label a free tier unlimited. Do not calculate a cheapest option from differently defined credits.
Run the research with a copyable task
Start with one accessible product so you can correct the evidence format before repeating the work across the remaining authorized targets. The following task is reusable; it is not a transcript of a completed browser session. Replace the filenames only if you also change the files in your workspace.
Task: research image tools for product images and social posts.
Read targets.csv and the two *-template.csv files in this workspace.
Start with the first accessible product and pause for evidence review.
Continue to other authorized products only after that format is reviewed.
Use the connected browser to read only public official product pages.
For each product, investigate generation, selective editing, background
removal, text/layout, brand reuse, export format/resolution, free limits,
paid usage units, and commercial-use conditions.
Create one evidence row per field, preserving the template columns:
product, field, value, source_url, source_id, source_heading,
short_evidence, checked_at_utc, plan_and_platform,
verification_status, review_notes, method.
Record what the source actually supports, including restrictions.
Use your actual UTC retrieval time. Paraphrase; do not invent quotations.
Use verified_vendor_statement only for statements supported by the source.
Keep not_verified, conflict, needs_clarification and access_denied separate.
Do not turn missing information into No, free, unlimited or zero.
Do not sign in, subscribe, generate images or submit external forms.
Stop at an explicit access denial; do not bypass it.
First show the evidence and unresolved questions for review.
After review, write evidence.csv and comparison.csv using the templates.
Reopen both CSVs and report row counts, missing sources and conflicts.
Review the first product at the field level. If its source only says an editor can remove a background, accept that narrow statement and leave unsupported resolution or plan details unresolved. Asking the agent to “fill every cell” at this stage encourages a polished but unusable answer.
Work one claim through to the final table
Here is a compact view of an actual record in the downloadable evidence, not a new product test. It shows why the evidence table needs more columns than the comparison table.
| Evidence field | Value from the worked record |
|---|---|
| Product and field | Leonardo.Ai — background_removal |
| Value | Background removal listed |
| Source ID | L1 |
| Source URL | Official image editor page |
| Source heading recorded at collection | Tools for precise, prompt-based image editing |
| Collection time | 2026-09-28T16:00:30.980754+00:00 |
| Status | verified_vendor_statement |
| Method | Official-page retrieval; no product UI test |
The resulting comparison cell can say “Background removal is listed in the official editor documentation; output quality and selected-plan access were not tested.” It cannot say “best cutouts,” “free high-resolution export,” or “works for every product photo.” Those require different evidence.
When a page changes, retain the old collection time and create a new observation. Do not overwrite a historical row with a current date while leaving the old claim untouched. For a source conflict, keep both relevant passages or paraphrases and their conditions in the evidence file before deciding whether either applies to your account.
A partial worked example: five targets, three researched
Checked against official sources on September 28, 2026, the companion files contain five comparison rows and 32 field/status rows. The facts below came from official pages retrieved with web research, not from operating each product UI. Canva and Adobe Firefly remain unverified because the browser refused access. We did not use another method to retrieve their blocked pages. No images were generated in any product.
| Product | What the reviewed source supports | What remains unresolved |
|---|---|---|
| Canva | No product facts verified in this run | All fields; access denied |
| Adobe Firefly | No product facts verified in this run | All fields; access denied |
| Leonardo.Ai | Its editor page describes prompt/reference editing and background removal | Selected-plan export formats, resolution and free allowance |
| Ideogram | Canvas docs describe generation, masked edits and text tools for users who still have Canvas access | New-user entitlement; inconsistent PNG plan qualifications |
| Recraft | Its design page lists raster/vector formats and reference/style controls | Credit-to-generation equivalence; exact selected-model limits |
Sources: Leonardo editor, Ideogram Canvas, Recraft design features.
One useful finding is a qualification conflict inside the Ideogram Canvas page: the image menu associates PNG with Plus and above, while its export instructions mention Basic and above. We preserved a conflict status instead of choosing the more attractive claim. Its plan overview also tells readers to use live pricing for current entitlements and quantities. A static FAQ allowance should not override that instruction.
Another important distinction concerns commercial use. Recraft’s current terms restrict Free Tier Assets to personal use. A marketing page’s general discussion of commercial rights cannot establish that a free-plan output is suitable for a client campaign. The evidence file keeps this condition with its source; this is not legal clearance for a particular asset.
Each comparison cell with source evidence retains its available plan conditions, review notes and source URL. Denied and unresolved fields keep their status rather than an invented source. This is intentional: a neat Yes/No table would hide the precise limits that matter to the marketer. The files reopen with five product rows and consistent columns; a spreadsheet UI rendering check and a five-site browser repeat have not been done.
Turn unknowns into the next decision
Imagine a campaign that needs a transparent product cutout, an editable vector logo and assets permitted for client advertising. These are illustrative requirements, not a completed campaign or a product ranking. Convert each requirement into a testable acceptance condition:
| Requirement | What a documentation review can establish | What still needs verification |
|---|---|---|
| Transparent cutout | A background-removal feature is documented | Your image’s edges, transparency and final exported dimensions |
| Editable vector logo | A relevant vector/export workflow is documented | The exported file contains editable paths suitable for your design workflow |
| Client advertising | Terms for the applicable plan can be located | The terms cover the actual asset, plan and intended use |
The source review therefore produces a follow-up test list, not an overall winner. For example, preserve the documented Leonardo editing feature as a candidate to test; preserve Recraft’s documented formats as a reason to inspect a vector workflow. Leave inaccessible tools undecided. No evidence means “not evaluated,” not “worse.”
Use the same discipline when checking your own site: the landing-page QA exercise separates a visible success message from a saved result. Both workflows require an observable acceptance condition before declaring a task complete.
Review and export
Reopen every cited source for the fields used in the final comparison. Check the heading and limitation as well as the value. Remove an inference that the source does not support; do not just attach the homepage URL to it.
Write UTF-8 CSV with fixed columns, using a CSV writer to escape commas, quotation marks and line breaks. Import the fields as text in your spreadsheet application. Check that each product occupies one row and that source URLs are intact and can be opened or copied into a browser; automatic hyperlinks depend on the application. Keep the evidence file beside it so uncertainty is not lost when the summary is shared.
Check the files without a spreadsheet application
Save the code below as check_research.py in the extracted research-kit directory, then run python3 -B check_research.py with Python 3.9 or later. It checks the supplied files against their templates, checks the expected five comparison rows and 32 evidence rows, and requires a source for each vendor-verified statement. Passing it confirms file structure, not whether the vendor claim is true.
import csv
from pathlib import Path
for name, expected in [("comparison", 5), ("evidence", 32)]:
with Path(f"{name}-template.csv").open(encoding="utf-8-sig", newline="") as f:
columns = next(csv.reader(f))
with Path(f"{name}.csv").open(encoding="utf-8-sig", newline="") as f:
reader = csv.DictReader(f)
assert reader.fieldnames == columns, name
rows = list(reader)
assert len(rows) == expected, (name, len(rows))
assert all(None not in row and None not in row.values() for row in rows)
if name == "evidence":
for row in rows:
if row["verification_status"] == "verified_vendor_statement":
assert row["source_url"].startswith("https://"), row["product"]
print(name, len(rows), "structure OK")
If you add products or evidence, update the expected counts; do not delete useful rows just to make the original counts pass. If all content opens in one spreadsheet column, choose comma as the delimiter during import. If a URL is plain text, copy it into the browser instead of treating hyperlink formatting as evidence of accessibility. If a source disappears, retain the historical record and mark a fresh verification as unresolved.
Reuse the workflow without overstating it
The reusable part is the evidence structure and review method. A second product category needs its own field definitions. Product capabilities and prices change, so date the table and recheck material fields before using it for a purchase. A research table can shortlist products for testing; it cannot replace a test of your own images, brand assets and final export requirements.
Frequently Asked Questions
- Does this include a completed browser test?
- No. This is a research template with a partial example based on official documentation for three products. The two other targets remain unverified, and no five-site browser run or product UI test was completed.
- What should a competitor research table contain?
- Use one product per comparison row and a separate evidence row for each claim. Preserve the source URL, collection time, applicable plan, method and verification status so readers can trace conclusions.
- Can I compare products when some pages are inaccessible?
- Yes, as a partial comparison. Mark the affected products or fields as unverified, keep the reason visible and leave them out of unsupported rankings. Missing evidence does not prove a missing feature.
- Does a valid CSV prove the research is correct?
- No. A CSV check verifies the structure and required fields. Product claims still need source review, and output quality needs a separate product test.


