/**
 * AttributionResolver — read-side resolver for the burn-detection system.
 *
 * Phase 2 of docs/specs/token-burn-detection-and-self-heal.md.
 *
 * Pure function: given the shape of a TokenLedger event (sessionId, cwd,
 * prompt text, model) returns an attribution_key suitable for grouping
 * "calls of the same structural origin." Used by the Phase 3 BurnDetector
 * to populate attribution_key for events the Phase 1 chokepoint did NOT
 * write directly — chiefly the dominant Claude-CLI path where the JSONL
 * trail carries the prompt and cwd but no source-side label.
 *
 * Authority shape: this is signal-only. It does not gate, throttle, or
 * decide anything. It maps event → key. The detector emits, the
 * Remediator decides. See umbrella spec §"Signal-vs-Authority Decomposition".
 *
 * No I/O, no time-dependent behavior — deterministic for tests + reasoning.
 */
/**
 * Sentinel attribution key meaning "the resolver has NEVER run on this event."
 *
 * This is the column DEFAULT and the historical hardcoded value the ingest
 * path wrote before Phase 2 was wired. It is NOT a resolution outcome —
 * `resolveAttribution()` never returns it (it always resolves to a manifest,
 * job, hook, sessionId-prefix, or `unknown::no-session` key).
 *
 * The distinction matters for burn detection: a bucket sitting at 100% of
 * spend under THIS key means "we don't attribute anything yet" (a coverage
 * gap), not "one component is burning." Per the umbrella spec
 * (docs/specs/token-burn-detection-and-self-heal.md §"Threshold logic"), the
 * BurnDetector must treat this sentinel as a coverage signal and never let it
 * trip the absolute-share trigger. The genuinely-residual `unknown::<sid>`
 * key (resolver ran, found no match) is a real signal and still triggers
 * normally.
 */
export declare const PRE_ATTRIBUTION_KEY = "unknown::pre-attribution";
export interface AttributionEvent {
    sessionId: string;
    /** cwd / projectPath field from the JSONL line. */
    projectPath?: string | null;
    /** The user prompt that triggered the assistant response. Optional — when missing, resolver falls back to cwd / unknown. */
    prompt?: string | null;
    /** Model string from the JSONL line (`message.model`). */
    model?: string | null;
}
/**
 * Resolve an attribution_key for an event.
 *
 * Resolution order:
 *   1. Manifest entry that matches the prompt (with optional cwd / model
 *      narrowing) → `<component>::<promptFingerprint>`.
 *   2. cwd-based scheduled-job inference — if the cwd contains a path
 *      segment like `.instar/jobs/<name>`, return `user-job:<name>`.
 *   3. cwd-based user-extension inference — if the cwd contains
 *      `.claude/hooks/` or `.instar/hooks/`, return the hook filename.
 *   4. Fallback: `unknown::<sessionId-prefix>`.
 *
 * The prompt-based check is intentionally first: it's the most informative
 * signal for the bleed-detection use case (one prompt shape running tens
 * of thousands of times). cwd-based inference is the secondary signal for
 * cases where the prompt is variable but the source is recognisable.
 */
export declare function resolveAttribution(event: AttributionEvent): string;
//# sourceMappingURL=AttributionResolver.d.ts.map