Credit & Underwriting

Credit Facilities

A credit facility is a pre-approved line of credit granted to an agent or operator. The disposition is derived from the applicant's scorecard band, runtime assurance, and certification standing, and also from the shape of their book. The report carries a manual_review_required flag (crates/economy/chio-credit/src/lib.rs:592), and admission refuses a grant while it is set (crates/economy/chio-credit/src/obligation/credit_admission.rs:554). Nothing in the crate sets it, so what raises it is the caller's to decide. Terms are captured in CreditFacilityTerms:

pub struct CreditFacilityTerms {
    pub credit_limit: MonetaryAmount,
    pub utilization_ceiling_bps: u16,                // max % of limit drawable at once
    pub reserve_ratio_bps: u16,                      // reserve, as a share of outstanding exposure
    pub concentration_cap_bps: u16,                  // max size of any single allocation
    pub ttl_seconds: u64,                            // facility lifetime
    pub capital_source: CreditFacilityCapitalSource, // where backing capital comes from
}

When an agent applies for credit, the underwriting system evaluates the application and returns a CreditFacilityDisposition, one of three variants:

• Grant: a credit facility is created with the terms specified by the underwriting decision.
• ManualReview: the application is borderline and requires human review before a facility can be granted.
• Deny: the application does not meet minimum underwriting criteria.

The same three values are the accepted --disposition filter on chio trust facility list: grant, manual_review, deny.

Credit Bonds

A credit bond is the collateral backing for an active credit facility. Bonds lock capital that can be seized if the agent defaults on its obligations.

pub struct CreditBondTerms {
    pub facility_id: String,
    pub credit_limit: MonetaryAmount,
    pub collateral_amount: MonetaryAmount,
    pub reserve_requirement_amount: MonetaryAmount,
    pub outstanding_exposure_amount: MonetaryAmount,
    pub reserve_ratio_bps: u16,
    pub coverage_ratio_bps: u16,
    pub capital_source: CreditFacilityCapitalSource,
}

Bonds pass through a lifecycle of states:

Bond disposition actions control transitions between states:

• Lock: lock additional collateral into the bond
• Hold: place a hold on bond collateral pending investigation
• Release: release collateral back to the bond holder
• Impair: seize collateral due to default or violation

Underwriting Decisions

The underwriting system evaluates credit applications using a combination of reputation history, certification status, and risk classification. Each decision records its reason codes and inputs.

Risk Classification

The risk class is an output, not a gate. Every finding carries its own class, and the report's risk_class is the maximum over them, defaulting to Baseline when nothing fired (crates/economy/chio-underwriting/src/decision.rs:649-653). The outcome is derived the same way from the same findings (:644-648), so the class summarizes an application rather than deciding it. Terms are set by a different enum, CreditScorecardBand, whose five values are prime, standard, guarded, probationary and restricted(crates/economy/chio-credit/src/lib.rs:372-378), carried as the band field of the scorecard (:511).

Decision Outcomes

The underwriter produces one of four decision outcomes. There is no manual-review outcome here: ManualReview is a CreditFacilityDisposition and an UnderwritingRemediation, not an UnderwritingDecisionOutcome.

• Approve: grant the requested facility with computed terms
• ReduceCeiling: approve with a lower utilization ceiling than requested
• StepUp: require additional collateral or certification before approval
• Deny: reject the application with reason codes

Decision Policy Defaults

The default policy is not a document to trust: the evaluator prints it with every report, so read it from the binary rather than from here.

$ chio --json trust underwriting-decision evaluate \
    --agent-subject demo-agent --tool-server ts-demo --receipt-db ./receipts.db \
  | jq '.policy'

{
  "schema": "chio.underwriting.decision-policy.v1",
  "version": "chio.underwriting.decision-policy.default.v1",
  "minimumReceiptHistory": 1,
  "maximumReceiptAgeSeconds": 2592000,
  "minimumApproveReputationScore": 0.6,
  "denyReputationScoreBelow": 0.25,
  "minimumStepUpRuntimeAssuranceTier": "attested",
  "minimumApproveRuntimeAssuranceTier": "verified",
  "requireActiveToolCertification": true,
  "requireComplianceScoreReference": false,
  "reduceCeilingFactor": 0.5
}

Two of those need reading carefully. minimumReceiptHistory is a count: at least one matching receipt. maximumReceiptAgeSeconds is a freshness ceiling on the newest one, so an agent with a single receipt from five minutes ago passes while an agent with two years of history whose newest receipt is thirty-one days old fails with StaleReceiptHistory(crates/economy/chio-underwriting/src/decision.rs:447-457).

Reason Codes

Every UnderwritingDecisionFinding carries a primary UnderwritingDecisionReasonCode in its reason field, the code that ties directly to the thresholds above. There are eight:

pub enum UnderwritingDecisionReasonCode {
    PolicySignal,                     // an underlying policy signal fired
    ComplianceScoreRequired,          // a compliance score is missing
    InsufficientReceiptHistory,       // fewer receipts than the minimum
    StaleReceiptHistory,              // receipt history older than the window
    ReputationBelowApproveThreshold,  // reputation under the 0.6 approve floor
    ReputationBelowDenyThreshold,     // reputation under the 0.25 deny floor
    RuntimeAssuranceBelowApproveTier, // assurance tier below approve
    RuntimeAssuranceBelowStepUpTier,  // assurance tier below step-up
}

A finding may also carry an optional secondary signal_reason of type UnderwritingReasonCode, the underlying signal that drove the primary reason. There are 13:

pub enum UnderwritingReasonCode {
    ProbationaryHistory,           // insufficient operational history
    LowReputation,                 // composite reputation below threshold
    ImportedTrustDependency,       // reliance on external trust source
    MissingCertification,          // required cert not present
    FailedCertification,           // certification check failed
    RevokedCertification,          // certification was revoked
    MissingRuntimeAssurance,       // no runtime assurance attestation
    WeakRuntimeAssurance,          // assurance tier below minimum
    PendingSettlementExposure,     // unsettled financial exposure
    FailedSettlementExposure,      // prior settlement failure
    MeteredBillingMismatch,        // billing discrepancy detected
    DelegatedCallChain,            // delegation chain risk factor
    SharedEvidenceProofRequired,   // additional proof needed
}

Bonded Execution

Bonded execution is the mechanism that allows autonomous agents to operate independently while providing economic guarantees to counterparties. The level of autonomy an agent has is governed by its autonomy tier and control policy.

Autonomy Tiers

Control Policy

Every bonded agent has a control policy that constrains its autonomy:

pub struct CreditBondedExecutionControlPolicy {
    pub version: String,
    pub kill_switch: bool,                                             // immediately halt all agent activity
    pub maximum_autonomy_tier: Option<GovernedAutonomyTier>,          // highest tier this agent can reach
    pub minimum_runtime_assurance_tier: Option<RuntimeAssuranceTier>, // floor on attested runtime assurance
    pub require_delegated_call_chain: bool,                           // require a delegated call chain
    pub require_locked_reserve: bool,                                 // must have active bond before operating
    pub deny_if_bond_not_active: bool,                               // deny when the bond is not active
    pub deny_if_outstanding_delinquency: bool,                       // deny on outstanding delinquency
}

The kill_switch is an emergency stop that immediately halts all agent activity regardless of bonds or approvals. When require_locked_reserve is set, the agent cannot execute any tool invocations unless it has an active bond with sufficient collateral. The autonomy ceiling is a GovernedAutonomyTier, and the deny_if_bond_not_active and deny_if_outstanding_delinquency gates are on by default.

Execution Decisions

When a bonded agent requests a tool invocation, the system evaluates the request against the agent's bond, control policy, and current exposure to produce a CreditBondedExecutionDecision. The decision is binary:

• Allow: invocation proceeds against the agent's bond.
• Deny: invocation rejected. The decision carries finding codes that name which gate refused it: KillSwitchEnabled, BondNotActive, RuntimeAssuranceBelowAutonomyMinimum, MissingDelegatedCallChain, and so on.

There is no "requires bond" outcome: an agent that lacks the collateral to proceed is denied, and posting a bond is a separate action (chio trust bond issue) taken before the next attempt.

Capital Book

The capital book is the ledger of all capital movements within the credit system. Every event (Commit, Hold, Draw, Disburse, Release, Repay, Impair) is recorded.

Event Kinds

Capital Roles

Each capital movement involves a counterparty with a defined role:

• OperatorTreasury: the operator's own capital pool, used for self-funded facilities
• ExternalCapitalProvider: third-party capital provider who funds facilities for a return
• AgentCounterparty: the agent or entity on the other side of the capital movement

Execution instructions for capital movements can require multi-sig authority chains, ensuring that high-value disbursals or impairments require approval from multiple authorized parties.

Liability Market

The liability market provides insurance-like coverage for tool execution risks. Providers underwrite specific risk classes and agents can purchase coverage to protect against operational failures.

Provider Types

Coverage Classes

Coverage is organized into five classes, each addressing a different risk category:

• ToolExecution: covers losses from tool invocation failures or incorrect results
• DataBreach: covers costs arising from unauthorized data exposure during tool use
• FinancialLoss: covers direct financial losses from agent actions
• ProfessionalLiability: covers claims from errors in professional-grade agent outputs
• RegulatoryResponse: covers costs of regulatory investigations or compliance actions

Coverage Lifecycle

Coverage follows a standard insurance lifecycle:

Quote -> Bind -> [Active Coverage Period] -> Claim -> Adjudication -> Payout

• Quote: provider prices the coverage based on the agent's risk profile and requested class
• Bind: agent accepts the quote, premium is collected, coverage begins
• Claim: agent or operator files a claim against the coverage after a covered event
• Adjudication: provider evaluates the claim against receipts and policy terms
• Payout: approved claims are settled through the standard settlement rails

Open Market

The open market uses economic bonds to incentivize honest participation in the Chio ecosystem. Participants post bonds that can be slashed if they violate market rules.

Bond Classes

Penalty Actions

When a market rule is violated, the system can apply penalty actions against the violator's bond:

• HoldBond: freeze the bond pending investigation. Capital cannot be withdrawn but is not yet seized.
• SlashBond: seize part or all of the bond as a penalty. Slashed capital is distributed to the affected counterparty.
• ReverseSlash: reverse a previous slash if the original decision is overturned on appeal.

Operator CLI

Each concept above has a corresponding chio trust subcommand that emits or lists the corresponding signed record.

Summary

Next Steps

• Settlement · how settled capital moves through the configured payment rail
• CLI Reference · commands for managing facilities, bonds, and underwriting
• Agent Passport · the reputation system that feeds underwriting decisions