Markings

A clearance key is one fact about a person, such as a citizenship, a completed training or a clearance level, and it can lapse after a period you set. A marking names the keys a reader must all hold and, optionally, the network ranges a request must come from. Markings come in families with ranks, so a higher rung always asks for everything a lower one does. A starter set (ITAR, EAR, CUI and Proprietary, with the keys they need) ships switched off, for you to adjust or replace.

A marked page lives only in a space that already carries its marking, or a higher one in the same family. Where several markings apply, the strictest wins.

Anyone who can edit a page can mark it, and a space's managers can mark the space. Lowering or removing a marking is the security officer's act alone, with a typed reason.

The security officer is a role of its own, which the same person can hold beside instance administration on a small team. Nobody can grant clearance to themselves, and every mark, unmark, grant and change of the catalogue is in the audit log.

Someone without the keys sees nothing: the marked place answers exactly as a place that does not exist, on every surface. A cleared reader sees a banner and a chip naming the marking.

Marked content never goes out through a public link, a template, a notification body, an outbound connector, a feedback screenshot or a search snippet. Export and print are each marking's own setting, and everything a cleared reader exports or prints carries the marking line.

Enforcement comes in three steps the security officer moves forward: off, recording (log who would be refused, hide nothing), then enforcing. Turning enforcement off again needs a script on the host.

Every delivery of marked content is recorded: the page read, the editor, a version, an export, the print view and a file. Each row says who, what, which markings the place carried at that moment, and the client address, with a count for each person, place and day. Refused attempts are recorded too, an agent's included.

The application has no way to edit or delete a row, and the log is kept. The security officer filters it by person, marking and outcome, and one report lists reads of content that carried a marking then and carries none now.

A rule-based pass reads the shared nexuses whose admins opt in, looking for signs people already write into their documents: USML category references, ECCN-shaped strings, distribution statements and the names of the regimes. What it finds is a suggestion in the review queue, with the sentence it found, and the security officer applies or dismisses it with a note.

An optional model pass reads only unmarked content, only on endpoints you run, serving models on an allowlist the security officer keeps. No model ever applies, lowers or removes a marking. The queue says what was scanned and decided, and never that a space holds nothing to find.

A space imported from another instance arrives marked Unreviewed import, with a deadline the security officer sets. The space's managers and the officers are warned in the notification bell before it passes. Once it passes, with enforcement on, only the reviewers the officer clears can read the space until it is reviewed.

A marking a transfer carries that your instance does not define is shown on the pages, not enforced, until the security officer maps it to one of yours.

Every marking already applied stays enforced, the access log keeps recording, and the security officer can still lower a marking or end a clearance. New markings, new catalogue entries and new grants wait until a licence is added again.

Markings control what the server delivers. They cannot stop copy and paste, a screenshot or retyping, and clearance is only as accurate as the people who maintain it. Markings is a set of mechanisms, not a certification: whether it meets your obligations is a question for you and your advisers.