Collections Compliance Pack

Note (dated 2026-08-04): a chain composes independent computations performed in an analytical order. No step's output is carried into the next step by the execution model; each step computes from its own declared inputs. This is true of every chain on this site, including chains whose per-step copy below reads as a data handoff.

Two-node debt-collection compliance workflow. Stage 1 checks a declared call log against the Regulation F 12 CFR 1006.14(b) 7-in-7 and post-conversation quiet-period rebuttable presumptions. Stage 2 checks a debt-validation-notice content-element checklist against 12 CFR 1006.34 / Model Form B-1 and computes the 30-day response-period math. Both stages run against DECLARED inputs: neither determines that harassment occurred or that a notice's disclosed amounts are accurate, and the 1006.14(b)(2) presumptions are rebuttable.

OpenChainGraph · 2 Nodes compliance mandate · Linear Hash-Anchored §4 Client-Side · Zero PII

Not a legal determination and not evidence that harassment occurred. Every call-log timestamp, notice element, and mailing date below is SUPPLIED by the user and treated as asserted: nothing is fetched, zero-egress by contract. This workflow attests the interval/checklist ARITHMETIC over those declared inputs. The Reg F 1006.14(b)(2) call-frequency presumptions are REBUTTABLE under 1006.14(b)(3); this pack does not evaluate rebuttal evidence. Read the Collections Compliance Guide before acting on a receipt.

Workflow Stages · 2 Nodes · Linear

1 ROOT node

Reg F Call-Frequency Presumption Validator art-402-validate-regf-call-frequency

Checks the declared call log against the 7-in-7 and post-conversation quiet-period presumptions per debt. Per-debt findings feed forward to Stage 2's notice review for the same collections file.

MCP Call · validate_regf_call_frequency

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "validate_regf_call_frequency",
    "arguments": {
      "inputs": {
        "timezone_offset_minutes": 0,
        "calls": [
          {"timestamp": "2026-07-01T09:00:00Z", "debt_id": "DEBT-1", "connected": false},
          {"timestamp": "2026-07-07T09:00:00Z", "debt_id": "DEBT-1", "connected": true}
        ]
      }
    }
  },
  "id": 1
}

↓

2 FINAL node

Debt Validation Notice Completeness Checker art-403-check-debt-validation-notice

Checks the validation-notice element checklist against 12 CFR 1006.34 / Model Form B-1 and computes the 30-day response-period math from the declared mailing date, completing the collections compliance review.

MCP Call · check_debt_validation_notice

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "check_debt_validation_notice",
    "arguments": {
      "inputs": {
        "notice_elements": [
          {"element": "debt-collector-name", "status": "complete"},
          {"element": "itemization-date", "status": "complete"}
        ],
        "notice_mailed_date": "2026-07-01",
        "mailing_assumption_days": 5,
        "itemization_date": "2026-06-15"
      }
    }
  },
  "id": 2
}

Question: Our dialer placed a call each day for a week on one debt. Does the log trip the seven-in-seven frequency presumption? Run the AINumbers MCP tool `run_chain` with {"chain":"collections-compliance-pack"} and read `art-402-validate-regf-call-frequency.debts_with_seven_in_seven_presumption`. Re-run with `inputs` for `art-402-validate-regf-call-frequency`, reusing the values that result echoed, with `inputs` changed so an eighth call lands on 2026-07-07. Compare the same field. Verify: call `verify_execution_hash` (https://mcp.ainumbers.co/mcp) with `claimed_hash` set to `composite_execution_hash` and the full `composite_artifact`. Ledger, for a human re-check: https://ledger.ainumbers.co/ PII rule: send synthetic or anonymised inputs only. The MCP server runs these kernels and logs no payloads. Chain page: https://ainumbers.co/chaingraph/chains/collections-compliance-pack.html

Collections Compliance Pack

Ask your agent