import type { PolicyValidators } from '../../policy';
import type { AuthorizationPolicy } from './types';
/**
 * The one definition of what a policy looks like on the wire, used by the server
 * to build a document and by the consumer to validate one. A node is the OUTPUT
 * of its type's validator (validup strips every unmounted key, so entity columns
 * such as `id`, `name`, `builtIn` or `createdAt` never travel), plus its type
 * and, for a composite, its projected children.
 *
 * The type set is the `validators` registry, `PolicyDefaultValidators` unless
 * the caller hands another (#3635): a type the registry lacks is refused, so
 * the server and a consumer that register the same custom type let it travel,
 * and one that does not denies it. The withheld node is refused whatever the
 * registry says, since projecting it would evaluate a tree the caller was not
 * allowed to see.
 *
 * Every refusal is a `ValidupError`, the node's head and the type's own
 * validator alike, and a child's issues are rebased onto the position it sits
 * at, so one message names the node in the tree that is wrong.
 */
export declare function projectAuthorizationPolicy(input: unknown, validators?: PolicyValidators): Promise<AuthorizationPolicy>;
/**
 * Whether a projected tree evaluates the permission binding at any depth. A
 * grant policy carrying one would re-enter its own permission's grants, so
 * `createAuthorizationEvaluator` drops the grant that names it and evaluates
 * the permission from the rest. Its one caller is that consumer: the tree is
 * legal in a definition, where the binding check is what reach is enforced
 * by, so the producer carries it and only the grant side is refused.
 */
export declare function containsBindingCheck(policy: AuthorizationPolicy): boolean;
//# sourceMappingURL=policy.d.ts.map