GoGuides Endpoints: A Technical Deep Dive

GoGuides exposes one underlying trust context through multiple public surfaces. Some are optimized for cheap machine discovery, some for deep evaluation, some for human transparency, and some for source-level integrity verification. This page explains how the pieces fit together.

Developer Reference Machine-Readable Trust Provenance Source Clearance Verified Text Favicon North Star
Architecture in one sentence GoGuides uses lightweight discovery and drift signals to point machines toward deeper canonical trust records, historical evidence, and source-level integrity data.

The core idea: one trust record, multiple public surfaces

GoGuides is not designed as a collection of unrelated endpoints. The public surfaces represent different views into the same broader trust system.

A machine does not always need the full record. Sometimes it needs only a cheap signal that something exists or changed. At other times it needs the complete policy, provenance, verification, history, and machine-use basis.

Cheap signal first. Deep evidence only when needed.

A practical consumption path looks like this:

/favicon_img.php ↓ /signal.json ↓ /evaluate.php?domain=example.com&format=json ↓ /verify/{domain} + /history/{domain} ↓ /verified-text.php

1/favicon_img.php — the visual North Star

The GoGuides favicon trust marker is the lightest-weight public trust surface. It is deterministic and derived from GoGuides-resolved trust state rather than uploaded or styled by the site being measured.

Its job is not to carry the entire trust record. Its job is to provide a tiny, repeatable artifact that can be fetched, cached, compared, and monitored cheaply.

Example:

https://www.goguides.com/favicon_img.php?u=goguides.com&s=32

Relevant underlying state can include rank, grade, favicon seed, timestamps, trust state, and other resolved record inputs.

Important The favicon is not a security certificate and it is not the canonical source of truth. It is a deterministic trust-state marker and drift-monitoring surface.

If the visual state changes, the intended next step is to inspect the deeper machine-readable record.

2/signal.json — lightweight machine broadcast

/signal.json is the compact discovery and broadcast layer.

It is designed to expose enough information for a crawler, AI agent, monitor, or other automated system to determine whether a domain is interesting enough to inspect more deeply.

Current production output identifies itself as:

"system": "GoGuides Trust Signal Feed" "api_version": "signal-v2"

Typical fields include:

Design role The feed is intentionally lighter than the detailed evaluation record. Machines can poll it repeatedly and follow the evaluate URL only when a record is new, relevant, or changed.

Live endpoint: /signal.json

3/evaluate.php — canonical detailed machine record

The detailed machine-readable source record is exposed through:

/evaluate.php?domain=example.com&format=json

Current production output identifies itself as:

"system": "GoGuides Trust Evaluate" "api_version": "evaluate-v3.2"

This endpoint goes significantly deeper than the broadcast feed.

For a known domain, it can expose:

Identity normalized domain, matched URL, trust ID, source type, canonical URL
Trust state AI Rank, grade, confidence, visibility state, eligibility and policy status
Machine use read, summarize, cite, recommend, transact, sensitive advice, basis and limits
Verification status, method, active state, verification time and fingerprint
Freshness last crawl, freshness label, observation age and change timestamps
History first seen, days observed, measurement count, stability window and current-state duration
Activity recently observed state, bot hit count, bot count and last seen
Policy review automated review stage, decision, confidence, reason code and evidence summary

Machine-use clearance is not one trusted/untrusted bit

GoGuides separates different types of machine use.

A source can be readable without being citable. A source may be citable for general information without being cleared for autonomous transactions, recommendation, or sensitive advice.

"machine_use": { "read": true, "summarize": true, "cite": true, "recommend": false, "transact": false, "sensitive_advice": false, "decision": "safe_to_read_and_cite_general" }

The detailed record can also publish a basis array describing why the decision exists and a limits array describing what is not cleared.

Why this matters Access, citation, recommendation, transactions, and sensitive advice carry different levels of risk. Treating all of them as one boolean would discard important context.

4Provenance inside the evaluate record

The provenance layer records objective web state independently of the site's own marketing claims.

Current provenance data can include:

The point is not merely to score a website. The point is to preserve enough observable state to explain what the score and machine-use decision were based on.

5/verify/{domain} — human-readable verification context

Machines consume JSON well. Humans often need a public page that can be inspected without decoding a large structured response.

The verify surface provides human-readable trust and verification context.

https://www.goguides.com/verify/goguides.com

It is intended as a transparency surface, not as a replacement for the canonical machine-readable evaluate record.

Live example: GoGuides verification record

6/history/{domain} — time as part of trust

The history endpoint exposes the temporal dimension of the trust record.

https://www.goguides.com/history/goguides.com

A single crawl can tell a machine what a site looked like at one moment. Repeated observations can show continuity, change, drift, or abrupt discontinuity.

Relevant historical concepts include:

Why history matters A website can manufacture a claim instantly. It cannot manufacture a long independent observation timeline instantly.

7/profile/{domain} — public Trust Profile

Trust Profiles present current trust context in a human-readable form.

https://www.goguides.com/profile/goguides.com

The profile is useful for current state, while the history endpoint provides the time dimension behind that state.

Together they provide a public inspection path for humans while machines can rely on the structured evaluate response.

8/verified-text.php — source-level integrity records

Domain trust and source-text integrity are different problems.

Verified Text addresses the second problem by storing source-attributed text with enough metadata to test whether the normalized text has changed.

Topic lookup:

/verified-text.php?q=gravity&format=json

Direct chunk lookup:

/verified-text.php?source_key=britannica_1911&chunk_id=1911:gravity:0001&format=json

Records can expose:

"integrity": { "hash_check": "match", "hash_scope": "full_normalized_text" }

A matching hash establishes that the normalized text returned by the record is identical to the text covered by that integrity record.

Live example: Verified Text JSON lookup

9/ai-discovery — machine discovery surface

GoGuides also publishes discovery-oriented surfaces intended to make the larger system easier for crawlers and automated systems to find.

The purpose is not to duplicate the evaluate record. The discovery layer points consumers toward the authoritative machine-readable records.

Live surface: /ai-discovery

10/machine-readable-examples — integration documentation

This is the developer-facing integration guide.

It provides crawlable examples for trust records, machine discovery, verification evidence, history, Verified Text, attribution, and hash verification.

Live documentation: Machine-Readable Integration Guide

Recommended starting point for developers Read the integration guide first, then inspect the live JSON endpoints.

11The GoGuides Data License

Machine-readable trust data is more useful when automated consumers do not have to guess whether they are permitted to use it.

Supported public machine endpoints expose:

"license": "https://www.goguides.com/data-license" "license_version": "1.0"

The public license provides machine-use context for crawling, indexing, retrieval, citation, attribution, embeddings, model use, and other responsible machine consumption while protecting the GoGuides trust layer itself from wholesale cloning as a competing service.

Read: GoGuides Data License

Integration in 60 seconds

A developer does not need to begin by consuming every GoGuides surface. The minimum useful integration is to retrieve a lightweight signal first, inspect its state, and request the detailed evaluation only when deeper context is needed.

1. Retrieve the current broadcast signal

curl -sS https://www.goguides.com/signal.json | jq .

Useful first-pass fields include domain, trust_id, broadcast_fingerprint, favicon_seed, trust_state, machine_use, freshness, and evaluate_url.

2. Request the detailed record for a domain

curl -sS \ 'https://www.goguides.com/evaluate.php?domain=goguides.com&format=json' \ | jq .

3. Pull only the machine-use decision

curl -sS \ 'https://www.goguides.com/evaluate.php?domain=goguides.com&format=json' \ | jq '.machine_use'

4. Inspect provenance state

curl -sS \ 'https://www.goguides.com/evaluate.php?domain=goguides.com&format=json' \ | jq '.provenance'

5. Compare lightweight state before doing deeper work

curl -sS https://www.goguides.com/signal.json \ | jq '{ domain, trust_id, broadcast_fingerprint, favicon_seed, signal_last_changed_at, machine_use }'
Integration principle Consumers can retain compact state such as the trust ID, broadcast fingerprint, favicon seed, and last-change timestamp and perform deeper retrieval when the public state indicates that another inspection is useful.

Real production evaluate response

The following is a shortened example based on the live goguides.com evaluation record. It preserves the actual production field names while omitting some values and nested detail for readability.

{ "system": "GoGuides Trust Evaluate", "api_version": "evaluate-v3.2", "source": "goguides", "license": "https://www.goguides.com/data-license", "license_version": "1.0", "query": "goguides.com", "query_normalized": "goguides.com", "trust_id": "GG-1258677610", "favicon_seed": "f8062c194eb7ad0a", "favicon_url": "https://www.goguides.com/favicon_img.php?u=goguides.com&s=32", "observed": true, "trust_state": "observed", "public_eligible": true, "profile_allowed": true, "favicon_allowed": true, "policy_status": "allowed", "ai_rank": 74, "grade": "A", "trust_confidence": 0.74, "machine_use": { "version": "1.0", "status": "active_verified", "read": true, "summarize": true, "cite": true, "recommend": false, "transact": false, "sensitive_advice": false, "decision": "safe_to_read_and_cite_general", "basis": [ "known_to_goguides", "publicly_eligible", "policy_allowed", "stable_trust_id", "fresh_record", "policy_review_allowed", "deep_review_clean", "verified_active_record" ], "limits": [ "recommendation_not_cleared", "autonomous_transaction_not_cleared", "sensitive_advice_not_cleared", "claims_not_independently_verified" ] }, "verification": { "status": "verified", "method": "meta", "active": true, "fingerprint": "31bb0fc5..." }, "freshness": { "state": "Fresh", "last_crawl_days": 5 }, "trust_measurement_count": 297, "observation_span": "212 days across 297 observations", "trust_record_fingerprint": "c374884bb49665c2...", "provenance": { "scope": "objective_web_state_v2", "collector": "GoGuidesCrawler", "current": { "requested_url": "https://www.goguides.com/", "final_url": "https://www.goguides.com/", "http_status": 200, "redirect_count": 0, "canonical_url": "https://www.goguides.com/", "robots": { "allowed": true, "meta_robots": "index,follow", "robots_txt_sha256": "8be873d2..." }, "dns": { "nameservers": [ "ns13.domaincontrol.com", "ns14.domaincontrol.com" ], "dns_sha256": "7f055503..." }, "tls": { "certificate_sha256": "a847b120...", "issuer": "Let's Encrypt" }, "hashes": { "content_sha256": "8b57ea53...", "html_sha256": "84848f4a...", "provenance_sha256": "08da7ce9..." } } }, "history_url": "https://www.goguides.com/history/goguides.com", "verify_url": "https://www.goguides.com/verify/goguides.com" }
This is intentionally not a formal frozen schema. Developers should treat api_version and the live response as authoritative for the currently exposed contract. New fields can be added as GoGuides expands provenance and trust context.

Current HTTP behavior and access model

The following describes behavior observed from the current production endpoints. It is intentionally narrower than a formal rate-limit specification.

Public access The documented public trust endpoints shown on this page are directly requestable over HTTPS without an API-key parameter in the current public interface.
signal.json Current production responses use Content-Type: application/json and explicitly send Cache-Control: no-store, no-cache, must-revalidate, max-age=0.
evaluate JSON Current production responses use Content-Type: application/json and send Cache-Control: no-store, no-cache, must-revalidate.
License discovery Machine responses expose the GoGuides Data License through both JSON metadata and HTTP headers such as X-GoGuides-Data-License.
Endpoint identity Current machine responses expose headers such as X-GoGuides-System and X-GoGuides-Version.
Favicon response The favicon endpoint returns image/png. Cache behavior can depend on the resolved eligibility/state path, so consumers should treat the deeper trust record as authoritative.
No invented rate-limit contract GoGuides does not document a fixed public polling interval or guaranteed 429 threshold here because this page should describe behavior that is actually implemented and intentionally supported. High-volume consumers should use the lightweight discovery model and avoid unnecessary repeated deep lookups.

Likewise, this document does not promise 304 Not Modified behavior. Current machine endpoints explicitly publish no-cache/no-store directives, so integrations should use GoGuides fingerprints and change fields for state comparison rather than assuming conventional HTTP cache revalidation semantics.

Machine interaction sequence

The public architecture is designed so machines do not have to repeatedly request the heaviest endpoint.

1. GET /signal.json 2. Read: domain trust_id broadcast_fingerprint machine_use favicon_seed freshness 3. If relevant, new, or changed: GET /evaluate.php?domain=example.com&format=json 4. Inspect: policy verification provenance machine-use basis limits timeline fingerprints 5. Optional transparency: GET /verify/example.com GET /history/example.com 6. If source-text integrity matters: GET /verified-text.php?...&format=json 7. Consumer decides: read summarize cite monitor or ignore
The feed is the discovery layer. Evaluate is the detailed machine record. Verify and history provide human transparency. Verified Text provides source-level text integrity.

How fingerprints reduce unnecessary work

Several GoGuides surfaces expose compact identifiers that make comparison cheaper than repeatedly inspecting every underlying field.

trust_id Stable GoGuides identity for the normalized domain.
broadcast_fingerprint Compact signal that can help indicate that broadcast state changed.
trust_record_fingerprint Fingerprint representing the deeper resolved trust record.
favicon_seed Deterministic input used by the visual trust-marker layer.
content_sha256 Fingerprint of normalized observed content state.
provenance_sha256 Integrity fingerprint for the provenance observation state.

A consumer can compare compact state first and perform a deeper retrieval when something important changed.

Why the favicon sits at the top of the architecture

APIs are powerful, but the open web benefits from tiny signals.

The favicon North Star exists because monitoring should not always require pulling a large JSON document.

Same resolved inputs → same favicon.

Trust state changes → visual state can change.

Visual change → inspect the deeper record.

This makes the favicon useful to browsers, crawlers, site owners, monitoring systems, and automated agents as a lightweight indication that deeper state may deserve another look.

The canonical truth still lives in the structured record.

Read the dedicated explanation: GoGuides Favicon Trust Marker

What GoGuides intentionally does not claim

The endpoints expose observed and computed trust evidence. They do not prove that every statement on a website is true.

A crawler request does not prove model training.

Verification does not automatically clear a source for recommendation, transactions, or sensitive advice.

A favicon is not a security certificate.

A high rank does not bypass policy gates.

Engineering principle Publish what the evidence supports, preserve the basis, and avoid turning one signal into a broader claim than it can justify.

Endpoint quick reference

/signal.json Lightweight machine discovery and broadcast record.
/evaluate.php Detailed canonical domain trust, policy, provenance, and machine-use record.
/verify/{domain} Human-readable verification and trust context.
/history/{domain} Historical observation and continuity context.
/profile/{domain} Current public Trust Profile.
/favicon_img.php Deterministic visual North Star and lightweight drift monitor.
/verified-text.php Source-attributed, hash-verifiable text records.
/ai-discovery Discovery surface for crawlers and automated systems.
/machine-readable-examples Developer integration documentation.
/data-license Public machine-use and data licensing terms.

Inspect the live trust system

The easiest way to understand GoGuides is to follow the same path a machine can: start with a lightweight signal and drill into the full record.

Open signal.json

Open GoGuides evaluate JSON · View history · Integration guide

Related technical resources

Machine Trust Layer

GoGuides Favicon Trust Marker

Time as Trust

Verified Text Registry

AI Source Clearance White Paper

GoGuides Data License