import type { AuthorityValidationResult, VerificationKeyResolver } from '../authority-delegation/types.js';
import type { LifecycleMappingOptions } from '../lifecycle-state/map.js';
import type { CompositeAuthorityResult } from '../lifecycle-state/types.js';
import { type ActivationAttestationV0, type ActivationConditionV0, type ActivationResult, type AttestorRoleResolver } from './types.js';
export interface ActivationVerificationInput {
    /** The condition gating the grant. Shape-checked; a malformed condition throws. */
    readonly condition: ActivationConditionV0;
    /** The `delegation_id` of the grant being evaluated. Checked against the condition's own
     *  `delegation_id`, so a condition for another grant produces a verdict rather than being
     *  silently applied to this one. */
    readonly delegationId: string;
    /** The instant the action is being authorized at. RFC 3339, offset required. */
    readonly actionInstant: string;
    /** Presented attestations, in presentation order. Absent or empty is the "nothing
     *  presented" case, which is `not_established` and never `not_yet_effective`. */
    readonly attestations?: readonly ActivationAttestationV0[];
    /** Resolves whether an attestor held a role. Required even for a date condition, so a
     *  caller cannot get a date answer and then discover the event path needs plumbing it does
     *  not have. */
    readonly resolveAttestorRole: AttestorRoleResolver;
    /** Resolves the key that signed an attestation, selected at the attestation's own
     *  `attested_at` rather than at verification time. Same resolver shape and the same
     *  historical-key discipline draft-03 section 2.4 states for delegations: the key current at
     *  verification time is not necessarily the one that signed this record. The `issuer`
     *  argument receives the attestation's `attestor`. */
    readonly resolveVerificationKey: VerificationKeyResolver;
    /** Exact bytes a presented attestation's signature covers.
     *
     *  Absent is the normal case: the module uses its own domain-tagged preimage
     *  (`activationAttestationSignatureInput`) and, because that preimage belongs to a record
     *  type it owns, REQUIRES `record_type` to be `ACTIVATION_ATTESTATION_TYPE`.
     *
     *  Supplied is the escape hatch for a model that accepts condition evidence in a shape this
     *  module does not own. Which bytes a signature covers is a property of a record type, and
     *  an SDK cannot dictate the signing convention of a record type it did not define. A caller
     *  using it must also declare `acceptedAttestationRecordTypes`, or the module has no stated
     *  basis for accepting the record at all. */
    readonly attestationPreimage?: (attestation: ActivationAttestationV0) => string;
    /** Which attestation record types the model accepts as evidence for this condition.
     *  Required when `attestationPreimage` is supplied. Membership is exact string equality. */
    readonly acceptedAttestationRecordTypes?: readonly string[];
}
/** Shape rules, each with the reason it exists. A condition that breaks one is a programming
 *  error at the caller, not a verdict about evidence, so this throws.
 *
 *  Exported so a caller can validate a condition it received before reaching a boundary. */
export declare function validateActivationCondition(condition: ActivationConditionV0): ActivationConditionV0;
/**
 * Decide whether an activation condition is established for one action at one instant.
 *
 * Three verdicts are reachable and `invalid` is not one of them:
 *
 * | situation                                                    | verdict             |
 * |--------------------------------------------------------------|---------------------|
 * | condition established at or before the action instant         | `valid`             |
 * | established as not met at that instant, or first met after it | `not_yet_effective` |
 * | the verifier cannot tell                                      | `not_established`   |
 *
 * NOT ESTABLISHED IS NOT THE NEGATION OF THE CLAIM. It says the verifier could not reach a
 * conclusion and names which establishment limb was missing. `not_yet_effective` says the
 * verifier DID reach a conclusion and it was negative; its remedy is to wait, where
 * `not_established`'s remedy is a better source. Collapsing the two throws away a decidable
 * answer the verifier already had.
 *
 * NO RETROACTIVE ACTIVATION, KEYED ON THE CONDITION'S OWN INSTANT. A record putting the
 * condition's first occurrence after the action instant leaves that action
 * `not_yet_effective`, and the SAME record establishes the condition for any later action.
 * What the rule keys on is the condition's instant, not the instant someone wrote the record:
 * learning on Thursday that a condition was met on Monday is the normal case for any model
 * built around an after-the-fact determination, and under
 * `instant_basis: 'condition_occurrence'` such a record establishes the condition. A model
 * that reads it the other way says so with `instant_basis: 'attestation_written'`.
 *
 * ORDER OF RESOLUTION, and why contradiction sits above acceptance:
 *
 *   1. two accepted records that disagree      `not_established`, `CONDITION_EVIDENCE_CONFLICT`
 *   2. `threshold` records say occurred by it  `valid`
 *   3. `threshold` records say not occurred    `not_yet_effective`
 *   4. `threshold` records say occurred after  `not_yet_effective`
 *   5. some accepted, fewer than `threshold`   `not_established`, `ACTIVATION_THRESHOLD_NOT_MET`
 *   6. none accepted                           `not_established`, furthest rejection reason
 *
 * Contradiction is evaluated on PRESENCE, not on counts. Two acceptable records that disagree
 * leave the verifier unable to tell which holds, and neither is discarded in favour of the
 * other: preferring the later record, or the negative one, or a majority, would each be a
 * precedence rule the concept text does not state.
 *
 * This function reads no clock and makes no network call. `actionInstant` is a parameter.
 *
 * Proposed. Concept source: aeoess/agent-authority-lifecycle, invariant candidates CAND-04
 * and CAND-13 (activation half) and BROAD-L7. Not required by draft-pidlisnyi-aps-03.
 */
export declare function verifyActivation(input: ActivationVerificationInput): ActivationResult;
export interface ActivationCompositionOptions {
    /** Passed through to `mapAuthorityValidationToLifecycle` when the chain result is reported
     *  in the lifecycle vocabulary.
     *
     *  The contested reading lives here and stays the CALLER's. Both reference SDKs answer
     *  `invalid` with `NOT_YET_VALID` for a grant whose time facet `not_before` has not been
     *  reached, and that is what the chain result says. An activation-condition date at the same
     *  instant answers `not_yet_effective` here. One instant, two mechanisms carrying the wait,
     *  two answers, and the concept text does not say whether a waiting grant should be
     *  `invalid`, `not_yet_effective` or something else. This module does not settle it by
     *  default: the default keeps the chain verifier's own answer, and
     *  `notYetValidAsNotYetEffective: true` takes the other reading. */
    readonly mapping?: LifecycleMappingOptions;
}
/**
 * Report an activation result ALONGSIDE a chain result, never merged into it.
 *
 * Two stages, in order, and the order is the point:
 *
 *   1. Chain verification decides whether the grant is valid at the action instant. Its
 *      four-value result is returned untouched in `chain`.
 *   2. Activation is asked ONLY when the chain is valid. A grant that does not verify is not a
 *      grant that is waiting on a condition, and reporting `not_yet_effective` for a revoked
 *      or unparented grant would say the remedy is to wait when it is not.
 *
 * This is also where CAND-13's activation half lands. A pre-committed replacement grant is an
 * ordinary grant with an ordinary condition, so it needs no separate machinery here, and the
 * ordering is what keeps L1 intact: if the pre-committing instrument is revoked, the
 * replacement's chain is invalid and no activation evidence can make it exercisable. Nothing
 * in this module can turn an invalid chain into a `valid` lifecycle verdict.
 *
 * `activation` may be `null`, which is how a caller says no activation module ran. The
 * composite then carries only the chain's own reading.
 *
 * Proposed. Concept source: aeoess/agent-authority-lifecycle, invariant L1 and invariant
 * candidates CAND-04 and CAND-13.
 */
export declare function composeActivation(chain: AuthorityValidationResult, activation: ActivationResult | null, options?: ActivationCompositionOptions): CompositeAuthorityResult<AuthorityValidationResult>;
//# sourceMappingURL=verify.d.ts.map