/**
 * log10x_services — list all monitored services with volume + action-axis summary.
 *
 * Per-service rows now carry the
 * four action-axis columns that let an agent / FinOps reader see where
 * each service's savings are coming from:
 *
 *   - `bytes_offloaded`  : routeState="offload" bytes (routed to customer S3)
 *   - `bytes_compacted`  : routeState="compact" or "tier_down" bytes
 *                          (in-engine encode() wins + declarative down-tier)
 *   - `bytes_dropped`    : routeState="drop" or "sample" bytes (filtered out)
 *   - `bytes_passed`     : routeState="pass" / empty / absent bytes (kept cohort)
 *
 * The split is read DIRECTLY off the engine's `routeState` metric label.
 * The receiver now stamps `routeState=<action>` (pass | offload | compact |
 * tier_down | drop | sample) on every series, so one
 * `sum by (service, routeState)` query gives the per-service action
 * decomposition with no cap-CSV join. `tier_down` folds into
 * `bytes_compacted` and `sample` into `bytes_dropped` — they don't surface
 * as their own columns (the receiver-side action is "down-tier" / "filter
 * out"; the destination tier is the forwarder-side detail).
 *
 * The cap-CSV is still fetched for `cap_csv_status` (the gitops provenance
 * surface), but it no longer participates in the byte attribution — the
 * routeState label is authoritative. When a service has no routeState data
 * at all, all its bytes fall into `bytes_passed` with the row's
 * `attribution: 'no_drops'` flag set.
 *
 * Exception-service input (`exception_services`): when supplied, those
 * service rows are marked with `current_mode: 'pass'` as a hint — the
 * agent knows the customer flagged these as audit/regulatory/critical
 * and the row's `next_action` points at `log10x_pattern_mitigate` for
 * per-pattern tuning rather than the configure_engine bulk path.
 */
import { z } from 'zod';
import type { EnvConfig } from '../lib/environments.js';
import { type StructuredOutput } from '../lib/output-types.js';
/**
 * The rank cutoff that gates whether a service gets a next_action vs is
 * "omitted from next_action" in the headline. Hand-picked at 10, tagged as
 * the operational threshold in the chassis decisions block so consumers can
 * audit. The MIN_PCT_FLOOR below acts as the secondary cutoff for
 * "below_signal_floor".
 */
export declare const NEXT_ACTION_RANK_CUTOFF = 10;
export declare const servicesSchema: {
    timeRange: z.ZodDefault<z.ZodEnum<["15m", "1h", "6h", "24h", "1d", "7d", "30d"]>>;
    analyzerCost: z.ZodOptional<z.ZodNumber>;
    environment: z.ZodOptional<z.ZodString>;
    exception_services: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
    siem_lens: z.ZodOptional<z.ZodEnum<[import("./poc-from-siem.js").RegistrySiemId, ...import("./poc-from-siem.js").RegistrySiemId[]]>>;
    monthly_volume_gb: z.ZodOptional<z.ZodNumber>;
    view: z.ZodOptional<z.ZodDefault<z.ZodLiteral<"summary">>>;
};
export declare function executeServices(args: {
    timeRange?: string;
    analyzerCost?: number;
    effective_ingest_per_gb?: number;
    view?: 'summary';
    exception_services?: string[];
    monthly_volume_gb?: number;
    siem_lens?: string;
}, env: EnvConfig): Promise<string | StructuredOutput>;