Pulse

Product

Personalise the Storefront

For AI Agents

Industries

By Goal

Resources

DevelopersPricingOpensourceSign InRequest a Decision Audit

Opensource

Teach software and AI agents what evidence a decision needs.

Product data was built for databases, feeds and storefronts. An AI agent needs more: what the buyer is trying to decide, what evidence that takes, what the product actually shows, and what is still unresolved. Open Pulse is the open foundation for that layer. The Pulse API is the decision engine behind it.

Explore Open Pulse on GitHubRead the developer docs

MIT licensed. For developers, merchants, researchers and AI agents, in any industry where options have attributes.

Commerce has plenty of product data. It has very little decision data.

What a catalogue knows

  • Title
  • Brand
  • Price
  • Colour
  • Category
  • Description
  • Images

What a buyer is trying to answer

  • “Will this sofa fit through my doorway?”
  • “Is this charger compatible with my laptop?”
  • “Will this laptop handle video editing?”
  • “What is actually in the box?”
  • “Is the warranty valid where I live?”

Those are decision requirements, not search queries. When the evidence for one is missing, buried or contradictory, neither a shopper nor an agent can resolve the decision.

A product record says what is stored. Decision evidence says what can be decided.

  1. 01

    Requirement

    What needs to be known.

  2. 02

    Product evidence

    The facts recorded, and where each came from.

  3. 03

    Visible evidence

    What a shopper or an agent can actually see.

  4. 04

    Decision

    Whether the evidence is enough.

  5. 05

    Outcome

    What happened afterwards.

A product can have data and still have an evidence problem: a fact in the supplier feed that never reaches the page, a specification stated twice with two values, a photograph that hides the feature that matters.

On our own 2,176-product demonstration catalogue, 52.6% of recorded values repeat what the photograph already shows. See the research →

An agent should be able to say “the evidence does not say”.

Language models are built to answer. Pulse gives them a third answer besides yes and no, grounded in what each option actually states.

Shopper

Will this sofa fit through my 78 cm doorway?

Agent

The listing gives the assembled width, but not the package width, so I can't confirm it fits through the door. The seller would need to publish the package size.

POST /decideAvailable now
requirement  width <= 300 cm          meets
requirement  package_width <= 78 cm   unknown
verdict      cannot_tell
missing      package_width

POST /decide and the MCP tool resolve_products return meets, fails, unknown or conflicting for each requirement, and fits, fails or cannot_tell overall.

Abstention is a feature.

Most product systems are built to return something. A decision system sometimes has to return: not enough evidence.

If the package size is not recorded, an agent should not infer from the assembled width that a sofa fits through a door. If two sources disagree about capacity, the conflict stays visible until someone resolves it.

AI may improve the presentation. It must not invent the product.

AI can help

  • Restructure verified specifications
  • Summarise verified evidence
  • Draw diagrams from verified dimensions
  • Explain why the evidence supports a decision

It must never invent

  • Dimensions or capacity
  • Materials or certifications
  • Compatibility
  • What is in the box, or warranty terms

Generate presentation. Never generate an unverified product fact.

Name the evidence problem precisely.

Planned, as part of the shared evidence formats. Six states say more than calling every problem missing data.

  • Missing

    Planned

    The evidence is not recorded.

  • Buried

    Planned

    It exists, but is hard for a shopper or agent to find.

  • Invisible

    Planned

    It is known internally, but not shown where the decision is made.

  • Unresolved

    Planned

    Some information exists, but not enough to answer.

  • Conflicting

    Planned

    The sources disagree.

  • Not observable

    Planned

    The available evidence cannot answer it.

Describe the repair the same way.

Planned, alongside the evidence states. Eight verbs cover what can be done about a gap.

  • Record

    Capture a missing fact.

  • Show

    Expose evidence that already exists.

  • Reconcile

    Resolve sources that disagree.

  • Generate

    Present verified evidence better.

  • Ask

    Request it from the merchant, supplier or buyer.

  • Compute

    Derive it safely from verified inputs.

  • Abstain

    Do not answer without evidence.

  • Don't fix

    Accept that some gaps are not worth fixing.

The last two matter most. A trustworthy system has to be able to say "I don't know", and a sensible one has to be able to say "this is not worth fixing".

Open where sharing helps. Paid where outcomes create the value.

Open Pulse

  • Browser SDK, @thepulseapi/sdk 0.2.0Available now
  • MCP server for AI agents, @thepulseapi/mcp 0.2.0Available now
  • Runnable examples and the agent guideAvailable now
  • Requirement and evidence formatsPlanned
  • Evidence states and repair vocabularyPlanned
  • Category packsPlanned
  • Validators and connectors for platforms and PIMsPlanned
  • Query parser and return-reason taxonomyPlanned

Pulse

  • Decision Audit: which gap matters most
  • Repair prioritisation and its economics
  • Decision Verification: did the repair change anything
  • Decision Monitor: did the evidence stay healthy
  • Return Verification and Promotion Audit
  • The Decision API in production
  • Learning from measured outcomes

Open Pulse describes the evidence. Pulse decides what is worth doing about it.

Teach the ecosystem how people decide in your category.

Planned. A category pack lists the requirements that matter for a kind of product and the evidence each one needs. A laptop, a sofa and a power adapter should not share one model.

category-pack.yamlIllustrative
category: furniture.sofa
requirements:
  - id: delivery_clearance
    question: "Can it reach the room?"
    evidence: [package_width, package_height, removable_legs]
  - id: room_fit
    question: "Will it fit in the room?"
    evidence: [width, depth, height]

A good pack answers

  1. What do buyers commonly decide?
  2. What evidence does each decision need, and which is mandatory?
  3. Where could that evidence come from, and can it be shown or computed?
  4. What should happen when it is not available?

You do not need to work on machine learning to contribute.

Useful contributions include:

  • Add a requirement

    A real buying question a category is missing.

  • Improve the agent tooling

    Help agents query and read evidence safely.

  • Add a connector

    Map a platform, PIM or feed into Open Pulse.

  • Add examples

    Synthetic or safely shareable cases.

  • Improve the docs

    For developers, merchants and specialists.

  • Report a wrong model

    "This is not how buyers choose this product" is a useful issue.

Domain experts are contributors too.

Someone who knows furniture, electronics, beauty or industrial parts may know more about the evidence a decision needs than the people writing the software. If you know the questions buyers keep asking, you can teach the ecosystem how that category is decided.

AI agents can propose, with review.

An agent meets unanswered questions at scale. When one finds a requirement no model covers, it can propose it. People review it before it changes anything.

  1. A buyer asks
  2. The agent tries to decide
  3. A missing requirement turns up
  4. The agent proposes it
  5. People review it
  6. The open knowledge improves

Open an issue on GitHub first. Contribution terms are being finalised, and we will publish them before accepting larger changes.

Who Open Pulse is for

  • Commerce developers

    Storefronts, PIM workflows and catalogue tools that understand decision evidence.

  • AI agent developers

    Structured evidence, and a safe way to say what is unknown.

  • Merchants and marketplaces

    Product data quality judged by decisions, not by full fields.

  • PIM and catalogue teams

    From "is the field filled?" to "can this evidence resolve the decision?"

  • Researchers

    Buying requirements and evidence coverage, in reproducible structures.

  • Domain experts

    The knowledge of what evidence matters in a category.

What Open Pulse is not

  • A recommendation engine
  • A product description or product fact generator
  • A replacement for a PIM
  • A cart, a payment protocol or a marketplace
  • A promise that every missing field matters
  • A system that answers when the evidence is not enough

More product data is not automatically better product data. The goal is evidence that resolves real decisions.

Our open-source principles

  1. 01Evidence before answers. Know what supports a claim before presenting it as fact.
  2. 02Provenance matters. Where evidence came from stays inspectable.
  3. 03Abstention is valid. Not enough evidence beats a confident invention.
  4. 04Requirements before completeness. A field matters because a decision needs it.
  5. 05Negative results belong in the record. Failed experiments are information.
  6. 06People stay in the loop. Agents can propose; people review.
  7. 07Open formats for interoperability. Evidence understandable across systems, not locked into Pulse.

Questions about Open Pulse

What is decision evidence?

The facts a buyer needs to make a specific decision, together with where each fact came from and whether the buyer can actually see it. Product data says what is stored; decision evidence says what can be decided.

Is Open Pulse the same as Pulse?

No. Open Pulse is the open foundation: the SDK, the MCP server, examples, and as they are released, shared formats and category knowledge. Pulse is the paid platform that measures, prioritises, verifies and monitors, and runs the Decision API.

Can AI agents use Open Pulse?

Yes. The MCP server is available now: with an API key, an agent can ask which options meet a buyer's requirements and get fits, fails or cannot tell, with what is missing. Without a key, it can search our documentation.

Can I use Open Pulse without the Pulse API?

The SDK and the MCP server are MIT licensed and you can read, change and ship them. The decisions themselves come from the Pulse API, which needs a key. Planned formats and category packs will be usable on their own.

Does Open Pulse generate missing product information?

No. It never invents unverified facts. Missing dimensions, materials, compatibility, certifications or warranty terms stay unresolved until a trustworthy source provides them.

Is Open Pulse a PIM?

No. A PIM stores product information. Open Pulse is about the link between buying requirements and the evidence that resolves them, so it complements a PIM.

What is a category pack?

A planned format that lists the requirements that matter for one kind of product and the evidence each needs. Domain experts will be able to improve them through GitHub.

Why include "don't fix"?

Because not every gap deserves engineering time or content spend. Open Pulse can describe a gap; Pulse helps decide whether fixing it is worth the cost.

Help build the evidence layer for AI commerce.

Agents can search faster and compare more products than any person. They still need reliable evidence to know whether a product really meets the decision in front of them. That foundation should be open.

Explore Open Pulse on GitHubPropose a category requirementRun a free Decision Audit

Open the language. Share the knowledge. Measure what matters.