E7041 Managing The Event Report Blocking Storage Control

---
name: e7041-managing-the-event-report-blocking-storage-control
description: "Manage which event reports a packet store refuses to keep under ECSS-E-ST-70-41C clause 6.15.4.7, where the storage-control configuration lists the event identifiers blocked from storage rather than the ones admitted. Use when the task is adding and deleting blocked event definitions per packet store and application process, refusing a store that carries no event-report storage-control configuration, refusing an identifier the mission holds as retention-mandatory, applying each instruction on its own so one rejection does not void the rest, and deciding whether an arriving event report is retained or dropped. Trigger: ecss, e-st-70-41c, event-report-blocking-storage-control, blocked-event-definition-storage, packet-store-storage-control, retention-mandatory-event, per-instruction-storage-rejection, event-report-retention-decision."
license: Apache-2.0
compliance: STANDARDS-REF
standards:
  - id: ecss
    reference-only: true
gated: false
domain: space-systems
pack: space-systems
compatibility: "agentskills.io SKILL.md; any SKILL.md host (Claude Code, Hermes, OpenClaw)"
metadata:
  domain: space-systems
  subdomain: ecss
  tags: [ecss, e-st-70-41-packet-utilisation-scope, e7041-managing-the-event-report-blocking-storage-control, event-report-blocking-storage-control, blocked-event-definition-storage, packet-store-storage-control, retention-mandatory-event, per-instruction-storage-rejection]
  version: 0.1.0
  author: Aero Agent Skills
---

# ECSS Packet Utilisation — Event Report Blocking Storage Control (space-systems/ecss/e7041-managing-the-event-report-blocking-storage-control)

Use when the task is the event report blocking storage-control
configuration of ECSS-E-ST-70-41C clause 6.15.4.7 -- the per-packet-store
configuration that decides which event reports a store declines to keep,
and therefore which events survive to be retrieved later.

## Domain quick reference

- The configuration is inverted, and this is the whole of its risk. It
  names what the store will not keep; everything not named is kept. An
  empty configuration is therefore a store that retains every event
  report reaching it, not a store that retains none, and a reviewer
  reading it as an admission list gets the retention picture exactly
  backwards.
- Blocking here is a storage decision, not a forwarding one. An event
  blocked from a store is still detected on board and can still be
  forwarded in real time; an event blocked from real-time forwarding is
  still stored. The two configurations are separate, live in separate
  services, and quieting a chattering event through the wrong one either
  loses the record or leaves the link just as loud.
- The configuration is held per application process inside each store.
  The same event identifier generated by two application processes is
  two independent entries, so blocking it once does not block it
  everywhere, and a census that collapses the identifier across
  processes overstates what has been suppressed.
- Some event definitions are retention-mandatory: the mission needs the
  on-board record whatever the downlink does with it. A request to block
  one is refused, and refused per instruction, so the remaining
  instructions of the same request still apply.
- Blocking an event in every store that serves its application process
  is the one outcome no single instruction reveals. Each instruction is
  individually legitimate; the aggregate leaves the event with nowhere
  to be retrieved from, so the aggregate is where that finding has to be
  raised.

## Workflow

1. Validate the packet stores: identifier, the application processes the
   store serves, whether it carries an event-report storage-control
   configuration at all, and the capacity of its blocked set.
2. Validate the event definitions: identifier in range, owning
   application process, severity, and whether the mission marks the
   definition retention-mandatory.
3. Walk the request instruction by instruction. An instruction naming an
   unknown store, an unknown event definition, an application process
   the store does not serve, or a store with no event-report
   storage-control configuration is rejected on its own.
4. For an add: reject an identifier already blocked, a retention-mandatory
   definition, or one that would push the blocked set past the capacity
   of the store. For a delete: reject an identifier that is not blocked.
5. Apply the accepted instructions to the configuration and report the
   resulting blocked set per store and application process, sorted so
   two runs of the same request compare.
6. Decide the disposition of an arriving event report against the
   resulting configuration: dropped when its identifier is blocked for
   its application process in that store, retained otherwise.
7. Aggregate: count accepted and rejected instructions, and raise a
   finding for any event definition now blocked in every store serving
   its application process.

## Pitfalls

- Reading an empty configuration as storing nothing. It stores
  everything; the list is of refusals.
- Confusing the storage-control block with the forward-control block.
  They suppress different hops, and using one for the other either
  silences the link while filling the store or empties the store while
  the link stays loud.
- Treating an event identifier as globally blocked once it appears in
  one entry. The entry belongs to one application process inside one
  store, and the same identifier from another process is untouched.
- Voiding a whole request because one instruction was refused. The
  instructions are graded individually, and collapsing them loses the
  ones that were valid.
- Reporting per-instruction results without the cross-store census. Every
  instruction can pass while the event ends up retrievable from nowhere.

## Behavior contract (gate 3)

The store and event-definition validation, per-instruction add and
delete grading, retention-mandatory and capacity refusals, resulting
configuration report, arrival disposition and cross-store census are
exercised by the gate 3 contract test:
scripts/test_e7041_managing_the_event_report_blocking_storage_control.py
against
scripts/e7041_managing_the_event_report_blocking_storage_control_logic.py
(stdlib unittest, offline). Run:
python3 scripts/test_e7041_managing_the_event_report_blocking_storage_control.py

## Compliance

- ECSS standards are freely downloadable (ESA); cite the source and
  paraphrase per standards-map.yaml.
- compliance: STANDARDS-REF, gated: false.