Brdg Agentic Commerce

Showing 25 of 89 from the live probe.

• Get BRDG Product Vision

  Returns BRDG's agentic commerce thesis, loop, and rejected product directions.

• Get BRDG Feature Map

  Returns the developer, merchant, storefront runtime, worker, analytics, and MCP surface map.

• Get BRDG Runtime Architecture

  Returns the storefront-runtime integration guide an agent needs to build a CORRECT surface: design authoring and brand publication boundaries, the render modes (pre-paint applier, free-tier server claim, watcher, preview), how the per-shop plan document is built and applied with no per-visitor server call, the launch-time and plan-time gates, what drift does, and how every failure mode lands on the merchant's own content. Read it with brdg_get_design_system BEFORE you scaffold, so the section's

• Get Example BRDG Resources

  Returns example BrandProfile, CatalogResource, StrategyBrief, BehavioralConfidence, and capability primitive resources. This does not return shop data.

• List BRDG Contract Schemas

  Lists BRDG Agent API and MCP contract schemas with canonical examples, including headless shopperChat v1 request/response contracts, signed Shopify app-proxy routing, explicit AI opt-in, context limits and interface-building guidance. Shopper traffic uses the runtime HTTP endpoint, never MCP. Also includes the consent-gated ToolManifest.submission contract, declared encrypted request fields, compatible Shopify metaobject mapping, and regional-delivery rules.

• Get BRDG Contract Schema

  Returns one contract schema by name.

• Validate theme surface

  Validates one brdg_theme_surface_v1 declaration — the contract a BRDG-adaptive surface in a Shopify theme declares about itself: which templates it appears on, the section file that owns it, whether it varies by props/layout/section_swap, the props it accepts, and the events it emits. This declaration describes SHAPE ONLY. It rejects unknown fields, and it rejects authority fields (scopes, consent, safety, entitlement, guardrails) outright — a theme file is merchant-writable, so anything that ch

• Validate theme build package

  Validates an exact theme_build_package_v1 proposal: isolated candidate, baseline file hashes, intended file operations, surface declaration and review/rollback instructions. Stateless and unscoped. A valid package grants no approval, publication or experiment authority. Save it as a custom_context delivery artifact revision; subsequent builds require parentRevisionId.

• Scaffold a theme surface

  Generates the exact theme files to make a BRDG-adaptive surface real: the Shopify section, the inline pre-paint applier snippet, the assets/brdg.surfaces.json declaration, AND the measurement code for every event you declare in `emits`. MEASUREMENT IS GENERATED, NOT LEFT TO YOU. A `_view`/`_viewed`/`_seen` event is wired to the surface entering the viewport, which needs no element at all. A `_click`/`_cta` event is wired to the element your EVENT NAME names (`hero_primary_action_click` binds el

• Register theme surface

  Registers a validated brdg_theme_surface_v1 declaration with BRDG so experiments can target it. This creates a governed registration, not launch approval: BRDG will not run an experiment against a surface it has no governed record of, no matter what the theme file says. Call it AFTER `shopify theme push` lands the files. The surface registers as `registered_unverified` — only BRDG's read-only scan of the published theme can promote it to `registered_verified`, and only `registered_verified` gate

• List theme surfaces

  Returns every registered theme surface for the shop, and `shopDomain` — the myshopify domain to pass as `shopify theme push --store`. This is the ONLY read that carries it: the scaffold tool is unscoped and stateless, so it cannot know which store it is generating for. `shopDomain` is null when BRDG does not know the domain; it is never omitted, so an absent answer is distinguishable from a missing field. Each surface carries its verification state — registered_verified | registered_unverified |

• Verify theme surfaces now

  With target:published (default), force the published-theme scan and reconcile registered surfaces. With target:candidate, require artifactId, revisionId and contentHash of the exact current ThemeBuildPackageV1 revision; independently read its unpublished candidate and published baseline files. Candidate verification never changes ThemeSurface, experiments, or the live plan and grants no authority. It checks complete paginated asset inventories and requires every difference to be declared, then v

• Validate theme submission profile

  Validates a submission contract for a theme-native form — the declaration that says which fields the form accepts, how they map to Shopify customer fields, metafields and metaobjects, how routing picks a destination team, and which consent each purpose requires. This is the SAME validator the runtime re-runs on every submission, so a definition that passes here is one the runtime can interpret. Validate before registering. The contract needs no tool_id and no exposure_key: on this lane a submiss

• Register theme submission profile

  Registers the submission contract bound to one registered theme surface, so a form in the merchant's own theme can post to /api/v1/submissions with nothing on BRDG's side to host. The surface must already be registered (brdg_register_theme_surface); it need not be verified, because verification gates experiment launches and not form submissions. BRDG stores the NORMALIZED contract server-side — the theme never carries field maps, routing or consent rules, because a theme file is merchant-writabl

• List theme submission profiles

  Returns every registered submission profile for the shop: its surfaceKey, status (pending | active | revoked), its active definition and hash, activeRevisionId, pendingRevisionId, pendingProposalId and the pending definition/hash. pendingReviewHash is the exact metadata-review identity. pendingReviewStatus and pendingReviewFeedback explain decisions or requested changes; revise the definition and register again to answer feedback. pendingProposalId is present only for a still-pending review. Ope

• Revoke theme submission profile

  Stops the theme-native lane accepting submissions for one surface, immediately. A lifecycle flag, never a delete — StorefrontSubmission rows reference the profile with onDelete: Restrict, because the receipts are the evidence of what was collected under which contract and must outlive it. Revocation also stops queued effects that have not begun dispatch. An external operation already in flight may finish. Re-registering only stages a new revision; individual brand approval is required to reactiv

• Validate theme surfaces file

  Validates a whole assets/brdg.surfaces.json document (schemaVersion brdg_theme_surfaces_v1 plus a surfaces array). Use this on the file you are about to write into the theme; it additionally catches duplicate surfaceKeys and the per-theme surface cap.

• Validate JourneyGraph

  Validates a guided journey graph for node references, transitions, cycles, and step limits. NODES ARE `surface`, NOT `tool`. A node carries `surface:{layout, section, props}` and renders on THE EXPERIMENT'S OWN bound surface — it carries NO surfaceKey, and one is refused, because a node that could name its own surface would let this journey redraw a surface another experiment owns. Vary the same declared props an arm varies; a prop the surface never declared is refused at write time and is invi

• Validate OutcomeEvent

  Validates an OutcomeEvent, optionally against a ToolManifest event taxonomy. Use exactly one attribution owner: experiment_id + variant_id for experiment traffic, or deployment_id + decision_source=deployment for always-on operational traffic. Never invent empty experiment ids for a deployment.

• Validate ExperimentProposal

  Validates a hypothesis, audience, metric, primitive, and generation-requirement proposal.

• Validate BRDG Resource

  Validates BrandProfile, CatalogResource, StrategyBrief, or BehavioralConfidence resource payloads.

• Read intelligence evidence

  Read current revision by kind+subjectKey; or Meta campaign inventory, exact campaign baseline, dated Insights (maximum 31 days, latest 100 rows, hasMore explicit), or operation receipt. Actions current/meta_campaigns/meta_campaign/meta_insights/meta_receipt. Requires enabled shop shadow program. Private evidence is not a shopper payload; platform attribution is not causal lift.

• List Experiments

  Returns this shop's experiments with variants, status, and traffic. Requires experiments:read.

• Get Experiment

  Returns one exact experiment with its editable pre-launch metadata, canonical control/treatment content overrides, locations, status, and traffic. Use this before update/remove/delete calls so confirmations and variant ids are current. Requires experiments:read.

• Get Experiment Readiness

  Runs the same read-only merchant launch/resume readiness evaluation, including moment ownership and launch-gate blockers. It never changes lifecycle state. CATALOG BLOCKERS SPEAK IN COUNTS, NOT ADJECTIVES, because "catalog truth is missing" is not something you can act on. An arm binding `fact.<key>` is checked against the products the experiment can actually run on: `catalog_missing` blocks and says "0 of 1,248 products carry an approved, customer-facing value for the catalog fact care_level,