Internet Search Capability

@DJJones

Internet Search V1 — technical rulings needed for Eval Pack

Dave J, Dave W has completed the product-facing review for the Internet Search V1 evaluation package. We need your confirmation on the following implementation and platform items before we can version-update the contract, evaluation plan, and kit for final independent review.

  1. Host capability admission
    Please confirm that the App Host will admit web.search@1 and web.read@1, including grants, limits, receipts, and provider-profile enforcement. Should the Shared App Contract annex define these now, or should we temporarily adopt the Internet Search capability contract as the frozen authority?

  2. Operating-envelope enforcement
    Please confirm that the Host can enforce the accepted per-run limits: five searches, ten results per search, thirty unique results, ten page-read attempts, 128 KiB per normalized page, twenty seconds per operation, two minutes per run, two concurrent requests, two new requests per second, one bounded retry, three redirects, and two controlled query adaptations.
    For BrainDrive-managed service, please also identify the Billing rate-table and lifecycle authority needed to implement reservation, charging, and release of unused value.

  3. Privacy, storage, and deletion mechanics
    The accepted policy retains no raw page content. Query text and canonical URLs may appear only in the owner’s private execution receipt, retained for thirty days by default and deletable sooner. Restricted diagnostics retain content-free operational metadata for thirty days; Billing remains metadata-only.
    Please confirm feasibility and define the storage locations, access controls, redaction, deletion behavior, and formal-evaluation evidence handling.

  4. Disclosure and consent records
    Please confirm the Host can maintain versioned provider disclosures, consent records, ninety-day currency checks, immediate invalidation after known material changes, and an auditable join from each execution receipt to the disclosure version that governed it. A material disclosure change requires fresh owner consent.

  5. Three-surface qualification
    Please identify the exact candidate builds and confirm the environments, drivers, evidence-capture paths, and parity inventories for:

    • Docker through the production web client
    • Native macOS desktop
    • Native Windows desktop

    Each surface qualifies independently; missing tooling blocks that surface rather than narrowing the V1 claim.

  6. Shared receipt lifecycle
    Please confirm the common lifecycle and identifiers joining capability operations, owner-initiated runs, execution receipts, and optional Billing entries, including ownership, replay behavior, redaction, retention, viewing, and export.

  7. Build Gate
    Please confirm or revise the Build Gate rules, commands, runner, and evidence record that must pass for the exact candidate before formal product evaluation begins.

Once these are resolved, we’ll update the Internet Search contract, plan, fixtures, and kit as one coordinated versioned change, rerun independent review, and prepare the BrainDrive Docs pull request for Dave W’s review.

Reference documents:

@djjones Quick heads-up from my re-review of Internet Search for submission to BrainDrive-Docs. This is a consolidation of the product contract, not my first review or a change to the current V1 goal. The Docs acceptance PR is open for docs/foundation/internet-search/internet-search-spec.md.

Job Discovery remains the only V1 consumer. web.search and web.read should stay consumer-neutral so future Apps, Pages, or Your Agent can adopt them without redesigning the capability. V1 still does not add general search to chat.

The two setup paths are now explicit:

  • owner-managed key or endpoint, including a local or self-hosted service, ships first;
  • BrainDrive-managed Search through BrainDrive Models follows the separate Billing work.

The operating limits, privacy and retention rules, disclosures, receipts, and platform qualification requirements are unchanged from the items already posted above. The main checks for the current build are that it is not coupled to Job Discovery or one provider, supports an owner-managed endpoint and test search, and preserves those existing host boundaries.

If the build already follows that shape, I expect documentation alignment and confirmation rather than a redesign. Please flag anything here that conflicts with what you have built.