/**
 * Client-side validation for the AWS Lambda adapter.
 *
 * The cloud-agnostic config-shape validation (`validateDistributedRenderConfig`,
 * `validateVariablesPayload`, `InvalidConfigError`) lives in
 * `@hyperframes/producer/distributed` and is shared with the other adapters.
 * This module re-exports those and adds the one piece specific to Step
 * Functions: the 256 KiB Standard-workflow execution-input size cap.
 */
export { InvalidConfigError, validateDistributedRenderConfig, validateVariablesPayload, } from "@hyperframes/producer/distributed";
/**
 * Hard cap on Step Functions Standard workflow execution input — 256 KiB per
 * the AWS limits page. Express workflows cap at 32 KiB; the render stack runs
 * Standard for execution-history visibility, so the larger limit applies. The
 * cap is on the entire serialized input, not just the variables, because
 * users hit it at the wire boundary regardless of which field caused the
 * bloat.
 *
 * Specific to Step Functions Standard. Other workflow runtimes (Temporal,
 * Express SFN, Cloud Workflows, raw Lambda invoke) have different caps; don't
 * reuse this constant for those without confirming the limit.
 */
export declare const MAX_STEP_FUNCTIONS_INPUT_BYTES: number;
/**
 * Validate that the serialized Step Functions execution input fits inside the
 * 256 KiB Standard-workflow cap. Measured in UTF-8 bytes (the format Step
 * Functions uses on the wire) — JS strings count UTF-16 code units, which
 * under-reports for any multi-byte character.
 *
 * Throws {@link InvalidConfigError} with a clear message naming the actual
 * byte count, the cap, and a pointer to the "working with large variables"
 * docs section, so users hit the limit at the SDK boundary with actionable
 * guidance instead of as a `States.DataLimitExceeded` 50 ms into the
 * execution.
 */
export declare function validateStepFunctionsInputSize(input: unknown): void;
//# sourceMappingURL=validateConfig.d.ts.map