Observed ≠ Resolved: Why an AI Service Listing Is Not Yet a Canonical Machine Contract

Direct answer

An AI-agent marketplace listing can contain useful commercial and technical evidence without containing enough information to establish a canonical executable service identity.

Atinamos observed this while building marketplace ingestion for x402.jobs on 24 August 2026. In a controlled sample of 10 listings, five could be associated with an existing canonical Atinamos service record using evidence already available to us. Five could not be safely resolved because the HTTP method was not disclosed in the marketplace data we inspected and there was no unique existing endpoint identity that allowed a method-preserving association.

Atinamos did not infer GET or POST to make those records fit the database. We retained them as observed-but-unresolved marketplace listings instead.

This is a narrow identity finding from a small controlled sample. It does not establish that half of x402.jobs is incomplete, that x402.jobs is defective, or that the same proportion applies to any other marketplace. A full x402.jobs catalogue harvest was still in progress when this page was published.

Evidence header

• Research question: When does a marketplace listing contain enough evidence to identify a canonical executable machine service?
• Evidence status: Direct observation plus Atinamos implementation response
• Observation date: 24 August 2026
• Controlled sample size: 10 x402.jobs listings
• Marketplace: x402.jobs
• Identity rule used by Atinamos: endpoint + HTTP method
• Evidence source: public x402.jobs catalogue/detail records, existing Atinamos marketplace records and controlled database-ingestion tests
• Commercial relationship: Atinamos is developing commercial machine-service verification and marketplace tooling. Atinamos Render Check is also listed on x402.jobs.

Why service identity needs more than a URL

For Atinamos, a canonical executable service is identified by at least:

endpoint + HTTP method

The distinction is necessary because the same endpoint can legitimately expose different behaviour under different methods.

During earlier marketplace ingestion, Atinamos observed records where one endpoint appeared separately as GET and POST. Examples in the existing dataset included Coinbase Bazaar listings where the same URL was associated with different HTTP methods and therefore mapped to different canonical service records.

That means this is unsafe:

https://example.com/api/task = one service

A more defensible identity is:

GET  https://example.com/api/task
POST https://example.com/api/task

Those may be two different executable contracts even though the URL string is identical.

What we tested with x402.jobs

Atinamos built a harvester using the public x402.jobs catalogue and per-resource detail records. The harvester retained marketplace-provided fields including endpoint, price amount, asset, network, payment recipient, provider metadata, category, schemas, health and marketplace reputation where present.

For the controlled test, Atinamos processed 10 listings before attempting the full catalogue.

The identity logic was deliberately conservative:

1. If the marketplace supplied an explicit HTTP method, resolve using endpoint + method.
2. If no method was supplied, associate the listing only when exactly one existing canonical Atinamos service already used that endpoint.
3. If the method was absent and the endpoint could not be uniquely associated, retain the listing as unresolved rather than inventing a method.

What we directly observed

The controlled 10-record run produced:

Examples among the safely associated records included Atinamos Render Check, Agent Readiness Audit, a Hyperextend endpoint, a JustaName endpoint and a SiteSignal service for which a unique existing endpoint record allowed association without inventing a second method.

Examples among the unresolved records included several SiteSignal resources where the marketplace record exposed the endpoint but did not expose an HTTP method in the fields inspected. Atinamos found no explicit method in the relevant output_schema, proxy_method, input_types or additional metadata inspected for those records.

The unresolved state therefore meant:

Atinamos observed the marketplace listing, but did not hold enough evidence to establish which endpoint + method canonical service it represented.

It did not mean the service was unavailable, invalid, unsafe or incorrectly listed.

Preserving evidence without manufacturing identity

Discarding the unresolved records would have lost useful marketplace evidence. Guessing a method would have created stronger data than the observation supported.

Atinamos therefore introduced a separate evidence state:

Marketplace listing observed
        ↓
Canonical identity sufficiently evidenced?
        ├── yes → resolved service source
        └── no  → unresolved source listing

An unresolved listing can still retain:

• marketplace and listing identity;
• discovered endpoint;
• description;
• price and payment metadata;
• provider metadata;
• category and tags;
• schema evidence where present;
• health and marketplace reputation fields;
• raw, sanitised marketplace evidence;
• first-seen and last-seen timestamps;
• immutable material-change history.

The missing method remains missing.

Controlled history test

Atinamos also tested whether an unresolved listing could be observed repeatedly without generating duplicate history.

One x402.jobs SiteSignal Wikipedia Summary listing was ingested twice without any material marketplace change.

The first pass created:

• one unresolved source listing;
• one immutable observation;
• method = None.

The immediate second pass produced:

• no additional unresolved source row;
• no duplicate immutable observation;
• method still unresolved.

A subsequent 10-record repeat also produced zero new observations when the material state had not changed.

This showed that unresolved evidence could be retained longitudinally without forcing it into the canonical service table and without creating history merely because the harvester ran again.

What we infer from the observation

The evidence supports a broader design principle for machine-service intelligence:

Observation and resolution are different evidence states.

A marketplace can be a valid source of evidence even when the evidence it exposes is insufficient for another system's canonical identity requirements.

This matters for autonomous procurement systems because discovery, identity, payment terms, execution and fulfilment are separate questions. A buyer or verifier should be able to say “I saw this listing” without silently upgrading that statement to “I know exactly which executable contract this represents.”

The same principle may apply beyond HTTP method. Depending on the protocol and marketplace, ambiguity could also arise from network, asset, route parameters, version, provider identity or schema information.

That extension is an inference and requires separate evidence for each case.

What this observation does not prove

The controlled sample does not establish:

• the percentage of the full x402.jobs catalogue that lacks HTTP method evidence;
• that unresolved listings are defective services;
• that x402.jobs should use Atinamos's canonical identity model;
• that endpoint + method is a sufficient universal identifier for every machine-service protocol;
• that the marketplace data will remain unchanged;
• that unresolved records cannot later be resolved using new evidence;
• that a successfully resolved identity proves service quality, fulfilment or future reliability.

The sample was selected during harvester development rather than through a formal random-sampling design. It should therefore be treated as a controlled engineering observation, not an estimate of marketplace prevalence.

Limitations and uncertainty

The observation depends on the public x402.jobs data available on 24 August 2026 and on the fields Atinamos inspected. A marketplace may hold information internally that it does not expose through the same public interface.

Some records could be associated with existing Atinamos services because earlier marketplace harvesting had already established a unique endpoint + method record. That means “resolved” in this test sometimes depended on evidence outside x402.jobs rather than x402.jobs alone.

The x402.jobs full-catalogue harvest was still running at publication time. Any later quantitative analysis of method availability or resolvability must be reported separately with the final sample size and method.

Adversarial considerations

Treating unresolved identity as a first-class state reduces one class of accidental overclaim, but it does not solve intentional identity manipulation.

A seller or marketplace could still publish misleading endpoints, descriptions, payment metadata or schemas. A resolved identity also says nothing by itself about whether the service will fulfil its advertised task.

Canonical identity should therefore be treated as one evidence layer, not as a trust verdict.

Reproducibility and evidence handling

The controlled ingestion tests used the Atinamos marketplace database and x402.jobs public resource identifiers. The implementation records marketplace source provenance and material-change hashes while excluding known volatile marketplace refresh metadata from the change fingerprint.

Atinamos does not publish credentials, encrypted configuration fields or marketplace-internal API-key identifiers collected incidentally in public detail responses.

The code supporting resolved and unresolved marketplace history is maintained in the Atinamos verification repository.

Related findings

This finding connects directly to several existing Atinamos principles:

• What Is Machine Contract Optimisation (MCO)? — clearer machine contracts may give buyers more explicit information to interpret.
• What Does Trust Mean in an AI Agent Marketplace? — identity evidence is only one category of evidence.
• Methodology — evidence should not be promoted to a stronger claim than the observation supports.
• Evidence and findings — payment, fulfilment and output validity are recorded separately.

Commercial relevance

Atinamos is commercially interested in machine-service verification and marketplace distribution. The observed/resolved distinction is relevant to both.

For verification, it prevents marketplace presence from being presented as stronger identity evidence than Atinamos actually holds.

For marketplace distribution, it suggests that “submitted” and “discoverable” are not sufficient final states. A distribution service may also need to verify what contract information became publicly visible after indexing.

These are product implications derived from the engineering observation. They are not evidence that a commercial market for those services has yet been established.

Change log

24 August 2026 — Initial publication based on the controlled 10-record x402.jobs ingestion test and prior multi-method endpoint observations. Full x402.jobs catalogue harvesting remained in progress at publication time.