Evidence row 568943

What was observed

{
  "count": 8,
  "tools": [
    {
      "description": "List the immutable audit-archive entries for the caller's API key: every Montgomery evidence report the key generated (text or json), newest first, each with its entry id, generation timestamp, DOT number, scoring date, methodology version and the SHA-256 of the archived report text. Requires a paid CarrierScore API key.\n\nUse it to answer \"which carriers did we generate evidence for, and when?\" and to find the entry id to cite or verify for a given carrier and date. Monitor keys see the last 90 days; Compliance keys see everything ever archived.\n\nArgs:\n  - dot_number (optional): only entries for this US DOT number\n  - since (optional): YYYY-MM-DD; only entries generated on/after this date (UTC)\n  - limit (optional): 1-500, default 50\n\nReturns JSON: { tier, retention_days, total_entries, matched, count, entries: [{ entry_id, generated_at, dot_number, sha256, format_requested, scored_as_of, score_version }] }.\n\nErrors: 403 without a paid key; 400 if since is malformed.",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "dot_number": {
            "description": "US DOT number of the carrier, digits only (e.g. \"1234567\")",
            "pattern": "^\\d{1,8}$",
            "type": "string"
          },
          "limit": {
            "description": "Max entries to return (default 50)",
            "maximum": 500,
            "minimum": 1,
            "type": "integer"
          },
          "since": {
            "description": "Only entries generated on/after this date (YYYY-MM-DD, UTC)",
            "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
            "type": "string"
          }
        },
        "type": "object"
      },
      "name": "audit_entries"
    },
    {
      "description": "Look up an FMCSA-registered motor carrier's identity by US DOT number: legal name, DBA, operating status, FMCSA safety rating, fleet size (power units, drivers), physical address, and registration dates.\n\nUse this first when a booking/dispatch agent needs to confirm WHO a carrier is — that a DOT number is real, active, and matches the company name on a rate confirmation. It does not return risk indices (use carrier_score for those).\n\nReturns JSON: { dot_number, legal_name, dba_name, status_code, safety_rating, power_units, total_drivers, phy_street, phy_city, phy_state, phy_zip, add_date, mcs150_date }.\n\nErrors: 404 if the DOT is not in the FMCSA census (likely a typo or a fraudulent/never-registered carrier — treat as a red flag for booking).",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "dot_number": {
            "description": "US DOT number of the carrier, digits only (e.g. \"1234567\")",
            "pattern": "^\\d{1,8}$",
            "type": "string"
          }
        },
        "required": [
          "dot_number"
        ],
        "type": "object"
      },
      "name": "carrier_lookup"
    },
    {
      "description": "Get the CarrierScore risk indices for a carrier by US DOT number: two first-class, separately validated indices (0-100, HIGHER = RISKIER), each with a full component breakdown.\n\nThis is the core \"is this carrier safe to book?\" signal for AI booking agents. Served methodology v0.5 returns TWO indices, both population-relative and built from point-in-time public FMCSA data:\n  - inspection_risk — inspection / compliance risk: violations and out-of-service rates per roadside inspection (24-month chronic, 6-month acute). Historically validated against the carrier's future out-of-service rate (validation block on the index).\n  - crash_risk — crash risk: reportable crashes, fatal/injury crashes and tow-away crashes per roadside inspection (24 months). Historically validated against future reportable crashes (validation block on the index).\nPresent BOTH indices; do not collapse them into one number. Hard flags (active out-of-service order, no active insurance filing, high-confidence reincarnated-carrier link) add explicit surcharges — a carrier with any flag deserves extra scrutiny regardless of index values.\n\nReturns JSON: { dot_number, legal_name, inspection_risk: { label, description, score, base, surcharge, percentile_basis, band, band_note, data_sufficiency, components: { <name>: { label, value, percentile, weight } }, validation: { auc_holdout, label, holdout_origins, post_selection_origin, source, text } }, crash_risk: { ...same shape... }, legacy_composite: { score, base_score, surcharge, rule, rule_text, validated: false, note }, carrier_score (backward-compatible: == legacy_composite.score under v0.5), base_score, surcharge, score_version (\"0.5\"), methodology_note, components (flat, backward-compatible), flags: string[], data_sufficiency (0-1, share of the components resting on observed vs neutral-imputed data), scored_as_of, disclaimer }. Older opt-in methodologies keep their shapes: v0 (six components), v0.3 (sub_indices), v0.4 (indices + composite).\n\nInterpreting for booking decisions: treat the indices as documented decision-support evidence, not an approve/deny verdict. legacy_composite / carrier_score is NOT validated and is kept only so older integrations keep working — never present it as the carrier's risk score. Low data_sufficiency means limited inspection history — common for new carriers, itself a risk signal. Always relay each index's validation text and the disclaimer when presenting the result.\n\nErrors: 404 if the DOT is not in the scored population; 503 if scores have not been computed yet.",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "dot_number": {
            "description": "US DOT number of the carrier, digits only (e.g. \"1234567\")",
            "pattern": "^\\d{1,8}$",
            "type": "string"
          }
        },
        "required": [
          "dot_number"
        ],
        "type": "object"
      },
      "name": "carrier_score"
    },
    {
      "description": "Retrieve the alert history for a saved carrier list (see save_carrier_list), newest first. Requires the same paid API key that saved the list.\n\nEach alert records one change detected between consecutive daily scoring runs for one carrier: type (oos_order_activated, authority_lost, insurance_lapsed, status_changed, inspection_risk_jump, crash_risk_jump, score_jump, reincarnation_link), severity (critical / high / medium / low), the field that changed with its before/after values, the DOT and legal name, and the scoring dates compared. inspection_risk_jump / crash_risk_jump (index base up >= 10 points, medium) are the primary deterioration signals; score_jump on the legacy composite is emitted at low severity for backward compatibility. Use it to answer \"did anything change on my carrier list?\" — critical alerts (new OOS order, authority lost) mean the carrier should not be dispatched until verified; follow up with carrier_score or montgomery_file for the full picture.\n\nArgs:\n  - list_id: the lst_... id returned by save_carrier_list\n  - since (optional): YYYY-MM-DD; only alerts from scoring runs on/after this date\n\nReturns JSON: { list_id, since, count, alerts: [{ ts, as_of, prev_as_of, list_id, list_name, dot, legal_name, type, severity, field, before, after }] }. An empty alerts array means no monitored change since the given date (alerts only exist once two daily scoring runs have happened).\n\nErrors: 403 without a paid key; 404 if the list id is unknown for this key; 400 if since is not YYYY-MM-DD.",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "list_id": {
            "description": "Saved list id from save_carrier_list",
            "pattern": "^lst_[A-Za-z0-9_-]+$",
            "type": "string"
          },
          "since": {
            "description": "Only alerts from scoring runs on/after this date (YYYY-MM-DD)",
            "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
            "type": "string"
          }
        },
        "required": [
          "list_id"
        ],
        "type": "object"
      },
      "name": "list_alerts"
    },
    {
      "description": "Batch risk check for a list of carriers by US DOT number (max 100 per call): score summary and hard flags for each.\n\nUse when an agent is screening multiple candidate carriers for a load, or re-checking a broker's active carrier roster (\"did any of my carriers pick up an out-of-service order or drop insurance?\"). For a full breakdown of any single carrier that looks risky here, follow up with carrier_score or montgomery_file.\n\nArgs:\n  - dot_numbers: array of DOT number strings, 1-100 entries\n\nReturns JSON: { scored_as_of, requested, found, carriers: [{ dot_number, legal_name, inspection_risk (0-100 inspection / compliance risk index, higher = riskier), crash_risk (0-100 crash risk index), carrier_score (legacy composite under v0.5 — backward compatibility only; use the two indices), data_sufficiency, flags: string[] }], not_found: string[], disclaimer }. DOTs in not_found are absent from the scored population — verify them with carrier_lookup; an unknown DOT on your roster is itself a red flag.\n\nErrors: 400 if the list is empty or exceeds 100 (split into batches); 503 if scores are not computed yet.",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "dot_numbers": {
            "description": "US DOT numbers to check, 1-100 per call",
            "items": {
              "description": "US DOT number of the carrier, digits only (e.g. \"1234567\")",
              "pattern": "^\\d{1,8}$",
              "type": "string"
            },
            "maxItems": 100,
            "minItems": 1,
            "type": "array"
          }
        },
        "required": [
          "dot_numbers"
        ],
        "type": "object"
      },
      "name": "monitor_carriers"
    },
    {
      "description": "Generate a timestamped Montgomery file — a carrier-selection evidence report — for a carrier by US DOT number.\n\nSince Montgomery v. Caribe Transport II (SCOTUS, May 2026), freight brokers are exposed to state-law negligent-selection claims and need documented, timestamped, safety-data-based carrier selection. This report is that artifact: the two risk indices (inspection / compliance risk and crash risk, each with its components, percentiles, activity-band context and its own historical-validation line), the legacy composite (labelled backward-compatibility only), hard flags, FMCSA safety rating, and the methodology disclaimer, dated as of the scoring run. A booking agent should generate and retain this file at the moment a carrier is selected for a load.\n\nArgs:\n  - dot_number: US DOT number, digits only\n  - format: \"text\" (default; the filing-ready plain-text report, available on the free tier) or \"json\" (structured fields; requires an API key on the monitor or compliance tier)\n\nReturns: format=\"text\" gives the plain-text report (structured field report_text); format=\"json\" gives structured fields { report, generated, dot_number, legal_name, dba_name, safety_rating, status_code, power_units, inspection_risk, crash_risk, legacy_composite (v0.5), carrier_score (backward-compatible), components, flags, data_sufficiency, score_version, scored_as_of, disclaimer } (v0.4 parquets return indices + composite instead). Every report embeds the disclaimer verbatim — keep it when storing or quoting the report.\n\nAudit archive (paid tiers): every report generated with an API key is stored immutably server-side and the result carries audit_entry_id + sha256 (SHA-256 of the plain-text report). Quote both when citing the report; later, verify_evidence(entry_id) proves the archived copy is unchanged and audit_entries lists what was generated. Monitor keys can retrieve the last 90 days (2,000 reports/month); Compliance keys have unlimited retention and reports.\n\nErrors: 403 if format=json without an API key; 404 unknown DOT; 429 if a Monitor key has used its 2,000 reports this month (upgrade hint in the message); 503 if scores are not computed yet.",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "dot_number": {
            "description": "US DOT number of the carrier, digits only (e.g. \"1234567\")",
            "pattern": "^\\d{1,8}$",
            "type": "string"
          },
          "format": {
            "default": "text",
            "description": "\"text\" = filing-ready report (free tier); \"json\" = structured fields (requires API key)",
            "enum": [
              "text",
              "json"
            ],
            "type": "string"
          }
        },
        "required": [
          "dot_number"
        ],
        "type": "object"
      },
      "name": "montgomery_file"
    },
    {
      "description": "Save a named list of carriers (by US DOT number) for continuous monitoring. Requires a paid CarrierScore API key (Monitor or Compliance tier) — connect with your key via OAuth (or set CARRIERSCORE_API_KEY on a self-hosted server); the free tier gets a 403 with an upgrade link.\n\nOnce saved, CarrierScore diffs every carrier on the list against the previous day's scoring run after each daily run and records alerts: new out-of-service order (critical), operating authority lost (critical), insurance filing lapsed (high), operating status leaving Active (high), risk score up 10+ points (medium), high-confidence reincarnated-carrier link appearing (medium). Alerts are always retrievable with list_alerts; optionally they are also pushed to a webhook (JSON POST, HMAC-signed via the X-CarrierScore-Signature header with the per-key secret from GET /v1/lists) and/or summarized in one daily digest email.\n\nUse this when a broker asks to \"watch\" or \"keep an eye on\" their carrier roster. Caps: 500 DOTs total across all lists on the Monitor tier, 5000 on Compliance; up to 50 lists per key. Saving the same DOT twice in one list is deduped.\n\nArgs:\n  - name: short label for the list (1-100 chars)\n  - dot_numbers: array of DOT number strings (1-8 digits each)\n  - webhook_url (optional): https URL to POST new alerts to\n  - email (optional): address for the daily digest\n\nReturns JSON: { list_id, name, dots, created, updated, webhook_url?, email? }. Keep list_id — list_alerts needs it.\n\nErrors: 403 without a paid key; 400 on invalid DOTs, empty list, or exceeding the tier cap (message says which); 401 bad key.",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "dot_numbers": {
            "description": "US DOT numbers to monitor",
            "items": {
              "description": "US DOT number of the carrier, digits only (e.g. \"1234567\")",
              "pattern": "^\\d{1,8}$",
              "type": "string"
            },
            "maxItems": 5000,
            "minItems": 1,
            "type": "array"
          },
          "email": {
            "description": "Optional daily digest email",
            "format": "email",
            "type": "string"
          },
          "name": {
            "description": "List name, e.g. \"Active roster Q3\"",
            "maxLength": 100,
            "minLength": 1,
            "type": "string"
          },
          "webhook_url": {
            "description": "Optional https URL to receive alert POSTs",
            "format": "uri",
            "type": "string"
          }
        },
        "required": [
          "name",
          "dot_numbers"
        ],
        "type": "object"
      },
      "name": "save_carrier_list"
    },
    {
      "description": "Verify an archived Montgomery evidence report by its audit entry id: CarrierScore re-reads the immutable stored copy, recomputes its SHA-256 and reports whether it matches the hash recorded at generation time (and, optionally, a hash the caller supplies — e.g. the sha256 printed on a broker's filed copy). Requires the same paid API key that generated the report.\n\nUse it when a broker or auditor needs to prove that a filed evidence report is exactly what CarrierScore produced on the stated date. match=true means the archived report is byte-identical to what was served; match_supplied compares against the caller's own hash. Follow up with the audit_entries list to find ids, or with montgomery_file to generate a fresh report.\n\nArgs:\n  - entry_id: the audit_entry_id returned by montgomery_file (also listed by audit_entries)\n  - sha256 (optional): a 64-hex SHA-256 to compare against the archived report (text or canonical json)\n\nReturns JSON: { entry_id, dot_number, generated_at, scored_as_of, score_version, format_requested, sha256_stored, sha256_computed, match, sha256_json_stored, sha256_json_computed, match_json, sha256_supplied?, match_supplied? }.\n\nErrors: 403 without a paid key, or (Monitor tier) if the entry is older than the 90-day retrieval window; 404 if the entry id is unknown for this key.",
      "inputSchema": {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "additionalProperties": false,
        "properties": {
          "entry_id": {
            "description": "Audit entry id from montgomery_file / audit_entries",
            "pattern": "^\\d{1,8}_\\d{8}T\\d{12}Z_[0-9a-f]{8}$",
            "type": "string"
          },
          "sha256": {
            "description": "Optional SHA-256 to compare against the archived report",
            "pattern": "^[0-9a-fA-F]{64}$",
            "type": "string"
          }
        },
        "required": [
          "entry_id"
        ],
        "type": "object"
      },
      "name": "verify_evidence"
    }
  ]
}

What the leaf hashes

{"body":"9dd9ccd540199afd6d41068d80c570c65f68cf3daf367c93d12a9f17633c7757","id":568943,"kind":"mcp.tools","method":"probe.mcp/1","observed_us":1793139169787578,"prev":null,"subject":"03ae7dc4-35f6-48a8-b3ed-070eab43531f","subject_kind":"endpoint"}

Proof

Fold these into the leaf in order, hashing each sorted pair with keccak256, to reach the root of 2026-10-27 (273461 rows).

1. 0x6eb90f4061c0a445509de0b3bab2e88f365901f1091344a679ef428c06e2bc79
2. 0xafbc7c0d520582693629f28e4fc96ad9ebc994320ce3477be3b42e4bcf12ca5c
3. 0xb7676a60c46577d38a4f1289b1b8c88427219c2be7254b0eecc2267b70ddf0c4
4. 0xdab12920b3dd2dd7ef3d23e27d5e2171aa9a24046fa4a735d18bd2042a09f017
5. 0x0d7a12a4e17d199299d2dc4e8dc313c70fe72f04a1c49317b82d88cf8bf07b21
6. 0xd6606d2de9ade079a77524d97134841d7fee0a1ed02234a95794e1a3af7aa1f6
7. 0x795f725d7db19baa293f6a3192269d703cdf9fc84de24b7b1ca341b1310a0951
8. 0x4218f4b77aaffef79c5aa56796fbec41189f23bb7e6e52b97d129505f58afdeb
9. 0x7f6e07e6fb39f066ced9e40da7f54d0a85439e82da9f851b11b16960fbde3c2f
10. 0xc29650db60795ec82f45e9969f6b0a4c48579a02b5ea6cdd47974099180e7cc1
11. 0x040640e4e07fb01070334ad90420bc979cc6533217449ddacb84ff50f0700a8b
12. 0x346adc8ebb20cf5f1a3349535238f6ff723da69f956f4b8324d3ec6271a3c969
13. 0xa7e162a9119a39c37b96b3483510d3fd108f25676fe3a9584241629612b01526
14. 0xb2ae53d841a55a805fb4078b1a7d44e08a81aba4be3690bac3a5b4c366bf39da
15. 0x275720ecabb68df33eee92ae4fd70572a8d952d6c61c061c2869cfc3217aa5c5
16. 0x23cf9bb4337ee8be7fcae368fd69d24c62c11fb45882127b4cd919bb96a19996
17. 0x0e01aa9525097570a6edaf32bfc959de57bf5c24317cf10c0716affea85ca60d
18. 0xa20d48798a34aba12eb9c7297722982d910f06c148f5e27ac59307422964a585
19. 0x9fc354c0ea3efc3f1b6548bb77ea902a50f2c9647647ea61592efce2bd795699

Day root

0xdd77e5e99da32c3f154180d63e3c3e6fe11e896a2c6896412ef6b5c4bcf7e795

Chained

0x23bb4dfd09f55c15ac3962f53578e02c6114d5bfd9bb451cf8794fb6e2817ef4

Published

On Arc Testnet, block 69414147: 0xb2ebd83aafeb765a0ce66e76aefb133ed06606c98038fd56191e2bcd1dcb77b4