AnswerShare Proposal for Texas First Rentals

System architecture, trust boundaries, and failure semantics.

No rebuild of your website code, CMS content model, or publishing workflow is required. A one-way outbound change notification keeps the machine layer current without giving AnswerShare access to the CMS.

AnswerShare Architecture / Technical, compliance, and network boundaries for enterprise review

None

Privileged origin access

No administrator, database, source-code, plugin, or daemon access.

Unchanged

Human experience

The existing website remains the human-facing experience.

HMAC-SHA-256

Change authentication

The exact raw request body is authenticated with a tenant-specific secret.

Route-level

Rollback

Remove the edge route, or restore the prior DNS value for the one CNAME hostname — whichever applies to you. No CMS migration or code purge.

This brief documents how AnswerShare attaches to your existing infrastructure, what it can and cannot reach, and how it behaves when something fails. It is written for the people who will be asked to sign it off — engineering, security, and whoever owns the CDN. Every section below is collapsed; open the ones your review actually needs, or take the whole thing as a PDF or Markdown download. Every operating boundary described here is inspectable from outside our network, and the last section tells you how to check each one yourself.

Expand all Collapse all

Your current architecture

Read from Texas First Rentals’s public DNS and a single page request on 2026-10-07. No access to your systems was used or required. Everything below follows from what is here, so please correct anything we have wrong before we schedule.

Domain

texasfirstrentals.com

DNS

Network SolutionsNot a Cloudflare zone.

Edge / CDN

OtherServer: vercel

Publishing / CMS

Statically generated (no CMS markers found)No CMS fingerprint in the served HTML

Keeping it current

Your build or deploy step sends one signed request listing the URLs that changed. It is the same contract any CMS uses, called from CI instead of an admin screen.We have a proven path for this.

What we will do at cutover

A CNAME cutover. One DNS record, added by you, reversible in one step.

A Worker can only be attached to a zone Cloudflare controls, and Texas First Rentals’s DNS is on Network Solutions. Moving your zone would be a far bigger ask than the single CNAME record this path needs, so we do the CNAME.

Hostname that changes: www.texasfirstrentals.com. A CNAME for www.texasfirstrentals.com at Network Solutions replaces the record that serves it today; we record that record’s exact value first. Hostnames not named here are untouched.

How AI crawlers reach the layer: AI crawlers keep requesting your existing page addresses (for example https://www.texasfirstrentals.com/page). Because that hostname resolves to AnswerShare’s edge, the request arrives there; a declared AI-crawler User-Agent on the configured roster receives the machine layer for that same address, and every other request, people and search crawlers included, is forwarded to your existing origin with the same content. No new public address is created. If the machine layer fails, the request falls back to your origin; if the edge itself fails, the hostname can be interrupted until DNS is restored.

What is in the request path: every request for www.texasfirstrentals.com reaches AnswerShare’s edge first, so people and search crawlers receive the same content but pass through our infrastructure. Vercel documents that it does not recommend an upstream reverse proxy, because it can affect firewall decisions and visibility of the real client IP. Before cutover your hosting, security and SEO owners approve the topology. We test TLS and certificate validation, redirects, cookies, forms, analytics, firewall and bot-challenge behaviour, and both edge-failure and origin-failure cases, with an independent availability monitor and a named rollback owner.

1. We stand up your machine layer on AnswerShare infrastructure and give you a preview URL to review before anything about your DNS changes.
2. You review the content and approve it in writing. Nothing is published on your domain until you do.
3. Before the call we record the exact current DNS value for that hostname, confirm the TLS certificate for it is issued, and agree a timed rollback with your DNS and hosting owners.
4. Your DNS administrator joins a short call with us — we do not perform a cutover without them present.
5. On that call you point www.texasfirstrentals.com at AnswerShare with a single CNAME record. That is the only change to your DNS.
6. We verify the record has propagated. Before and after the change we compare what a browser, real verified Googlebot and Bingbot requests (checked with the providers’ published verification methods) and a declared AI crawler receive on representative URLs and assets: status, redirects, robots directives, canonicals, rendered content and latency.
7. Rollback is restoring the DNS value we recorded before the change (replacing the CNAME, not just deleting it); DNS caches can take up to that record’s TTL to settle.

Security and Operations

What is implemented, what we test before cutover, and what we still need to agree.

Control register version 1.1 (2026-10-06). Each control shows whether it exists today, is a test we run before DNS changes, is a pilot deliverable, is a proposed default or is your decision. Nothing here is an audit, a certification or a guarantee, and a control that is not yet evidenced is shown as pending, never as an assurance. Register summary: 8 implemented today, 1 implemented; hardening planned, 3 test before cutover, 3 pilot deliverable, 2 proposed default, 1 your decision.

Your deployment

Routing and exposure

SO-01 Implemented today

The representation a request receives is chosen by its declared User-Agent only. A match against the published roster is a declaration, not an authentication of the provider.

Owner

AnswerShare engineering

Evidence

The routing matrix and the User-Agent request examples in this tab; the versioned roster.

Limitation

Anyone can declare a roster agent and receive the machine representation. It contains only approved public facts, so nothing private is exposed, but self-declared requests can inflate crawl counts and cost. Counts are reported as declared, never as verified providers.

Acceptance

Synthetic routing matrix passes before cutover: browser, Googlebot, Bingbot, every roster agent, and mixed or ambiguous User-Agent strings, with response captures kept.

SO-02 Implemented today

People, browsers and every declared search-engine crawler, Googlebot and Bingbot included, receive the unchanged website. AI companies' own crawlers, including their AI-search and user-triggered fetchers (for example OAI-SearchBot, Claude-SearchBot, PerplexityBot, ChatGPT-User), are AI agents on the roster and receive the machine layer.

The Crawler roles table in this tab lists each agent and the operator's stated role.

Which agents count as AI crawlers is a roster decision. The roster is versioned and attached to the pilot agreement, so a change is visible and dated.

Acceptance

Roster version and routing test results attached before cutover; any later roster change is logged with its date.

SO-03 Implemented today

The machine layer holds approved public facts only. Authenticated, personalised, form, API and administrative routes are passed through to your origin and never served a machine representation.

AnswerShare engineering with your content approver

The routing matrix (served, passed through, measured) in this tab.

Content you publish publicly is eligible for the layer. You approve what is eligible; we honour exclusions. On zones AnswerShare administers, any security exception for declared crawlers is limited to public read requests (GET and HEAD) and skips only bot-fight; managed firewall rules and rate limiting apply to all traffic, declared crawlers included, and login, admin and API paths are never exempted. We do not change your own security rules without your write access and your agreement.

Acceptance

Response captures for each route class (public page, form, API, asset, administrative path) reviewed by your security owner before cutover.

Availability and recovery

SO-04 Implemented today

A failed machine-layer request falls back to your origin while the edge runtime is running. The human website does not depend on machine-layer content.

The failure contract table in this tab; fault-injection results once produced.

If the edge itself fails (ingress, TLS or platform failure), the proxied hostname can be interrupted. Fallback does not cover that case; DNS rollback does.

Acceptance

Fault-injection results (backend timeout, router error, edge failure) produced and reviewed before cutover.

Recorded uptime

We engineer for five nines (99.999%). Since 13 April 2026 on our Top10Lists.us platform, and since 10 September across 10 client properties on our minute-by-minute monitor, we recorded 99.999% uptime: 7 minutes 7 seconds of interruption to our AI files over 719,843 measured production minutes, while serving more than 24 million crawler requests. Our layer fails open. People and search crawlers such as Googlebot and Bingbot are passed straight through to your own website and never reach our AI service, so none of those interruptions made a client website unavailable.

SO-05 Test before cutover

Rollback is restoring the exact DNS value recorded before the change (replacing the CNAME, not only deleting it). The prior TTL is lowered in advance and the rollback is rehearsed.

Your DNS administrator, with AnswerShare engineering on the call

DNS export before the change; rollback rehearsal report with recovery measured from several resolvers.

DNS caches mean recovery is not instantaneous and not identical at every resolver. We do not promise every resolver recovers within the advertised TTL.

Acceptance

Rehearsal completed and the recorded prior value verified by your DNS administrator before cutover.

SO-06 Proposed default

Stop thresholds (negotiation defaults, not existing service levels; frozen in the pilot agreement before cutover). A browser or search crawler receiving machine content, a tenant leak or a material safety contradiction: disable the affected serving at once, full rollback if isolation is uncertain. TLS failure, or a critical journey failing twice a minute apart from two locations: start rollback.

Proxy-attributable 5xx above 1% over five minutes with at least 100 requests: roll back. Added p95 latency over 200 ms for 15 minutes against an origin control, not corrected in the next 15: roll back. A new robots, canonical or status-code defect we caused: disable the affected serving.

AnswerShare engineering; rollback authority is yours

Threshold table in the pilot agreement; external synthetic probes during the staffed window.

Low-volume periods rely on synthetic probes, not percentages. Before production cutover the pilot agreement specifies monitoring coverage, an on-call primary and backup, alert channels, acknowledgment and rollback-initiation times, and the client's authority to order rollback; production service does not begin with these unspecified.

Acceptance

Thresholds and the acknowledgment times (five minutes to acknowledge, ten to start a rollback during the staffed window) accepted by your owner before cutover.

SO-07 Pilot deliverable

Soak: 48 hours of representative synthetic traffic with controlled fault injection in a test environment, then a staffed cutover, a seven-day production soak and a 72-hour heightened-monitoring period at its start. Accepted go-live requires the soak to complete without an unresolved stop-threshold breach.

Test report and monitoring log.

Limiting machine pages does not limit availability exposure: every request to the changed hostname traverses the edge.

Acceptance

Both periods completed without a threshold breach before the 90-day evaluation clock starts.

Update integrity

SO-08 Implemented today

Content-change notifications are authenticated with a per-tenant HMAC-SHA-256 secret over the exact request body. A tenant without a configured secret is refused; the check fails closed.

The webhook wire contract in this tab; invalid-signature test results.

The secret protects update integrity, not the public content.

Acceptance

Invalid-signature, wrong-tenant and missing-secret tests pass before the webhook is enabled.

SO-09 Implemented; hardening planned

Replay: a notification whose timestamp is outside plus or minus five minutes is rejected. Today the timestamp is optional, so a signed event without one is authenticated by its signature alone. Before activation we make the timestamp mandatory and add a unique event identifier with duplicate rejection and per-page ordering.

Replay-window behaviour in the webhook function; the hardening change and its tests when delivered.

A timestamp alone does not stop replay inside its window; that is why event identity and ordering are added.

Acceptance

Tests pass before activation: missing timestamp, duplicate event, reordered event, replay of a retired page, cross-tenant event.

SO-10 Implemented today

Revalidation fetches only the public pages of your registered hostname (the www form counts as the same host). Off-site targets are rejected, fetches are time-bounded, and a failed revalidation never takes your website offline.

The SSRF boundary and network bounds rows in this tab.

Boundary tests beyond the stated rules (redirects, private address ranges, decompressed size limits) are run before activation, not assumed.

Acceptance

Redirect, private-address, port and response-size negative tests pass before the webhook is enabled.

SO-11 Implemented today

A change signal is not automatic publication: materially changed content enters review and the previous approved representation is not destructively overwritten.

The content state machine and review-hold logic in this tab.

Review holds depend on the approver acting; the pilot freshness rule (SO-13) sets what is served meanwhile.

Acceptance

Review-hold behaviour demonstrated on a sample change before cutover.

SO-12 Implemented today

Every delivery is recorded in an audit log.

Sample redacted delivery record.

The record stores approved metadata, not page bodies; retention follows SO-15.

Acceptance

Redacted sample reviewed by your security owner before cutover.

Content parity and freshness

SO-13 Pilot deliverable

Pilot freshness policy: no seven-day stale service. Changed content awaiting approval is answered from your origin rather than a superseded representation. Deletions, noindex changes and sensitive corrections retire and purge the affected representation; loss of freshness assurance disables the affected machine response.

Retirement and purge test results; actual cache behaviour captures (header strings alone are not evidence).

A purge is verified by test, not assumed from headers.

Acceptance

Retirement and purge confirmed within five minutes of an accepted notification in the test, before the corresponding feature is enabled.

SO-14 Test before cutover

Each machine page represents the material facts of its corresponding approved human page, keeping its qualifications. Status codes, redirects, canonical relationships, robots directives, language and important links are preserved. Facts the AI-side briefing carries but your website does not (for example counts, entity wording, hours that differ between pages, safety or contract summaries) are either added to your website with your approval or removed from the initial cohort; a parity report lists each one.

The one labelled exception is dated third-party review ratings, each shown with its platform, date and scope, which you can have removed on request. Fixed output fields, escaping, source restrictions and review gates reduce prompt-injection risk; they do not guarantee how a downstream model reads published text.

URL-by-URL side-by-side captures for people, search crawlers and AI agents; fact-source extracts.

Whole-site overlap does not prove per-URL equivalence, so parity is checked per URL for an agreed initial cohort and repeated after changes.

Acceptance

Initial cohort passes before cutover and again after every change to it.

SEO release gate: Pilot preparation may use a non-indexable preview, but no production DNS change or crawler-facing publication may occur until the following evidence is recorded and passes. Identify the exact production hostname, its existing and proposed DNS targets, the explicit origin destination, host-header handling, TLS behavior and apex/www redirect chain.

Demonstrate that origin forwarding does not loop through the new edge hostname. Capture representative branch, equipment, service, language, deleted and redirected URLs, plus robots.txt, sitemaps and required rendering assets, before and after routing. Compare browser, synthetic routing probes and verified Googlebot and Bingbot delivery using provider verification methods and available diagnostic or crawl evidence; a spoofed User-Agent alone does not verify a provider.

Include the existing hosting firewall and bot-challenge path. Preserve status codes, redirects, robots and noindex directives, canonicals, hreflang, material content, important links and rendering assets.

A site-wide briefing is a separately identified resource. It must not be returned indiscriminately in place of individual branch, product or service pages. Each routed page must retain its own material facts and qualifications, with a canonical appropriate to that content. Keep preview hosts non-indexable and test machine/human cache separation. Demonstrate retirement and purge for deletions, redirects, noindex changes and sensitive corrections; changed content awaiting approval must fall back to the current origin, not the superseded representation.

Test actual served responses rather than relying on cache headers.

Record baseline search crawl and indexing health in Google Search Console and Bing Webmaster Tools, together with origin-control availability and latency. Demonstrate backend-failure fallback and rehearse DNS restoration from multiple resolvers using the recorded prior values and lowered TTL. Record recovery time. Machine content delivered to people or conventional search crawlers, or a new proxy-attributable robots, canonical, redirect, status or rendering defect, requires immediate disabling of the affected serving and full rollback when isolation is uncertain.

Apply the existing availability and latency stop thresholds and investigate any material crawl or indexing regression against the baseline. A failed or missing acceptance test prevents production rollout; this gate is a technical SEO acceptance requirement, not an assertion that tests have already passed.

Data, access and ownership

SO-15 Proposed default

Request-data handling is documented per data category (proxied request data, machine-request logs, webhook records, stored representations and vectors, backups): fields, purpose, processor and location, access, retention and deletion. Proposed retention defaults: raw machine-request IP logs 30 days; minimised operational and webhook metadata 90 days; de-identified aggregate pilot reports 12 months; superseded representations 30 days; on termination, active-store deletion within 30 days and backup expiry within 90 days.

Incident notice within 24 hours of confirming an incident affecting your data or service.

AnswerShare engineering and your security owner

Data table completed with the actual providers and settings, the subprocessor list, access list and a deletion test on sample records.

A proxy processes the requests that traverse it, potentially including cookies, authorization headers and submitted form data. "Not recorded in AnswerShare application telemetry" does not mean "not processed by an infrastructure provider". The defaults above are proposals until the schedule is signed.

Acceptance

Data table, subprocessor list and the signed retention schedule approved by your security owner before cutover.

SO-16 Test before cutover

Administrative access, secret storage and rotation, who can deploy or change routing, release review, emergency changes, tenant isolation in storage, caches and authorization, and security testing are documented and demonstrated to your security owner rather than asserted.

Redacted settings, access review, a release example and cross-tenant negative tests.

Not independently audited. No SOC 2, ISO 27001 or similar certification is claimed; this section describes controls and is not an audit report.

Acceptance

Security-owner sign-off on the evidence set before cutover.

SO-17 Pilot deliverable

Operations: a named operating contact and backup, coverage hours, alert channels and the rollback authority are written into the pilot agreement. Machine-route outcomes (declared agent, status, representation version, fallback reason, cache disposition, request identifier) are logged without credentials, cookies, bodies or sensitive query values, with counters for rate anomalies, repeated misses, malformed agents, tenant-boundary attempts and webhook authentication failures.

Sample dashboard, an alert exercise, a load test and the incident runbook.

Latency is reported as the runtime measures it; that is not proof of receipt by a remote crawler.

Acceptance

Alert exercise and runbook walk-through completed before cutover.

SO-18 Your decision

You control your DNS and may order a bypass or rollback at any time. You receive the configuration and reporting artifacts, you can disable the webhook, and secrets, records, vectors and backups are deleted on the schedule in SO-15 at exit. Fees pause for qualifying vendor-caused outages or delays, as the pilot agreement states.

You; AnswerShare executes

Exit runbook and deletion report.

Provider-imposed retention and legal holds are listed as exceptions in the agreement.

Acceptance

Exit terms accepted in the pilot agreement before start.

The supporting evidence is collected on the Evidence tab: the claim index, the measurement method, the raw baseline records and the pilot acceptance summary.

Key questions answered

The enterprise architecture in one page.

AnswerShare deploys an optimized machine-readable translation layer for recognised AI inference and answer engines at the CDN edge. It does not modify the client’s origin server, CMS installation, content model, or publishing workflow.

Terminology: HMAC-SHA-256 is symmetric message authentication, not an asymmetric digital signature. The present webhook implementation uses HMAC; cryptographic receipt signing is a separate evidentiary control.

Control-plane summary

Two paths with different safety priorities.

The read path is availability-biased: human, search, unknown, and identity-mismatch requests pass through to the existing origin. The update path is integrity-biased: unsigned, stale, off-site, incomplete, or unverified changes cannot modify the managed machine layer.

Architecture patternEdge proxy + tenant-scoped revalidation

Trust boundaryClient-approved public origin only

Freshness triggerSigned one-way HTTPS webhook

Write dispositionReview hold on material change

Deployment footprint

CDN edge worker

Attached through a proxied edge route. DNS enables routing; execution occurs at the CDN edge.

System of record

Your website

The client-controlled human website remains the source of truth for approved first-party facts.

Content boundary

Approved public facts

No private operational data, credentials, non-public staging content, or sensitive personal information.

Passthrough population

Humans + search

Humans, Googlebot, Bingbot, and unverified requests continue to the existing origin.

Machine population

Eligible AI crawlers

Only User-Agents on the configured AI-agent roster are eligible. Everything else, including Googlebot and Bingbot, passes through to the origin.

Synchronization

One-way change webhook

The client emits a signed notification; AnswerShare retrieves only the declared public URL.

CDN & Worker runtime

The Worker is a narrow router inside the existing CDN request path.

The current implementation uses a Cloudflare Worker attached to a hostname route in whichever CDN zone answers for the client’s domain — their own Cloudflare zone where one exists, otherwise AnswerShare’s, reached by the CNAME described in Your current architecture above. It executes before the origin is contacted, makes one bounded routing decision, and otherwise forwards the original request to the existing website.

01 · CDN ingressExisting hostname

TLS and HTTP ingress remain on the client’s proxied domain. The origin address and application do not move.

02 · Worker routeScoped interception

A route pattern invokes the Worker only for configured hostnames and paths. Assets, administration routes, and designated public files can bypass classification.

03 · DecisionClassify by declared agent

Method, path and the declared User-Agent, matched against the configured AI-agent roster, determine eligibility. Source IP and ASN are not part of the decision. A User-Agent is a declaration, not proof of identity, which is why the layer holds only public facts.

04 · ResponseOrigin or machine layer

Passthrough uses the original request. Eligible machine requests use an isolated cache or a tenant-authenticated backend fetch.

What changes in the client environment?

The CDN or DNS configuration changes; the website does not. On the Worker path a proxied route must invoke the Worker, and if the hostname is already proxied through Cloudflare its origin target normally remains unchanged. On the CNAME path the client publishes a single CNAME record for the agreed hostname and nothing else in its own zone changes. The client authorizes that one route or record, it is documented, and rollback is removing or disabling the route, or restoring the DNS value recorded before the change.

After a DNS rollback requests return to the original path as resolver caches expire. Recovery is measured in the rehearsal rather than assumed instant; no CMS database rollback or code purge is required.

Implementation topology

The serving plane and update plane remain separate.

A signed CMS event starts the update path. A crawler request starts the serving path. Neither path requires administrative access to the client CMS, database, source repository, VPN, or private network.

01 · EmitClient CMS

Outbound HTTPS POST after publish, update, unpublish, or delete.

02 · AuthenticateWebhook ingress

Tenant lookup, raw-body HMAC verification, replay check, and URL allowlist.

03 · RecordDelivery log

Event, payload, signature result, disposition, and error are persisted.

04 · RevalidateClean-room fetch

Only the declared public, same-host URL is retrieved and validated.

05 · Publish controlMachine layer

Idempotent upsert into review, live, or retired state under tenant policy.

Independent serving pathRequest → CDN edge policy → existing origin or managed machine layer. Unknown identity and evaluation failure resolve to origin.

if (human || traditional_search_bot || !declared_ai_agent_on_roster) { return fetch(origin); } if (declared_ai_agent_on_roster) { return serve(machine_layer); }

Routing matrix

Served, passed through, or measured.

“AI surface” does not always mean “AI crawler.” The routing policy distinguishes direct machine-layer delivery from answer-surface measurement.

Crawler roles: what a request from each agent does and does not show

Routing treats every agent on the configured roster alike: a declared match receives the machine layer. Crawl reports count requests by agent and by role, as self-identified requests, so training collection, search indexing and user-triggered fetches are never added together.

No single request is presented as a recommendation or a citation; answer outcomes are measured separately on the fixed prompt panel. Roles are as each operator states them in its published crawler documentation.

Google AI boundary

Google AI Overviews remain origin-fed.

Google states that AI Overviews and AI Mode are part of Search and use the Google Search index. Googlebot therefore continues to receive the human origin site. AnswerShare measures those answer surfaces without representing that they receive the selective machine-layer response.

Authentication & abuse controls

Identity is verified at each trust boundary.

Crawler identity controls protect the serving decision. Tenant-specific request authentication, replay protection, and URL validation protect the update decision.

No privileged ingress

AnswerShare requires no CMS administrator, database, hosting-panel, source-repository, or internal-network credentials. Public origin requests are ordinary HTTP passthrough—not privileged origin access.

Crawler identity

The declared User-Agent is the routing signal, matched against a configured roster of AI retrieval agents. That is a deliberate choice rather than a gap: it is what lets you audit the machine layer yourself, from any machine, with a single curl -A GPTBot against a published URL.

Source-IP gating would answer that check with the human page and make our work unverifiable to the person paying for it. The trade is sound because the machine layer contains nothing confidential — it is built from pages you already publish, so a forged User-Agent obtains only what any visitor could already read. Unrecognised identities receive the origin.

Webhook authentication

The tenant slug resolves a tenant-specific secret. x-geolocus-signature must contain sha256=<hex> for the HMAC of the exact raw body. Missing secrets fail closed; missing or invalid signatures return 401. The header name is a legacy identifier kept so existing integrations keep working: it is AnswerShare’s own header, set and verified by AnswerShare, and does not indicate a third-party service or subprocessor.

Data and logging boundary

The managed layer is limited to approved public facts and their provenance. The webhook payload is logged for delivery evidence, so its contract deliberately excludes credentials, page bodies, database schemas, private URLs, and sensitive personal information.

On the serving side the logging is deliberate and is the product's measurement surface, not incidental telemetry: each eligible machine request is recorded with its source IP, its bot classification and its time to last byte, measured at the network buffer rather than by a client-side tag, which is why these figures exist for crawlers that never execute JavaScript. Human traffic passes through untouched and is not recorded here.

Webhook wire contract

One-way notification. Public revalidation.

The webhook keeps AnswerShare synchronized with the latest approved version of the client’s public site. The client initiates one outbound HTTPS request. AnswerShare does not initiate a session into the CMS, network, database, or control plane.

POST /functions/v1/content-update-webhook?client=<tenant-slug> Content-Type: application/json x-geolocus-signature: sha256=<hex HMAC-SHA-256 of exact raw body> { "event_type": "page.updated", "urls": ["https://client.example/public-page"], "timestamp": "2026-09-08T20:00:00Z", "status": "review" }

What “one-way” means here

HTTP returns an acknowledgement, but it creates no inbound AnswerShare connection to client systems. After authenticating the notification, AnswerShare performs an ordinary public HTTPS fetch of the declared URL—exactly the information already available outside the client network.

Client → AnswerShareTenant slug, event type, public canonical URL, timestamp, and optional target state.

AnswerShare → Client private systemsNone. No CMS credentials, database access, VPN tunnel, agent, daemon, plugin, or administrative API session.

AnswerShare → Public originBounded GET request for the signed, same-host public URL after validation.

Webhook responseProcessing acknowledgement and delivery identifier so the CMS can distinguish success from a retryable failure.

Authentication

Per-tenant HMAC

HMAC-SHA-256 is verified against the exact raw body using constant-time cryptographic verification. User-supplied tenant identity never selects a shared secret.

Replay control

± 5 minutes

Timestamped events outside the accepted clock window are rejected before revalidation.

SSRF boundary

Same public host

URLs are restricted to the registered client hostname, treating its www equivalent as the same host. Off-site targets are rejected.

Batch bound

50 URLs (hard cap)

The ceiling, not the working size. Revalidation is synchronous and sequential, so send one to three URLs per call for a dependable 200 and queue bulk republishes; malformed and empty batches are rejected.

Audit record

Every delivery

Authentication failures and successful events are recorded with tenant, event, payload, signature result, processing status, and error.

Idempotency

Retry safe

Revalidation upserts on the canonical page identity. A retried delivery does not create a second page record.

Content state machine

A change signal is not automatic publication.

The event establishes what changed. Revalidation determines whether the resulting machine representation is safe to write and whether it can remain live.

page.publishedRequests live status, subject to validation and tenant review policy.

page.updatedMaterially changed content enters review.

page.savedTreated as a review-state change.

page.unpublishedStored machine content is retired without fetching origin.

page.deletedStored machine content is retired without fetching origin.

Review-hold logic

Unchanged live content stays live; new or materially changed content does not bypass review.

An existing live page with the same content hash remains live. New or changed content is placed in review where the tenant requires approval. Existing review or retired state is preserved. Notifications are generated only when content actually enters review.

Failure contract

Every response code has an operational meaning.

Read path

Fail open to origin

Unknown crawler identity, failed verification, and supported worker exceptions resolve to the existing human website. Availability takes priority because no machine-layer write occurs.

Write path

Fail closed on integrity

Bad authentication, stale events, off-site targets, empty extraction, soft 404s, or validation regression cannot replace managed content. Integrity takes priority because state would change.

Clean-room revalidation

The public page must pass before its representation can change.

Network bounds

20-second public fetch

Only registered same-host URLs are fetched. Each fetch has a hard timeout and failures are isolated per URL.

Content tripwires

No destructive overwrite

Empty extraction, soft-404 responses, and material markup-density regressions are rejected instead of overwriting a valid page.

Media completeness

Transcript gate

Applies only where a tenant publishes video or audio that carries transcripts; a text-only site never meets this gate. Where a tenant does require manifest-backed media, missing or invalid source-provenanced transcripts block the affected page write.

Version evidence

Comparable artifacts

Content hash, structured data, embedding state, and sanitizer version are stored with the page record for repeatable review.

Availability & decommissioning

The human site does not depend on machine-layer content.

Your origin keeps serving the human website independently of the machine layer.

Because requests to the changed hostname traverse the edge, availability of the hostname also depends on the edge (SO-04, SO-05). Edge fallback, health checks, and route-level rollback are verified for each deployment; update failures leave the last accepted representation intact.

Origin fallback

• Unknown or failed crawler verification routes to origin.
• Supported runtime exceptions are configured to fail open.
• A failed revalidation never takes the human website offline.
• Platform limits and exception cases are recorded in the deployment runbook.

Clean removal

• Disable or remove the edge route.
• Verify direct origin delivery.
• No CMS migration, plugin removal, asset restoration, or publishing rollback.

Governance boundary

Clear ownership at every layer.

Client

Controls the human website, approves the factual source boundary, and authorizes the CDN route and production cutover.

AnswerShare

Builds and operates the managed machine layer, maintains crawler-verification rules, monitors availability, and records release evidence.

Joint control

Defines webhook activation, change approval, incident contacts, rollback authority, review cadence, and production cutover.

This architecture is designed to preserve the client’s existing security and compliance workflow. It is not, by itself, a claim of certification under SOC 2, ISO 27001, HIPAA, or another compliance framework.

Search integrity

Is this cloaking?

The machine layer is not a second offer, a hidden ranking page, or a contradictory version of the business. It is a machine-optimized representation of approved public facts.

Substantive-equivalence rule

Same text as in the Presentation tab, section "Is This Cloaking?": https://proposals.answershare.com/efa83680e8538e264aa420f1d791d6cf/presentation

Same text as in the FAQ tab, section "Is this cloaking?": https://proposals.answershare.com/efa83680e8538e264aa420f1d791d6cf/faq

Material claims must remain faithful to the approved public record. Humans and conventional search crawlers receive the existing website. If the machine layer conflicts with the website’s source-of-truth facts, the conflict is treated as an error and corrected—not as an alternate message.

What the published policies actually say

Every major definition turns on deception and content divergence, not on rendering for a machine. Google defines cloaking as “different content to users and search engines with the intent to manipulate search rankings and mislead users,” and states that where dynamic rendering produces similar content, “Googlebot won’t view dynamic rendering as cloaking.”

Bing calls showing “one piece of content and other visitors a different piece of content” misleading, while treating bot-specific server rendering that preserves the content as “acceptable and not considered cloaking.” Yandex carves out the case where “the layout of the page differs… while the content remains consistent.” The recurring boundary is material content inconsistency used to manipulate ranking — not machine-oriented delivery.

Googlebot never receives the machine layer

Googlebot, Bingbot and every conventional search crawler are classified out of the AI set and pass through to the origin, so the representation Google indexes is the same page a person sees. The policy question is also narrower than it first appears: Google’s spam policies govern participation in Google Search. They do not make Google the authority over what representation a publisher offers an independent AI-inference system such as OpenAI, Anthropic or Perplexity.

Primary technical references

The operating boundaries are inspectable.

Google Search: AI features and your websiteGoogle Search Central ↗ OpenAI crawler roles and published verification rangesOpenAI Developers ↗ Cloudflare Workers routes in front of an existing originCloudflare Docs ↗ Cloudflare Workers execution context and exception behaviourCloudflare Docs ↗ HMAC as keyed message authenticationNIST FIPS 198-1 ↗ Server-side request forgery threat boundaryOWASP ↗

Implementation evidence reviewed for this brief

content-update-webhook — tenant resolution, raw-body HMAC verification, replay window, URL allowlist, delivery logging, internal forwarding, and response-code contract.

clean-room-revalidate — public-page retrieval, tenant authorization, per-URL isolation, review holds, content tripwires, and idempotent page upserts.

edge router — crawler classification, origin passthrough, machine-layer eligibility, exception fallback, and route-level decommissioning.

Control names identify implementation components without exposing secrets, tenant credentials, internal URLs, or security-sensitive configuration values.

Edge cache behaviour

Machine responses are cached, and stale beats absent.

A machine response is cached at the edge under a key separate from the human cache object, and it keeps being served after the freshness window closes while a replacement is fetched behind it. That is deliberate: for a crawler, a slightly old accurate answer is worth more than a timeout.

Served representation

What an eligible crawler actually receives.

The brief describes at length how the machine layer is kept honest. This is what comes back on the read path: a server-rendered HTML document, complete before it leaves the edge, with no client-side rendering step for a crawler to execute and no framework payload to download.

Egress hardening

The address we validated is the address we connect to.

The brief already states that we resolve DNS before dialling and reject private ranges. A reviewer's next question is always the same, so here it is answered in advance: the validated address is pinned for the connection itself, and every redirect hop is re-validated rather than trusted.

Webhook field reference

The exact contract, so your team can build against it.

The brief already shows an example payload. This is the specification an integrator needs instead: every field, every response, and the answer to the question your engineers will actually ask — whether the call blocks.

Processing model

The call is synchronous.

The webhook does not acknowledge first and revalidate later. It fetches and validates your page before it answers, and returns when that work is finished.

Budget for it: the ingress aborts at thirty seconds, each page fetch at twenty, and the URLs in a batch are processed one after another — so a large batch of slow pages can exceed the ingress timeout and return 502 while the work upstream still completes. Send small batches from a background job in your CMS rather than from the request thread that is saving the page. This is the one place where “no change to your publishing workflow” earns a footnote, and this is the footnote.

Adversarial content

Controls that limit how a page edit can reach a model.

The content tripwires described above catch broken pages. This is the different risk that arrives with publishing to machines rather than to people: a page that reads as entirely normal but carries text aimed at the model reading it.

Personal data

Where our boundary starts, and where yours continues.

One distinction is worth stating plainly, because it tends to be assumed in both directions at once.

We represent your public page faithfully. We do not police it.

The machine layer represents the page you have already approved and published. AnswerShare does not detect, redact or filter personal information you have chosen to publish — a staff biography carrying a direct phone number is reproduced as published, because altering it would make the machine layer disagree with your own site. The data-handling and privacy review of your public content remains yours.

Our boundary covers what AnswerShare itself collects, generates and stores beyond that public content: notification payloads, delivery metadata, and derived artefacts such as embeddings. Those exclude credentials, private staging content, proprietary source assets, and sensitive personal information that is not already public on your site.

Appendix

Engineering reference

Dense specification tables. The same controls as above, written for an engineer who wants the exact values.

Key Questions Answered

Terminology Note: HMAC-SHA-256 is symmetric message authentication, not an asymmetric digital signature. The present webhook implementation uses HMAC; cryptographic receipt signing (Ed25519) is a separate evidentiary control.

Control-Plane Summary

Serving Plane: Fail-Open to Origin

Availability-biased. Human visitors, search crawlers, unknown bots, and verification failures pass through to the origin server. If the machine-layer backend fails or returns a non-200 response, or the Worker hits an unhandled error, the request fails open to the origin. A failure of the edge platform itself is not covered by that path; DNS rollback is.

Update Plane: Fail-Closed on Integrity

Integrity-biased. Unsigned, stale, off-site, malformed, empty, or soft-404 updates cannot modify or overwrite the managed machine layer. Updates require valid cryptographic HMAC verification.

CDN & Worker Runtime

The Worker is a narrow router inside the existing CDN request path. It executes before origin is contacted, makes one synchronous in-memory classification decision (<1.5ms), and forwards the request.

Routing Matrix

Webhook Wire Contract & Controls

The webhook provides one-way synchronization from the client CMS to AnswerShare. AnswerShare never establishes an inbound connection to the client network.

Max Batch: 50 URLs · Window: ±5 min POST /functions/v1/content-update-webhook?client=<tenant-slug> HTTP/1.1 Host: api.answershare.com Content-Type: application/json x-geolocus-signature: sha256=<hex HMAC-SHA-256 of exact raw body> { "event_type": "page.updated", "urls": ["https://client.example/public-page"], "timestamp": "2026-09-09T18:00:00Z", "status": "review" }

SSRF & DNS Rebinding Defenses

Target URLs are strictly restricted to registered client hostnames. The revalidation engine performs pre-socket DNS resolution and validates the IP against RFC 1918, loopback (127.0.0.1), and cloud metadata (169.254.169.254) blocks before dialing. Manual redirect handling intercepts off-site or non-standard port hops.

Replay & Rate Controls

Timestamps deviating by more than ±5 minutes are rejected immediately. Inbound payloads are restricted to a maximum of 50 URLs per batch, and tenant-level outbound concurrency is throttled to prevent resource exhaustion against the client's origin server. Fifty is the hard ceiling, not the working size: revalidation is synchronous and sequential at up to 20 seconds per URL inside a 30-second ingress timeout, so send one to three URLs per call and queue bulk republishes.

Content State Machine

A webhook notification signals revalidation; it does not trigger automatic publication.

Failure Contract

Governance, Compliance & Rollback

Governance & Audit Trail

The client controls the origin website, factual boundaries, and CDN route cutover. Each webhook delivery is recorded with its event type, target URL, notification payload, signature result and processing outcome; that update-path log holds no request headers and no source IP.

The serving path is deliberately different: every eligible AI-crawler request is recorded with its source IP, bot classification and time to last byte, because that crawl record is the measurement being bought — it shows which declared agents requested which pages, and when.

Those are self-declared requests, not verified providers, and a request is not a citation.

Page representations and their vectors are held per tenant for as long as the tenant is active. Retention periods and the deletion schedule on termination are set in the contract — ask for them in writing rather than inferring them from this page.

Route-Level Decommissioning

Removal requires only disabling the route rule in the CDN dashboard, or restoring the DNS value recorded before the change, depending on which path is in use. Disabling a route stops edge execution for that route at once. Restoring the recorded DNS value returns traffic to the previous path as DNS caches expire, which is not instantaneous and not identical at every resolver (SO-05). Neither requires CMS database rollbacks or code purges.

AnswerShare Architecture & Security Brief · Enterprise Engineering Review · October 2026

Operating boundaries are inspectable and verifiable.

ANSWERSHARE ARCHITECTURE & SECURITY BRIEF · OCTOBER 2026 · NOT A CERTIFICATION STATEMENT

Next: Part 7 of 7 — Evidence https://proposals.answershare.com/efa83680e8538e264aa420f1d791d6cf/evidence

End of the Technical tab of the Texas First Rentals proposal (31 sections).