/**
 * 🤝 THE VERIFICATION RECEIPT — turn any one-way Melete certificate into a TWO-PARTY trust record.
 *
 * Every certificate in the stack is a one-way proof: an ISSUER (an AI vendor, a bank, a deployer) signs a property
 * about their own system. But trust is two-sided — the people who need that proof are a VERIFIER (a regulator, an
 * auditor, a customer, a counterparty agent), and today they have no signed record that they independently checked
 * it. This closes the loop: the verifier re-derives the issuer's certificate OFFLINE (no trust in the issuer), then
 * signs a Verification Receipt binding their own verdict to the exact certificate hash with their OWN key. Now BOTH
 * sides hold a cryptographic artifact — the issuer proved it, the verifier confirmed it — and anyone can check the
 * whole two-party chain offline. It is independence-checked (issuer key ≠ verifier key) so a vendor cannot
 * rubber-stamp itself, and it works across EVERY certificate kind in the stack.
 *
 * WHO BENEFITS (≥2 parties, by design): ① the ISSUER gets a portable, counter-signed attestation that a named third
 * party verified their claim — worth more than a self-signed cert to a buyer/regulator; ② the VERIFIER gets an
 * offline-checkable record that protects them (they can prove WHAT they verified and WHEN, and that it wasn't
 * tampered since). Neither has to trust the other; the signatures + re-derivation do the work.
 *
 * (DIAKRISIS — MEASURED: a receipt over a genuine certificate verifies; the receipt is BOUND to that exact
 * certificate [pairing it with a different cert is rejected]; a tampered/forged certificate yields a REJECTED
 * verdict, and a forged "VERIFIED" receipt over a bad certificate is caught on re-derivation; issuer≠verifier
 * independence is enforced; it works across multiple certificate kinds. HONEST: the receipt attests that the
 * verifier re-ran the SAME deterministic offline check the certificate already supports — it inherits that check's
 * scope, it does not add new statistical power; "independent" means a different key, not a different methodology.)
 */
import { type KeyObject } from "node:crypto";
interface SignedCert {
    standard: string;
    payloadHash: string;
    signature: string;
    publicKeyPem: string;
    [k: string]: unknown;
}
type VerifyFn = (cert: any) => {
    ok: boolean;
    reason: string;
};
export interface VerificationReceipt {
    standard: "melete-verification-receipt/v1";
    certStandard: string;
    certHash: string;
    issuerFingerprint: string;
    verifierFingerprint: string;
    independent: boolean;
    verifierVerdict: "VERIFIED" | "REJECTED";
    reason: string;
    verifiedAt: number;
    payloadHash: string;
    signature: string;
    publicKeyPem: string;
    algo: "ed25519+sha256";
}
export declare function issueVerificationReceipt(opts: {
    cert: SignedCert;
    certStandard?: string;
    verify: VerifyFn;
    verifierKeys?: {
        publicKey: KeyObject;
        privateKey: KeyObject;
    };
    verifiedAt?: number;
}): VerificationReceipt;
export declare function verifyVerificationReceipt(opts: {
    receipt: VerificationReceipt;
    cert: SignedCert;
    verify: VerifyFn;
}): {
    ok: boolean;
    reason: string;
};
export declare function receiptGauntlet(): {
    score: 0 | 100;
    checks: Array<{
        name: string;
        pass: boolean;
        detail: string;
    }>;
};
export {};
//# sourceMappingURL=receipt.d.ts.map