/**
 * Lexicon OKF knowledge bundle (#1060, epic #1057) — projects a packaged
 * lexicon's resource-type registry and lint rules into an Open Knowledge
 * Format v0.2 bundle, emitted alongside the other build artifacts
 * (`dist/meta.json`, `dist/types/`) as `dist/okf/`.
 *
 * Vocabulary, resolved against the project bundle (#1058, ../okf.ts): there a
 * concept's `type` IS the entity's resource type; here `type` is the concept
 * *category* — `resource-type`, `lint-rule`, `post-synth-check` — and the
 * resource type string rides in `resource_type`. A consumer tells the two
 * bundle kinds apart by exactly that.
 *
 * Cross-links run both directions: a resource concept lists the rules that
 * govern it under "Governed by", a rule concept lists the types it applies to
 * under "Applies to". The association is derived from the rule's source text
 * (rules match on identifiers, not declared type lists), so it is a textual
 * over-approximation — acceptable for knowledge, wrong for enforcement.
 */
import { type OkfFile } from "../okf.js";
import type { ScannedRule } from "./docs-rule-scanning.js";
export interface LexiconOkfInput {
    /** Lexicon name as the manifest states it, e.g. "aws". */
    name: string;
    /** The registry JSON — the exact content of `dist/meta.json`. */
    registry: string;
    /** The generated declarations — the content of `dist/types/index.d.ts`. */
    typesDTS: string;
    /** Scanned rules with their sources, for metadata and type association. */
    rules: ScannedRule[];
}
/**
 * Build the OKF bundle for a packaged lexicon. Pure and deterministic: the
 * same registry, declarations, and rules yield byte-identical files.
 */
export declare function buildLexiconOkfBundle(input: LexiconOkfInput): OkfFile[];
//# sourceMappingURL=okf-lexicon.d.ts.map