ObjectCanon

An open experiment about physical objects

Objects have stories.

They're created, bought, sold, repaired, modified, appraised, inherited and passed from one person to another.

Each encounter can leave a receipt, listing, service record, appraisal, photograph, owner's note or database entry. Those records live in different places, may describe the same object differently, and weren't designed to work together.

ObjectCanon explores how software can work with those accounts without pretending they always agree.

Explore the ideaExplore the API

One object · different accounts

Disputed

Loading…

Loading claim…

Also claimed

Loading…

Loading claim…

One object. More than one account. Neither description is treated as the final answer. Synthetic example.

The basic problem

Software likes one answer. Objects don't always have one.

“Original pickups.” Seller

“Bridge pickup replaced in 1987.” Repair record

“All original.” Old dealer listing

“All original.” Three later listings repeat the description

Traditional software often has to put one value in a field: Original pickups: Yes. But repeating a description does not settle a disagreement.

ObjectCanon takes a different approach. It keeps the individual accounts, their sources, and the disagreement visible.

Sometimes the useful result is Pickup originality: disputed

That matters when software and AI agents are asked not just to search, but to compare, recommend, evaluate, insure, buy, sell or act on information about an object.

Illustrative accounts, not records in the public synthetic dataset.

Where information originates

So where does the information come from?

ObjectCanon doesn't magically know an object's history or discover everything ever said about it. A record can begin because someone is already doing something with the object.

Owner catalogs a watch, adding photographs, reference numbers and purchase details.

Dealer takes a guitar into inventory and records its description and serial number.

Repair shop services a camera and records what was repaired or replaced.

Appraiser examines furniture and records an opinion about age, maker or condition.

Insurer schedules an object and records identifying information and valuation documents.

Manufacturers, marketplaces, auction houses and other systems create records too. Each interaction can leave information behind.

Where accounts are made available, the ObjectCanon model offers a common way to represent what those sources say, retain where it came from, and show agreement or conflict. The current public service does not collect these real-world records.

A record doesn't have to be complete to begin.

One source is one sourced account. More information can accumulate as an object is repaired, appraised, listed, sold, insured or inherited. The number of sources alone does not make an account true.

An object's history

One object. Many moments. Many records.

Imagine one guitar passing through different hands. Each encounter leaves a piece of its story.

  1. An owner buys a Fender Stratocaster.

  2. A repair shop records replacement of the bridge pickup.

  3. A dealer lists the guitar as “all original.”

  4. Another sales record repeats the “all original” description.

  5. A seller offers an “all-original 1975 Stratocaster.”

Those records arose because people were buying, repairing, cataloging and selling the guitar—not because ObjectCanon went looking for them. If made available to a system using the model, each account could remain visible instead of being collapsed into a single field.

Pickup originality DISPUTED

Original pickups Seller description

Bridge pickup replaced 1987 repair record

“All original” 2004 dealer listing

No account is automatically correct.

Illustrative timeline, not a real guitar or a record in the current dataset.

The hard parts

The hard parts aren't the database.

Storing claims isn't particularly difficult. The harder questions are:

01 · ORIGIN

Where does useful information come from?

Real records begin with owners, makers, dealers, repair systems, appraisers, insurers and other applications.

02 · IDENTITY

Which physical object is this?

A model name isn't an identity. Neither is a search result.

03 · LINEAGE

Are sources actually independent?

Five descriptions may repeat one earlier assertion rather than represent five observations.

ObjectCanon does not claim to have solved all of these problems. The public experiment asks a narrower question:

Once multiple accounts exist, can software preserve their provenance and disagreement in a predictable, machine-readable way?

Physical identity

First, you have to know which thing you're talking about.

“1975 Fender Stratocaster” describes a kind of object, not one particular guitar.

Depending on the situation, establishing physical identity might involve serial numbers, photographs, ownership records, service history, tags, physical inspection or continuity of custody.

ObjectCanon does not currently provide a universal method for proving physical identity. Its lookup tools can help identify candidate records.

A candidate match is not proof that a record describes the physical object in front of you.

Information lineage

Five sources don't necessarily mean five independent accounts.

Suppose five marketplace listings describe a guitar as having its original pickups. That sounds like strong agreement.

But what if four copied their descriptions from the same earlier listing?

“Original pickups” Earlier listing

“Original pickups” × 4 Later listings repeating that description

That may be one assertion repeated five times, not five independent observations. Understanding how descriptions move between systems matters.

ObjectCanon currently preserves recorded source provenance. Deeper information-lineage and source-dependency analysis—including detecting copied descriptions—is an area of exploration, not a capability of the public experiment.

Judgment stays with you

Why doesn't ObjectCanon just decide who's right?

Because a source's usefulness depends on the question being asked.

A manufacturer's production record may establish when something was made, but not its current condition.

A recent appraiser may assess condition without knowing what happened thirty years earlier.

A repair record may document one modification without establishing the history of the rest of the object.

These sources are not equally useful for every purpose. ObjectCanon does not assign them a universal truth score. It retains recorded source, timing, supporting information and disagreement so the person, agent or application making a decision can use rules appropriate to the situation.

The wider picture

Information is made elsewhere. ObjectCanon works with the accounts.

Information is created

Owners · manufacturers · dealers · repairers · appraisers · insurers · marketplaces

Object records accumulate

Identity information · observations · documents · events · sources · provenance

ObjectCanon's model

Keep accounts and sources separate · expose agreement and disagreement · return reproducible results

People, software and agents

Search · evaluate · compare · insure · repair · buy · sell · transfer · decide

ObjectCanon is not meant to replace the systems that create object information—or require every organization to put its data in one central database. It explores how software can use accounts from those systems without erasing uncertainty. Downstream applications decide what to do; ObjectCanon does not take those actions itself.

The public experiment

What exists today

ObjectCanon is currently a public experiment with 53 fully synthetic physical-object records across musical instruments, watches and furniture. None are production object records.

Its object records are read-only. You can explore recorded claims and sources, see agreement, disagreement or missing information, and inspect a deterministic resolution receipt. This shows how software or an AI agent might handle conflicting accounts after information has already been assembled.

What it does not do

It does not crawl the web for object history, create records from real-world encounters, authenticate objects, provide appraisals, determine objective truth or prove a physical object matches a record. It does not detect when apparently separate sources copied one another.

What can software do with accounts that disagree—without silently turning them into certainty?

Where this is headed

The next questions are harder.

The current experiment asks whether software can work more carefully with conflicting information about physical things. Beyond it lie larger questions:

How do useful object records get created naturally?

How does information accumulate as an object moves through the world?

How can continuity of physical identity be established?

How can independent observations be distinguished from repeated descriptions?

How should different applications interpret the same evidence for different purposes?

And what becomes possible when people and AI agents can ask questions of those records?

That's where ObjectCanon is headed.

Explore the experiment

One guitar. Different accounts.

A synthetic Telecaster from the bundled ObjectCanon dataset. These values come from its generated receipt.

Loading record…
Loading the bundled example…

When accounts disagree, the disagreement remains visible.

Inspect the full JSON receipt

        
Synthetic reference data, not a real guitar or a verified physical identity.

      

    

  


  

    

      
For developers ↓

      

        
Underneath, it's deliberately small.

        
An object record contains attributable claims. The resolver applies the published disputed_v1 policy. A receipt reports agreement, disagreement or unknown information, with the claim IDs and alternatives involved. It also carries a schema version, resolver version and dataset fingerprint.

        
object → claims → resolve → receipt

        
Same input + same rules = same result. A dataset fingerprint identifies a revision; to replay it, you need the matching source checkout and version. Candidate lookup is discovery, never verification of physical identity.

        
Inspect the actual generated response for the synthetic guitar above, including its full JSON receipt.

        
Explore the APIMCP docsWhy I built thisView GitHub

      

    

  


  

    

      
Try it

      

        
Don't take our word for it.

        

          
Curious?
Explore an object
Start with the synthetic guitar example. Open its full receipt to see the underlying accounts.

          
Building software?
Connect to ObjectCanon
Read the MCP documentation or use the working endpoint below.

        

        
Connection endpoint (Streamable HTTP): https://mcp.objectcanon.com/mcp

        

          
          
          
          
        

        
Run this command in your terminal.

        
Save as .cursor/mcp.json.

        
Add as a custom connector in Settings → Connectors using this URL:
Or via claude_desktop_config.json:

        
Streamable HTTP endpoint:
  • about — identify the build, dataset, and policy.
  • types — discover object types and attributes.
  • lookup — find candidate records, not verified identities.
  • resolve — inspect statuses, alternatives and retained claims.
  • submit_feedback — report a problem without changing object records.

        
API Reference · MCP · Specification · GitHub

      

    

  


  

    

      
Notes

      

        
Why I built ObjectCanon

        
I love used and vintage guitars, and spend more time than I should browsing Reverb, eBay, Facebook Marketplace and local listings. Finding the good stuff takes time, so I thought: I’ll build an agent to do it for me.

        
That immediately raised a harder question: how does an agent figure out what an object actually is when the information it finds is incomplete, inconsistent or just wrong?

        
That was the motivation for ObjectCanon.

        
I wanted to give an agent somewhere to check what it finds, see the evidence behind it, and, importantly, be allowed to say “this is disputed” or “I don’t know” rather than manufacture a confident answer.

        
Used guitars are just where I happened to encounter the problem. The same problem exists across used goods markets, where identity, condition, provenance and history can matter.

        
ObjectCanon is my experiment to see whether there’s a useful way to make that process more transparent and trustworthy.

        
It’s early. Try it, break it, and tell me what you think.

      

    

  


  

    
Feedback
Tell us what you’re building
Found a bug, got confused, or have a use case? Call submit_feedback from an MCP client, or email feedback@objectcanon.com.