Trust is not one question.
"Can this be trusted?" sounds simple. In an agent workflow, it may conceal several different questions:
- Has the signed material remained intact?
- Does the supplied evidence belong to this claim or artifact?
- Does the receipt chain support the process said to have occurred?
- Is an authentic claim legitimate for this particular purpose?
- Was the payload received the same payload that was sent?
- Is a proposed transaction complete, current, evidenced and covered by the submitted approvals?
A valid signature answers only part of that picture. Cryptographic integrity does not, by itself, establish provenance, applicability, authority, readiness or a legitimate outcome.
MeaningSystem keeps those distinctions visible.
Each Trust Preset Route coordinates a defined sequence
of checks,retains the result of each stage and returns a route-level conclusion — without collapsing everything
into a vague trust score.
Agent workflows create evidence gaps at their boundaries.
An agent may receive a signed receipt but not know whether the associated process is adequately evidenced. An artifact may carry a passport but not match the submitted content. An exchange envelope may be intact while its payload or receipt references do not agree. A transaction proposal may appear complete while an approval has expired or the submitted authority does not cover the declared amount, asset or action.
These gaps often occur between systems:
- when one agent relies on a claim produced by another;
- when an artifact moves between tools, models or organisations;
- when a message is represented as sent and received;
- when an internal proposal approaches an external or consequential action;
- when receipts are retained but their relationship to the claim is unclear;
- when authentic material is treated as automatically legitimate.
The usual choices are poor: accept the representation at face value, build a custom verification chain for every workflow, or expose developers to a long catalogue of low-level endpoints.
Trust Preset Routes provide a more usable layer. Choose the kind of checkpoint required; MeaningSystem applies the established route and shows what happened inside it.
Simple at entry. Precise underneath. Inspectable on return.
Each route is a bounded composition of existing Maenen Trust operations. The route determines the required order, carries validated evidence between stages, avoids duplicate work and returns one coherent result surface.
Every completed run can show:
- the selected route and its purpose;
- which stages ran;
- which stages passed, raised caution, were rejected or were skipped;
- the evidence associated with each finding;
- trace and receipt references for executed stages;
- the route-level conclusion; and
- what remains missing, conflicting or unverifiable.
The routes are read-only. They assess submitted material; they do not create identities, alter trust history, approve actions or execute transactions.
Four checkpoints for consequential agent work.
Agent Claim Assurance
Is this agent claim supported by its signed receipt, receipt chain and stated context?
Artifact Trust Review
Is this the same artifact, and does its passport and receipt evidence support its represented provenance?
Agent Exchange Review
Is this exchange intact, correctly bound to its payload and consistently evidenced as sent and received?
Transaction Preflight
Is this proposed transaction complete, current, evidenced and covered by the submitted authority?
The displayed amount is the complete route bundle, not an additional charge for every internal check. Under the current route contracts, only a completed positive conclusion is chargeable; hold, rejected, failed and pre-execution invalid-evidence outcomes are not charged. Always consult the live pricing manifest for the current contract.
Agent Claim Assurance
agent_claim_assurance_v1 · 90 MCAn agent can state that a task ran, an artifact was produced or a required process was followed.
But the statement itself is not evidence.
Even a signed receipt does not automatically show that the submitted chain supports the claim or that the claim is legitimate for the intended use.
Agent Claim Assurance reviews a submitted claim through three coordinated stages:
Trust Verify checks the supplied signed receipt; Trust Proof assesses whether the receipt chain supports
the represented process; Trust Legitimacy assesses whether the authenticated claim is meaningful and applicable
to the expected intent and requested use. The same verified receipt-chain evidence is carried through the route.
Use when
- one agent must rely on another agent's claim;
- a completed-work claim arrives with signed receipts;
- an output is being considered for acceptance, publication or onward use;
- authenticity alone is insufficient and contextual legitimacy also matters.
You receive
- separate Verify, Proof and Legitimacy findings;
- an overall conclusion of assured, hold or rejected;
- explicit skipped findings where an earlier stage prevents later checks;
- the canonical receipt-chain fingerprint; trace and receipt references.
Artifact Trust Review
artifact_trust_review_v1 · 60 MCFiles, structured outputs and other artifacts move between agents, tools and organisations. A familiar filename or attached receipt does not prove that the content is unchanged, that the submitted passport belongs to it, or that the receipt history supports the provenance being represented.
The route coordinates: Artifact Passport Verify — recomputes the content identity and checks the submitted passport against the artifact; Receipt Bind — checks that the signed receipt evidence identifies and belongs to the same artifact; Trust Proof — assesses whether the supplied receipt history supports the represented provenance.
Use when
- receiving an artifact from another agent, system or organisation;
- checking an artifact before reuse, publication, storage or onward transfer;
- confirming that content still matches its submitted passport;
- reviewing provenance after a multi-step workflow.
You receive
- the passport-verification finding;
- the artifact-to-receipt binding finding;
- the provenance Proof finding;
- a consolidated artifact-trust conclusion with trace evidence and linked receipts.
Agent Exchange Review
agent_exchange_review_v1 · 60 MCAgent-to-agent communication involves more than a message body. An exchange may include an envelope, sender and receiver references, a payload identity, timestamps and receipts from different points in the transfer. Any one component can be valid while the overall representation is inconsistent.
The route coordinates: Envelope Verify, Payload Bind, Receipt Correlate and Trust Proof — examining whether a submitted exchange is authentic and intact, whether its payload is correctly bound to the signed envelope, and whether the supplied receipts consistently represent what was sent and received.
Use when
- one agent hands a message or payload to another;
- an exchange crosses a model, runtime, team or organisational boundary;
- a receiver must verify that it received the represented payload;
- an exchange will become evidence for a later claim or decision.
You receive
- envelope-integrity findings;
- payload-binding findings;
- sender/receiver receipt-correlation findings;
- an exchange-level Proof finding with trace and receipt references.
Transaction Preflight
transaction_preflight_v1 · 90 MCTransactions are where agent representations begin to meet external consequence. A proposal may look complete while material terms conflict, evidence points to another transaction, an approval has expired, or submitted authority does not cover the declared action, currency, asset or amount.
Transaction Preflight provides a read-only checkpoint before a separate authorised system decides whether to proceed. It assesses: Proposal Validate, Evidence Verify, Trust Verify, Trust Proof, Trust Legitimacy and Readiness Consolidate — distinguishing satisfied, cautionary, missing, conflicting, expired, revoked and unverifiable conditions.
Use when
- an agent has prepared a purchase, payment, reservation or commitment;
- a proposal is about to cross from internal preparation to an external system;
- approval and authority evidence must be checked against material terms;
- a human or policy engine needs an inspectable readiness assessment before deciding.
You receive
- proposal and material-term findings;
- evidence-binding and authority-coverage findings;
- Verify, Proof and Legitimacy findings;
- a consolidated readiness result preserving every unresolved condition.
Start with the object or event you need to assess.
| You need to review… | Use… |
|---|---|
| A claim made by an agent, supported by a signed receipt chain | agent_claim_assurance_v1 |
| An artifact, its passport and its provenance evidence | artifact_trust_review_v1 |
| A signed payload exchange between agents or systems | agent_exchange_review_v1 |
| A proposed transaction before any external action occurs | transaction_preflight_v1 |
| Whether meaning, constraints, authority or responsibility survived delegation | agent_handoff_audit_v1 |
| One narrow signature, hash, issuer, Proof or Legitimacy question | the relevant direct Trust API |
An agent may request a route explicitly by its stable route ID. MeaningSystem may also suggest a matching route when the submitted intent and evidence fit its selection rules. Suggestions are advisory: they do not auto-run and require confirmation. For consequential or repeatable workflows, explicit route selection is recommended — it makes the intended checkpoint part of the workflow contract.
Add a checkpoint without replacing your workflow.
- Identify the trust moment. Decide whether the workflow is relying on a claim, receiving an artifact, reviewing an exchange or approaching a transaction.
- Retain the evidence at source. Preserve signed receipts, passports, envelopes, hashes, approvals and authority evidence as they are created. A later route cannot recover evidence that was never recorded.
- Submit the bounded assessment. Call the selected public route through the MeaningSystem run entry point:
POST /v1/run Authorization: Bearer - Inspect the route result. Read the overall conclusion together with the stage findings, skipped checks, unknowns and evidence references. Do not treat the top-level status as a substitute for the detail beneath it.
- Let the controlling workflow decide. Continue, pause, reject or escalate according to your own permissions, policies and the route result. MeaningSystem supplies evidence for that decision; it does not take the action.
- Retain the return. Keep the relevant receipts and route evidence with the associated claim, artifact, exchange or proposal for later verification and audit.
Choose the level of control your workflow needs.
Use a Trust Preset Route when
the checkpoint requires several coordinated Trust operations; evidence must remain connected across the assessment; you want a consolidated conclusion and route-level receipt bundle; your agent understands the purpose of the checkpoint but should not assemble the internal tool chain; consistent treatment across many runs matters.
Use an individual Trust API when
your workflow already knows the exact bounded question; only one signature, hash, issuer, revocation, Proof or Legitimacy check is required; your system needs to construct its own composition; a smaller deterministic check is sufficient.
MeaningSystem preset routes are the front door.
Individual Trust APIs are the instruments behind it.
What a trust route does — and does not — establish.
A Trust Route can assess whether the submitted material is internally consistent, cryptographically verifiable where supported, correctly bound, supported by its receipt history and applicable to its stated context. It does not turn supplied evidence into universal truth. In particular, a route result does not automatically establish:
- real-world or legal identity;
- ownership, custody or title;
- truthfulness of every originating assertion;
- authority beyond the submitted signed evidence;
- legal or regulatory compliance;
- successful external execution;
- permission to spend, publish, merge, settle or act;
- future reliability or safety.
MeaningSystem assesses the checkpoint.
Your authorised system controls the gate.
Depth without the doctorate.
The Trust suite contains distinct operations because identity, integrity, evidence, provenance, authority and legitimacy are not interchangeable.
Most integrations should not need to assemble those operations from first principles every time.
MeaningSystem turns that depth into four recognisable workflow checkpoints while preserving the precision underneath:
- stable, versioned route identities;
- bounded and read-only execution;
- cautious route suggestion without hidden auto-execution;
- ordered findings with explicit skipped stages;
- linked trace and receipt evidence;
- consolidated route conclusions;
- clear non-authority and non-execution boundaries;
- modular direct APIs for advanced use.
No replacement agent.
No black-box trust score.
No claim that a valid signature makes an action legitimate.
Simply a better-evidenced point at which a consequential agentic workflow can decide what happens next.
Frequently asked.
Does MeaningSystem run or control my agent?
Are Trust Routes automatic?
Does an assured result authorise the next action?
Is a valid signature enough to establish legitimacy?
Does Transaction Preflight execute a transaction?
Does Artifact Trust Review create an Artifact Passport?
Is Agent Exchange Review the same as Agent Handoff Audit?
Can developers still call the individual Trust APIs?
Keep the workflow. Strengthen the checkpoint.
MeaningSystem provides preconfigured assessments and modular Trust APIs for agent workflows. It does not operate or replace the agent runtime.
· v1 BETA NOTICE
Maenen suite tools are currently available in public release beta. All effort is being made to assure full performance and capability. Please be patient as the full system is brought online and any use-case feedback is considered. Any free assessment keys are subject to rate cap and payload limits. No uptime or performance guarantees are implied and may be subject to version changes.
Deployment note: public demo surfaces are currently limited to approved routes, proof inspection, and capsule save/verify.