Before You Diff Two Numbers, Make Sure You Resolved the Same Page
A cross-source audit can go wrong before the comparison even runs — by confidently landing on the wrong document, or by comparing a number a format-specific parser already mangled — and Gyrence's Resolve and Fetch primitives are built to catch each failure separately.
Before You Diff Two Numbers, Make Sure You Resolved the Same Page
Say you're building an agent to catch discrepancies in a company's reported quarterly revenue. The plan is simple: pull the number from the press release, pull it again from the official regulatory filing, pull it a third time from a data vendor's export, and flag it if they don't match. Three fetches, one comparison, done.
Except the plan has a failure mode that shows up before the comparison ever runs: what if one of those three fetches landed on the wrong page?
The failure that looks like success
Company names collide. Tickers get reused across markets. Search results serve up a syndicated re-post instead of the original filing, or an old cached version of an investor relations page instead of the current one. A naive pipeline — search for "Acme Corp investor relations," take the first result, fetch it — has no way to tell a genuinely matching page from a page that merely rendered without error. If your agent quietly lands on the wrong company's page and it happens to load fine, you get a confident answer that's confidently wrong. That's worse than a fetch that fails outright, because a failure gets investigated and a wrong-but-plausible number gets shipped into your audit report.
This is the specific problem Gyrence's Resolve primitive targets. Give it a direct URL and it verifies reachability before anything downstream touches it — a real answer for "does this page actually exist," not just a 200 status from a redirect chain. Give it a natural-language description instead — "Acme Corp's most recent 10-Q on SEC EDGAR" — and it runs a pipeline: extract what you're actually asking for, search for real candidate URLs, rank them, and then verify that the top candidate both renders and is actually about the entity you named, not just a page that happens to load. A candidate that renders but doesn't match gets dropped in favor of the next one, rather than accepted because it was first. Resolve costs zero credits, which matters if you're running it as a guard rail in front of every fetch in a recurring audit rather than a one-off lookup.
The second failure, once you've got the right pages
Resolving to the correct document only gets you halfway. The second way cross-source audits quietly go wrong is format-specific parsing damage: a number that's exact in its source document arrives at your comparison step already rounded, re-typed, or reformatted differently depending on which file type it came from.
This is where Gyrence's Fetch primitive matters for the second half of the job. Fetch detects what a URL actually is — HTML, CSV, XBRL, inline XBRL rendered inside a filing page, JSON, a spreadsheet — and returns a typed structure matched to that format, rather than flattening everything into the same markdown dump. A press release comes back as clean markdown with a link graph. A CSV export comes back as header-inferred, typed rows. An XBRL instance document comes back with its numeric facts preserved as exact source strings, not re-parsed into floating point, because financial precision is exactly the kind of thing that silently rots when a parser coerces a decimal into a JavaScript number. Every response carries a kind field and a via field, so your audit log records not just the value you extracted but what you parsed it from and how — evidence you can hand to a human reviewer instead of a black-box diff.
There's a related guard for large numeric datasets: when a Parquet or Arrow file carries a decimal precise enough that converting it would risk losing digits, Gyrence flags it with an approximationRisk marker instead of quietly rounding. A number you can see and decide about beats a number that's already wrong by the time it reaches your comparison.
Putting it together
For a recurring cross-source audit — the kind you'd actually schedule, not run once — the shape looks like: Resolve each source into a verified, entity-matched URL; Fetch each one and let format-aware parsing hand back typed, precision-preserving values; then diff. When the numbers disagree, you can trust that the disagreement is real, because you've already ruled out "we fetched the wrong page" and "the parser mangled the number" as explanations. Two independent failure modes, two dedicated checks, before the interesting comparison ever runs.
If the sources you're auditing change on their own schedule rather than yours — a filing that gets amended, a press release that gets a quiet correction — that's a different problem (WebDoppler handles the "tell me when something changed" side of things), but the resolve-then-fetch pattern above is what makes each individual check trustworthy regardless of when it runs.
Full primitive reference, including current credit costs and the complete list of content kinds Fetch handles natively, is at gyrence.com/docs.