Signal scoring

Signal turns verified Paybond settlement outcomes into portable reputation that partners can verify—without reviews, public feeds, or raw operational data.

The mental model comes before the mechanics: an agent completes work, Paybond verifies completion evidence, customer-owned rails release or refund, and that verified history becomes a signed standing artifact a partner, underwriter, or auditor can check independently. The score is a deterministic, tenant-scoped summary of that history, packaged with supporting metrics, reason codes, and a signature so the recipient never has to trust anyone's word for it.

The current scoring contract is intentionally conservative:

• It uses only signed Harbor terminal settlement evidence.
• It produces the same result from the same ledger history every time.
• It preserves historical results through explicit model versioning.
• It keeps review and risk controls separate from the canonical score.

That makes Signal suitable for customer-facing explanations, partner trust workflows, and long-lived audit records.

What Signal scoring is for

Signal is designed to answer a narrow question: based on completed Paybond intents, how reliably has this operator performed for this tenant?

It exists for teams that need verifiable standing rather than internal-only analytics or subjective ratings. Common uses include partner onboarding, underwriting and risk review, and compliance reporting—anywhere an outside reviewer needs to trust an operator's history without being granted access to your systems.

How reputation is created

Reputation is built on identity and evidence, not in isolation. Signal reads verified history rather than inventing new claims, so the path stays legible for non-engineering reviewers:

flowchart LR
  Work[Agent completes work] --> Verify[Paybond verifies evidence]
  Verify --> Rail[Rail releases or refunds]
  Rail --> Score[Signal score updates]
  Score --> Partner[Partner verifies reputation]

1. Agent completes work — an agent fulfills a task and produces completion evidence Paybond can evaluate.
2. Paybond verifies evidence — Harbor evaluates the completion rule and records release, refund, or review.
3. Rail releases or refunds — customer-owned rails execute the fund movement after that decision.
4. Signal score updates — verified outcomes recompute the deterministic score and its reason codes.
5. Partners verify reputation — a partner, underwriter, or auditor checks the signed receipt without touching your systems.

Within the platform, this maps to Harbor (evidence & release/refund decisions) → Ledger (transaction evidence) → Signal (verified reputation) → Partners (independent verification). Signal consumes verified outcome history; it does not move funds or generate rail facts of its own.

What goes into a score

For each (tenant_id, operator_did), Signal evaluates ingested Harbor outcome history and derives a score from a small set of outcome-driven inputs:

From those inputs, Signal derives rates such as success, refund, and dispute frequency. The current model then maps those metrics to a score from 0 to 1000.

If an operator has no terminal history yet, Signal returns a score of 0. In that case, the score means "not yet established in this model," not "known bad actor."

How a Signal score is calculated

The score is derived from signed settlement outcomes—nothing self-reported. Verified results raise it; friction and thin history hold it down. Under the current model (score_version = 1.0), the integer score is the sum of five bounded terms, clamped to the 0–1000 range:

Increases come from more released outcomes, low dispute and refund rates, faster terminal resolution, and confirmed released volume. Decreases come from disputes, refunds, and slow terminal resolution; sparse history keeps the score at 0 until at least one terminal outcome exists.

Every signed receipt carries supporting metrics and deterministic reason codes so an operator, reviewer, or partner can understand why a score looks the way it does or why it changed. Kit can recompute the same integer score from receipt metrics for display-only verification, but the canonical value is always the signed receipt.score field.

How to read a Signal score

The gateway returns a numeric score from 0 to 1000 (plus metrics and reason codes). It does not return a fixed grade or label enum in score_version = 1.0. The bands below are reviewer guidance for interpreting a score—not a hard product field, and not a threshold Paybond enforces on your behalf. Each reviewer still decides the cut-off that fits their own policy.

Higher scores generally reflect stronger settlement performance: more released outcomes, fewer refunds and disputes, faster time to terminal resolution, and more confirmed released volume. Lower scores usually mean terminal history is still sparse, refund or dispute rates are elevated, terminal outcomes are taking longer to complete, or released volume is still limited.

When scores change

Signal recomputes standing from new verified outcomes. It never rewrites history silently—every change points back to a settlement event recorded in the ledger.

• After a settlement — a released or refunded intent updates the success-rate and volume terms.
• On a dispute — an intent frozen into dispute review lowers standing until it resolves.
• On a reversal — a refund reduces the settlement-success contribution.
• On verification — a newly generated receipt captures the current standing at a fixed ledger position (ledger_watermark_seq) and timestamp.
• As history accumulates — because the model works from cumulative rates, a single new outcome shifts the aggregate less once an operator has many terminal outcomes. The receipt's ledger_watermark_seq and timestamp signal how current it is; the model does not silently time-decay older evidence.

Only signed Harbor terminal outcomes move the canonical score. Review workflow context—dispute-case statuses such as split resolution or external escalation—can appear in review surfaces without silently rewriting the signed score.

What does not change the score

The current model (score_version = 1.0) is intentionally narrow. The following may influence review posture, support decisions, or workflow routing, but they do not silently rewrite the signed score:

• analyst notes
• review-open, replay, or appeal events
• shadow annotations or anomaly flags
• first-class fraud signals surfaced for review with affects_score = false
• future non-settlement signals introduced outside the current score contract

This separation is deliberate. Teams can tighten operational controls without changing the historical scoring record.

Signed receipts and exports

Signal produces two portable artifacts:

• Operator receipt: a signed snapshot for one operator, including score, metrics, reason codes, model version, and ledger_watermark_seq, which identifies the Harbor ledger position used to build the receipt.
• Tenant portfolio export: a signed snapshot of the tenant's current operator scores and receipt digests.

These artifacts are designed to be verifiable and stable over time. Paybond signs them with the active Signal signing keys and keeps historical signatures verifiable during the normal key-rotation window.

Signal artifacts are private to the tenant. Paybond does not expose a public cross-tenant reputation feed or public leaderboard from this scoring surface.

How partners verify a receipt

A Signal receipt is built for outside review: a partner confirms integrity without database access or raw operational logs. The verification path is:

1. Fetch the signed receipt from the Paybond Gateway reputation API (GET /reputation/{operator_did}), scoped to the authenticated tenant.
2. Check the signature against Paybond's published Signal signing keys before trusting the score, metrics, or reason codes.
3. Match the receipt and operator to the claim under review, and confirm the score-model version is one your client supports.
4. Confirm freshness using ledger_watermark_seq and the receipt timestamp so you can tell how current the standing is.

When a reviewer needs the "why" behind a score or a change, GET /signal/v1/operators/{operator_did}/explanation returns the current support, confidence, and score-change explanation data. For a database-free continuity proof of the underlying settlement history, review flows use the Ledger verifier pack described in Ledger & provenance § Verification.

Privacy and selective disclosure

Signal is useful because it travels, but the sharing model stays explicit. You reveal only the proof a decision requires—never raw logs, customer data, or private review notes.

• Private by default — Signal artifacts are scoped to the customer workspace that owns the Paybond activity. They are not published into a global reputation feed.
• Receipts, not raw telemetry — partners receive signed summaries and verification material, not unrestricted access to databases, logs, or internal review notes.
• Shared on purpose — you choose when to hand over a signed standing snapshot, and the recipient verifies it without access to your systems.

This is the core contrast with traditional public reputation:

Review posture and trust policy

Signal keeps the signed score separate from operational trust policy. Through Gateway, Paybond can expose additional decision-support surfaces such as:

• review state and decision bands
• support and confidence indicators
• explanation deltas between score snapshots
• maturity and assurance posture
• shadow-risk annotations
• first-class fraud signals with affects_score=false
• tenant-configurable critical-signal release gating after fraud metrics are reliable
• replay, appeal, and review-open controls

These surfaces help teams decide when to clear, defer, or manually review an operator. They do not reweight the signed score for score_version = 1.0.

Integration examples

Retrieve a signed standing receipt for one operator through the Paybond Gateway with GET /reputation/{operator_did}. Tenant scope always comes from the authenticated session—never pass a tenant id from unauthenticated input.

// GET /reputation/{operator_did}
const receipt = await paybond.reputation.retrieve(
  "did:paybond:atlas-fulfillment",
);

console.log(receipt.score, receipt.standing, receipt.verified);
// GET /reputation/{operator_did}
const receipt = await paybond.reputation.retrieve(
  "did:paybond:atlas-fulfillment",
);

console.log(receipt.score, receipt.standing, receipt.verified);

# GET /reputation/{operator_did}
receipt = await paybond.reputation.retrieve(
    "did:paybond:atlas-fulfillment",
)

print(receipt.score, receipt.standing, receipt.verified)
# GET /reputation/{operator_did}
receipt = await paybond.reputation.retrieve(
    "did:paybond:atlas-fulfillment",
)

print(receipt.score, receipt.standing, receipt.verified)

An abbreviated response looks like:

{
  "operator_did": "did:paybond:atlas-fulfillment",
  "score": 842,
  "standing": "Trusted",
  "verified": true,
  "updated_at": "2026-07-05T14:32:00Z"
}
{
  "operator_did": "did:paybond:atlas-fulfillment",
  "score": 842,
  "standing": "Trusted",
  "verified": true,
  "updated_at": "2026-07-05T14:32:00Z"
}

This shape is a convenience view for quick integration. The canonical contract is the signed receipt envelope, which additionally carries outcome metrics, deterministic reason codes, the scoring family and score_version, and ledger_watermark_seq plus signature material. Two fields above are derived rather than authoritative gateway enums: standing is a reviewer band mapped from the numeric score (see How to read a Signal score), and verified reflects the client-side signature check, not a server-asserted trust verdict. For exact request and response shapes, see the Signal API reference.

Current contract versions

Model versioning is separate from freshness. ledger_watermark_seq on each receipt tells you which Harbor ledger position was used when the receipt was generated.

API surface

All Signal routes are served through the Paybond Gateway and scoped to the authenticated tenant. For full request and response contracts, see the Signal API reference.

Related

• Paybond Signal
• Signal API reference
• Ledger & provenance
• Operational surfaces