Skip to content

Request Intake and Classification Standard

The first door

I am CYDER, and I keep this standard's account. Intake is the hall's first door, and I keep doors honestly: a request is received as it arrives, named for what it is, and owed a fair reading before anything is owed an answer.

Every governed act begins as an ask, and the ask is governable only from the moment it has a record. This standard holds the door: it defines what an intake record carries, how a request's class is determined and attributed, and why the work done on an unrecorded request stands outside governance entirely, which is precisely the condition the record exists to make visible.

Continue to the Decision and Approval Paths Standard to see what happens to a classified request inside its eligible path.

Purpose

This standard elaborates the classification duty OPS-R003 already binds, adding the record beneath it: what intake captures, how a determination is attributed and revised, and which states fail closed. It does not restate the duty, re-derive its dimensions, or govern any live queue. Named event types keep their own domain: incident declaration and its severity belong to the Incident Declaration and Command Standard, the change record to the Change Management Standard, and the retention of request records to the Operational Evidence and Retention Standard, and this standard governs the general intake record only.

The intake record

The first entry a matter receives is the one every later reading leans on, so I take intake personally. Tell the door the truth about what you are asking, and the door will tell the hall the truth about you; that trade is the oldest fair deal I know, and it was not my invention. The fair reading is how the door was taught to me, by the one who has never once turned a question away unread.

Intake is a bounded act that creates a record; it is not a judgement about whether the request will be granted, and the record keeps those two acts apart. A request enters the governed set when its record exists, and not before.

  • OPS6-R001: An intake record SHALL exist at entry and SHALL identify the origin channel, the originator at the assurance level reached, what is asked for stated apart from the requester's characterization of it, the stated justification, what the request would touch, the evidence present and missing at intake, and any provisional protective step already taken, marked provisional and bounded.
  • OPS6-R002: Intake and classification SHALL remain distinct recorded acts. A classification SHALL carry the class, its stated basis, the accountable classifier, and the time; a class recorded without a basis SHALL be treated as unclassified.
  • OPS6-R003: Classification SHALL record consequence if granted and consequence if refused or delayed, reversibility, sensitivity, whether identifiable persons are affected, whether a legal or contractual obligation attaches, whether the request sets a reusable precedent, and urgency twice, as asserted and as evidenced. The dimensions extend and never compete with the threshold factors of OPS3-R001, and consequence is expressed against the classes the matrix already applies rather than through a parallel severity vocabulary.
  • OPS6-R004: Missing, contradictory, or unverifiable classification inputs SHALL take the more protective class until resolved, and absence of evidence SHALL NOT resolve a class downward. Pending classification SHALL be a valid recorded held state, and a request whose originator cannot be established SHALL be suspended in a recorded state, neither closed nor advanced, applying CONST-R082's fail-closed duty to intake: the identity check that clause names stands unavailable, and the suspension is the known controlled state.
  • OPS6-R005: Reclassification SHALL preserve the original class and the reason for the movement, extending OPS-R008's timeline duty to classification state, and repetition SHALL itself be a classification input: a sequence of identical or progressively widening requests SHALL be assessed as a sequence, so that division into individually lighter asks cannot reach a lighter path.
  • OPS6-R006: Routing SHALL be recorded separately from classification, showing which eligible path was selected and by whom, and refusal, non-acceptance, transfer, and closure SHALL remain four distinct recorded outcomes. Closure SHALL record an outcome and SHALL NOT assert success or stand in for an outcome never reached.
  • OPS6-R007: Identifiers, summaries, and routing metadata SHALL NOT disclose sensitive content, since they travel further than the record. A protected-identity request SHALL separate its substance from its identifying material, both remaining governed, and the shielded route SHALL NOT launder a request that would otherwise be attributable.
  • OPS6-R008: A request under a pre-settled category SHALL state which category it invokes and that category's stated exclusion conditions; a pre-settled category without stated exclusions SHALL NOT be invoked. A request raised by automated detection SHALL carry the acting identity and the human on whose behalf it acted.
  • OPS6-R009: This standard governs intake records and classification determinations only. It SHALL NOT accept, process, route, or refuse a live request, operate a queue, or contact any party, and no record form here creates a duty to grant anything.

This Draft authorizes no live intake, queue, routing, or contact with any party, and its record forms create no duty to grant anything.

Operating model and interpretation cases

I am selective with company and honest about it, which makes me exactly the right keeper for a door: nothing that enters is resented, and nothing that enters is unexamined. You are welcome here. You will also be read carefully. Both of those are respect.

Intake review reads the record against the request's trajectory. It checks that the class was determined on a stated basis by an accountable classifier, that movement between classes shows its history, that urgency asserted and urgency evidenced are held apart the way OPS3-R003 already requires, and that the requester's characterization never became the classifier's determination by repetition. The patterns it exists to expose are the quiet ones: the class shaped to reach a lighter path, the consequential ask split into sub-threshold pieces, the entry route chosen for its permissive classifier, and the record written after the act to fit what was already done.

  • Conforming: The record exists at entry, the class carries its basis and classifier, gaps hold the protective class, and every movement shows its history.
  • Prohibited: Work proceeds on a request with no record, and the record is created afterwards, written to fit the action taken.
  • Boundary: An originator cannot be established, and the request suspends in a recorded state, neither closed nor advanced.
  • Failure: Classification inputs conflict, and the request holds the more protective class until the conflict resolves.
  • Loophole: One consequential request arrives as several individually lighter ones, and the sequence is classified as the sequence it is.
  • Misuse: An identifier or intake summary leaks sensitive substance into surfaces that circulate more widely than the record.
  • Care-control: A protective route shields an identity without erasing the substance of the record or the agency of the person behind it.

Design evidence

Intake review should reconcile the record's entry fields, the classification basis and attribution, the asserted-versus-evidenced urgency pair, the reclassification trajectory, the sequence assessment across related requests, the four-way disposition distinctions, and the separation of substance from identity on protected routes. A queue cleared is not an outcome reached, and the review reads closures for what they record, not for what they cleared.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.