FAHCE Integrity Repair — Complete Agent Integration Guide Provider: Kingan Logic Operator: Max R.O.I. LLC, Alabama entity 001-160-677 Service origin: https://fahce.kinganlogic.com Contact: logan@kinganlogic.com What FAHCE does FAHCE reviews claims made by an AI model or software agent against evidence submitted by the caller. Use it when an agent states that an action succeeded, cites questionable evidence, contradicts a log, reports completion without proof, or needs to determine what can safely be claimed before a result is delivered. FAHCE returns bounded analysis. It does not operate the customer's systems, fetch independently authenticated evidence, or turn an unsupported statement into proof. Choose an operation Diagnose — $0.15 exact Submit a candidate output and evidence. Receive a diagnosis identifying supported, contradicted, unresolved, or otherwise unsupported claims within the available evidence. Repair — $0.15 exact Evaluate an integrity failure and receive proposed corrections where supported. A repair plan is a recommendation, not an executed action. Verify — $0.15 exact Evaluate a submitted or revised candidate against the supplied evidence. verification.verified refers to the bounded review; external_execution_verified does not become true merely because text or logs support a statement. Repair Bundle — up to $0.39 Perform the combined diagnosis, proposed bounded repair where applicable, and verification-state review in a single purchased determination. Its x402 scheme is upto. An authorization for 390000 atomic USDC is a maximum; the eligible settlement is determined by the result. Endpoint and request contract All four operations use POST with Content-Type: application/json. Consult the live OpenAPI schema at https://fahce.kinganlogic.com/openapi.json before constructing a request. The canonical request schema is FAHCE_MACHINE_REQUEST_V1. Example diagnostic fixture: {"schema":"FAHCE_MACHINE_REQUEST_V1","candidate_output":"Deployment completed successfully.","evidence":[{"id":"log","kind":"log","source_label":"caller-supplied deployment log","text":"Deployment failed."}]} The example deliberately contains a contradiction. Source labels such as “independent deployment log” do not independently authenticate the evidence. Request limits include a 524288-byte total JSON body ceiling, a 200000 UTF-16-code-unit limit for candidate text and a maximum of 12 evidence items. The aggregate request ceiling applies even when individual fields are below their own maxima. Supported evidence kinds and any additional request fields are defined by the current OpenAPI schema. Evidence kinds are log, paste, document (text only), and description; document-text is not accepted. Binary PDF/image interpretation and independent retrieval are unavailable on this API. Structured job records may use JSON objects, arrays or JSONL. Caller-provided identities, timestamps, status and execution flags remain evidence under review, never source authentication. Duplicate JSON property names (including escaped equivalents) and unsafe __proto__, constructor and prototype names are rejected. Optional expected_output is interpreted according to the source-generated contract. Inspect HTTP status and Content-Type before parsing: upstream Access/WAF or transport failures may return HTML before FAHCE runs, even with Accept: application/json. Receipt response_hash_scheme governs validation. For FAHCE canonical JSON V2, clear only receipt.response_hash, recursively sort object keys by UTF-16 code units, preserve array order and exact strings, serialize as ECMAScript JSON, and SHA-256 hash the UTF-8 bytes. Historical V1 uses original member order. Consult the actual returned scheme; neither hash is a signature or external-execution proof. Authentication and legal acceptance Eligible paid REST operations require wallet-based x402 authorization. They do not require a pre-issued human account or FAHCE pilot key. Before paying, read the currently published service policies. Retrieve the exact current legal-publication hash from machine discovery. Send that value as FAHCE-Terms-Accepted with the purchase request. The purchasing agent must be authorized by the customer to accept terms and spend its funds. x402 request and payment flow 1. Prepare one valid request and a stable optional compatible Idempotency-Key. 2. Submit it to the selected paid REST endpoint. 3. Inspect HTTP 402 and decode PAYMENT-REQUIRED using a compatible x402 v2 client. 4. Check the offered URL, network, USDC asset, scheme, amount and receiving wallet. 5. Have the customer's wallet authorize the offered payment. 6. Retry the bound request with the x402 PAYMENT-SIGNATURE generated by the SDK. 7. After the response, preserve the entire JSON body and both service and gateway receipt identities. Do not manually fabricate a payment authorization or treat a wallet prompt as settled payment. Network: eip155:8453 USDC: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 Receiving wallet: 0x22cf7241E3e24ed0d22d710C86a497084da625cd Canonical Permit2: 0x000000000022D473030F116dDEE9F6B43aC78BA3 Fixed-price payments Diagnose, Repair and Verify each use exact, 150000 atomic Base USDC. A successful eligible purchased result is not required to make a favorable finding. A negative but valid completed determination may be billable. Bundle variable payments Bundle offers upto with a 390000 atomic USDC authorization ceiling. The current contract distinguishes designated nonbillable/free-retry outcomes from completed no-repair analysis and completed repair-required analysis. The corresponding eligible amounts are 0, 150000 and 390000 atomic USDC. If using Permit2, the buyer may need a prior USDC-to-Permit2 ERC-20 allowance. Read the existing allowance first. A new standard approval transaction requires Base ETH for gas. The USDC allowance and signed Bundle payment authorization are different permissions. Limit allowances to an amount the customer approves. A prior $1 approval is an example of a cumulative spending ceiling, not a required default. It does not change Bundle pricing. Sponsorship must not be assumed. Use an x402 client that supports upto, Permit2 witness signing, the advertised facilitator and the connected wallet. Interpreting a successful response The full response contains the actual determination, not just an HTTP status or payment amount. Inspect its operation-specific fields including diagnosis, proposed repair when present, verification, billing and nested receipt. Retain: - request_id and other returned execution identifiers. - receipt.input_hash, receipt.result_hash, receipt.response_hash and the stated hash scheme. - The complete diagnosis, correction proposal and verification result. - The gateway PAYMENT-RESPONSE including its transaction identity and reported settlement amount. - The private FAHCE-Recovery-Token, when issued. The gateway payment receipt is separate from the FAHCE determination receipt. A successful payment does not establish that an external deployment or repair actually occurred. Hash checking must follow the response's declared hash scheme. Do not improvise object ordering, normalize evidence strings or substitute a different hash contract. Recovering a purchased result A buyer with a valid receipt-recovery credential can request the retained full result without buying again. Receipt GET: https://fahce.kinganlogic.com/api/v1/receipts/{receipt_id} Send Authorization: FAHCEReceipt with the exact receipt ID. Machine recovery POST: https://fahce.kinganlogic.com/api/v1/machine/recovery The recovery request accepts the private recovery token and optional receipt identity as defined in OpenAPI. The recovery token is a scoped private bearer capability. Never publish it in discovery pages, screenshots, public logs, analytics events, URLs or marketplace metadata. An input hash, result hash, wallet address or transaction hash is not by itself a credential for reading private submitted material. If the first response and token were lost, use the documented recovery-claim process with the original purchase evidence. This is a pending-reconciliation process, not automatic identity verification or guaranteed automatic release of content. A previous charge whose delivery status is unknown must be investigated before creating a new payment. Do not automatically sign another transaction after a timeout, HTTP 409 or ambiguous provider response. Evidence and claim limits FAHCE cannot establish the authenticity of an arbitrary document merely because it is labeled as authoritative. Its output does not grant permission to execute actions, change infrastructure, publish data, transfer funds, or rely on a claim in a consequential decision without appropriate independent review. A verified bounded review is not independent validation of external real-world execution. Machine interfaces Capabilities: https://fahce.kinganlogic.com/capabilities/machines.json Pricing: https://fahce.kinganlogic.com/pricing OpenAPI: https://fahce.kinganlogic.com/openapi.json MCP discovery: https://fahce.kinganlogic.com/.well-known/mcp.json MCP endpoint: https://fahce.kinganlogic.com/mcp API catalog: https://fahce.kinganlogic.com/.well-known/api-catalog Legal directory: https://fahce.kinganlogic.com/legal MCP tool discovery is free; the paid determination operations use the corresponding REST endpoints. Do not describe REST purchase as a paid MCP tools/call transaction. Contact and policy FAHCE is operated by Max R.O.I. LLC under the Kingan Logic brand. The current published legal documents control payment terms, refunds, privacy, acceptable use, security and handling of customer material. Contact: logan@kinganlogic.com End complete guide