import { z } from 'zod';
export declare const visibility: z.ZodEnum<{
    customer: "customer";
    internal: "internal";
}>;
export type Visibility = z.infer<typeof visibility>;
/**
 * One attachment's metadata fact (#473) — the row the kernel writes into the scope's
 * `_substrat_attachments` spine when bytes land in the platform blob store. The row and
 * the object are two halves of one thing: the row lives INSIDE the scope database (so
 * `scope pull` / restore / PITR carry it like any other scope fact), the bytes live in
 * the platform-minted per-tenant blob store under a key derived from `(scopeId, id)`.
 *
 * `sha256` is the integrity witness across that split: bytes are hashed at upload and
 * written once under a fresh ULID key, so a row can never point at bytes other than the
 * ones it was born with — after a PITR rewind the worst case is an orphaned object
 * (harmless, GC-able), never a row silently re-pointed at different content.
 */
export declare const attachmentRecord: z.ZodObject<{
    id: z.ZodString;
    entity: z.ZodObject<{
        entityType: z.ZodString;
        entityId: z.ZodString;
    }, z.core.$strip>;
    filename: z.ZodString;
    contentType: z.ZodString;
    size: z.ZodNumber;
    sha256: z.ZodString;
    visibility: z.ZodEnum<{
        customer: "customer";
        internal: "internal";
    }>;
    createdBy: z.ZodString;
    createdAt: z.core.$ZodBranded<z.ZodString, "Instant", "out">;
}, z.core.$strip>;
export type AttachmentRecord = z.infer<typeof attachmentRecord>;
/**
 * The spine events attachment mutations emit (#473) — kernel-emitted, fat payload (the
 * full `attachmentRecord`), so a consumer (a timeline projection, attachment GC) never
 * needs a cross-module read. `entity` on the envelope is the OWNING entity, so timelines
 * project attachments onto the entity they document.
 */
export declare const ATTACHMENT_ADDED = "attachment.added";
export declare const ATTACHMENT_REMOVED = "attachment.removed";
//# sourceMappingURL=attachments.d.ts.map