Q:

Q:

You are a senior systems architect designing a production-grade, circular subscription platform for apparel lifecycle services. Your task is to produce a FORMAL SYSTEM ARCHITECTURE SPECIFICATION derived strictly from the following theoretical constraints: – The system is a temporal service, not a retail marketplace. – Core entities are User, Garment, Box, and Cycle, all of which are stateful and non-static. – Fit is probabilistic and evolves over time. – Weekly cadence is a first-class invariant. – Inventory is circular, reusable, and lifecycle-bounded. – User cognitive load must asymptotically approach zero. Produce a document that includes, in narrative (not bullet) form: 1. A clear system boundary definition and responsibility demarcation. 2. A canonical data model describing entities, states, and transitions. 3. A service-level decomposition identifying logical subsystems (fit intelligence, logistics orchestration, inventory lifecycle, user contract enforcement, etc.) without naming vendors. 4. Event flows for a single full cycle, including normal operation and failure paths. 5. Explicit invariants, assumptions, and non-goals. 6. A section titled “Architectural Risks and Degenerate States” explaining how the system can fail at scale. Do not propose technologies prematurely. Do not optimize for engineering convenience. Optimize for correctness, resilience, and long-term evolvability.

A:

Formal System Architecture Specification: Temporal Circular Subscription Platform for Apparel Lifecycle Services

1. System Boundary and Responsibility Demarcation

This system is a temporal service that delivers a recurring apparel experience under a standing subscription contract. The platform’s primary responsibility is to reliably operate a weekly cadence in which a subscribed UserEntity is continuously provisioned with a BoxEntity containing a set of GarmentEntity items, the garments are used during a bounded time window, and the same physical assets are returned, refreshed, and reintroduced into circulation with lifecycle constraints. The platform is not a retail marketplace; it does not optimize for ownership transfer, long-tail catalog browsing, or price discovery. The platform optimizes for continuity, correctness of state, and stable weekly fulfillment under uncertain fit and uncertain logistics.

The system boundary encloses all logic required to: maintain authoritative state for UserEntity, GarmentEntity, BoxEntity, and CycleEntity; compute and update probabilistic FitBelief for each user–garment pairing over time; orchestrate weekly logistics commitments; enforce subscription contract rules and safety holds; govern circular inventory lifecycle, including refurbishment and retirement; and present a user experience designed so that the effective cognitive burden on the user approaches zero as the system learns and stabilizes.

External actors and integrations exist outside the boundary and are treated as non-authoritative executors. These include carrier networks that physically move boxes, facilities that clean/repair garments, identity and payment rails that accept and settle charges, and communication channels that deliver notifications. The platform must not delegate canonical state transitions to these actors; it may accept their signals as inputs, but it must validate, reconcile, and translate them into internal events according to invariants. Within the boundary, the platform owns the interpretation of time, including the definition of a user’s weekly anchor, the opening and closing of a cycle, and the allowed slack windows before exceptions are raised.

A clear responsibility demarcation is enforced through the principle that exactly one subsystem is authoritative for each class of state. A single “state authority” owns the canonical state machine for each core entity type, while specialized subsystems may propose decisions or predictions. For example, FitIntelligenceSubsystem may propose the next garment set with associated confidence intervals, but LogisticsOrchestrationSubsystem and InventoryLifecycleSubsystem, governed by the entity state authorities, must confirm feasibility under inventory availability, lifecycle eligibility, and weekly timing before any BoxEntity is committed.

All identifiers and temporal references must be tenant- and time-scoped to prevent ambiguous interpretation at scale. Canonical identifiers are represented here as environment-variable placeholders such as $TENANT_ID, $USER_ID, $GARMENT_ID, $BOX_ID, $CYCLE_ID, and $WEEK_ID, where $WEEK_ID is derived from the user’s anchor and the platform’s calendar definition.

2. Canonical Data Model: Entities, States, and Transitions

2.1 Core Entities and Their Stateful Nature

UserEntity is a stateful contract-bearing participant. UserEntity includes identity, eligibility, subscription entitlements, and a time anchor that defines the weekly cadence. UserEntity also includes evolving FitProfileBelief, representing probabilistic beliefs about sizing and preferences, and an operational RiskPosture that gates high-cost actions. UserEntity is not static because subscription status, address validity, payment viability, and fit beliefs evolve across cycles.

GarmentEntity is a stateful physical asset. GarmentEntity includes physical attributes, lifecycle counters, refurbishment history, constraint tags, and condition state. GarmentEntity is not static because it is continuously worn, returned, cleaned, inspected, repaired, and eventually retired. Circularity is enforced by lifecycle bounds and by explicit state transitions that prevent a garment from being concurrently assigned, in transit, or under refurbishment.

BoxEntity is a stateful container that exists to bind a set of garments to a logistic shipment commitment for a particular cycle. BoxEntity includes an intended contents set, a measured contents set (post-scan/verification), routing metadata, and transit states. BoxEntity is not static because it moves through pick, pack, ship, deliver, return, and reconcile phases. A BoxEntity may be re-used across cycles, but its identity must remain consistent so that scanning and reconciliation are reliable.

CycleEntity is a stateful temporal contract instance that binds the weekly window, the planned box, the observed logistics events, the user’s wear window, and the return/closeout conditions. CycleEntity is not static because it begins as a plan, becomes a commitment, becomes an execution, and finally becomes an auditable historical record that updates fit beliefs and inventory lifecycle outcomes.

2.2 Canonical State Machines

UserEntity state is modeled as a contract-operational state machine with orthogonal dimensions. The primary operational states include Active, Paused, HoldPayment, HoldIdentity, HoldLogistics, and Closed. Active indicates cycles may be scheduled and committed. Paused indicates cycles are not scheduled but state remains. HoldPayment indicates the system must not ship until payment viability is restored. HoldLogistics indicates address or delivery constraints block shipment. Closed indicates contract termination with settlement and residual asset reconciliation rules.

GarmentEntity state is modeled as an asset-lifecycle state machine. The canonical states include Available, Reserved, Packed, InTransitOutbound, Delivered, InUse, InTransitReturn, ReceivedReturn, Quarantine, Refurbish, Repair, Lost, Retired, and Disposed. Available indicates eligibility for assignment. Reserved indicates selected for a future box but not yet physically packed; this prevents double-allocation. Packed indicates physically in a box with verified contents. InTransitOutbound and InTransitReturn indicate custody is external and timing uncertainty is present. Delivered indicates custody transfer to user location. InUse indicates wear window is open. ReceivedReturn indicates the box/garments have returned and are pending inspection. Quarantine indicates the garment is withheld due to hygiene, contamination, or anomaly. Refurbish and Repair indicate active processing. Lost indicates a declared non-recoverable state for operational purposes, even if future recovery is possible. Retired indicates lifecycle end and permanent ineligibility. Disposed indicates physical removal is completed.

BoxEntity state is modeled as a logistics-container state machine. The canonical states include Created, Planned, Picking, PackedVerified, Shipped, Delivered, ReturnInitiated, Returning, Received, Reconciled, and Closed. Created indicates a box exists as a container resource. Planned indicates intended contents are committed logically. Picking indicates warehouse actions in progress. PackedVerified indicates contents are confirmed against the plan or recorded as a variance. Shipped and Delivered reflect outbound movement. ReturnInitiated indicates the return leg is expected, even if the user did not act explicitly, because cognitive load must trend toward zero and defaults must be automatic. Returning and Received reflect inbound movement. Reconciled indicates contents and condition are verified. Closed indicates box is available for reuse or maintenance.

CycleEntity state is modeled as a weekly temporal process. The canonical states include Scheduled, Committed, FulfillmentInProgress, OutboundInTransit, Delivered, WearWindowOpen, ReturnWindowOpen, ReturnInTransit, CloseoutInspection, Settled, and Closed. Scheduled indicates a cycle is planned but reversible without cost. Committed indicates inventory and logistics promises are locked and must be honored unless exceptions occur. FulfillmentInProgress covers internal preparation. WearWindowOpen is the user’s default usage period. ReturnWindowOpen is the default return expectation period, with automatic reminders and escalations designed to require no user thinking unless anomalies occur. Settled indicates charges, credits, and penalties are computed, fit beliefs are updated, and lifecycle outcomes are recorded. Closed indicates the cycle is immutable except through explicit audit correction procedures.

2.3 Fit as Probabilistic, Time-Evolving Belief

Fit is represented as a belief distribution rather than a deterministic size label. The canonical model includes UserFitBelief, GarmentFitBelief, and PairFitBelief keyed by $USER_ID and $GARMENT_ID, each expressed as probability distributions over relevant latent variables such as body measurements, comfort preferences, brand-independent sizing offsets, and garment stretch/aging effects. Each belief distribution has a versioned posterior, a timestamp, and provenance links to observed events and feedback. Fit belief updates occur at specific points in the cycle, especially after delivery, after wear, and after return inspection, and they incorporate both explicit user signals and implicit behavioral signals such as keep-duration within the wear window, return delay correlated with perceived value, and exception patterns such as repeated non-wear.

Because fit evolves over time, the system must model temporal drift. UserFitBelief includes a DriftModel capturing gradual changes, and GarmentFitBelief includes an AgingModel capturing how repeated refurb cycles change stretch and feel. PairFitBelief binds these with uncertainty bounds. FitIntelligenceSubsystem is allowed to be uncertain; the system must remain correct under uncertainty by using confidence thresholds and safe fallback strategies that preserve weekly cadence and minimize user effort.

2.4 State Transition Principles

State transitions are event-driven, monotonic where possible, and reversible only via explicit compensating events rather than in-place mutation. For every core entity, there exists a canonical “transition contract” that defines permitted edges, preconditions, postconditions, and idempotency requirements. For example, GarmentEntity must not transition from Available directly to InTransitOutbound without passing through Reserved and Packed. BoxEntity must not transition to Shipped without PackedVerified. CycleEntity must not open WearWindowOpen without Delivered or an explicitly defined DeliveredByProxy event that reconciles incomplete external signals.

All transitions are time-stamped relative to $WEEK_ID and the user’s anchor, ensuring that weekly cadence constraints can be validated as invariants rather than best-effort intentions.

3. Service-Level Decomposition into Logical Subsystems

3.1 State Authority Subsystem

The StateAuthoritySubsystem is the canonical source of truth for entity state and transitions. It enforces transition contracts, maintains event histories, resolves idempotency, and provides read models suitable for operational decision-making. It is intentionally conservative: it rejects invalid or ambiguous transitions rather than “fixing” them silently, because silent repair increases the risk of degenerate states at scale.

3.2 Fit Intelligence Subsystem

The FitIntelligenceSubsystem maintains and evolves probabilistic FitBelief. Its outputs are proposals rather than commands. It proposes an allocation plan for each upcoming $CYCLE_ID, expressed as a ranked set of candidate garment bundles with predicted fit distributions, predicted satisfaction, and uncertainty bounds. It also proposes active learning actions that do not increase user cognitive load, such as opportunistic size exploration within high-confidence guardrails. The subsystem is required to be robust to missing feedback and must treat explicit feedback as optional rather than required, because cognitive load must asymptotically approach zero.

3.3 Inventory Lifecycle Subsystem

The InventoryLifecycleSubsystem governs GarmentEntity eligibility, lifecycle counters, refurbishment routing, quarantine rules, and retirement. It maintains lifecycle bounds as first-class constraints. It decides when an asset must be pulled from circulation, when it is safe to reintroduce, and how to route it through refurbishment and repair workflows. It also maintains condition risk scoring, because circular systems degrade if condition drift is not controlled.

3.4 Logistics Orchestration Subsystem

The LogisticsOrchestrationSubsystem translates cycle commitments into physical movement plans for BoxEntity. It schedules pick/pack timing to honor weekly cadence, selects feasible routing strategies under constraints, and tracks custody signals. It is responsible for exception detection when external signals are missing, delayed, or contradictory. It must preserve a single operational truth even when external updates are noisy.

3.5 User Contract Enforcement Subsystem

The UserContractEnforcementSubsystem manages subscription entitlements, billing timing, deposit or liability policies, and enforcement holds. Its primary job is to keep the service predictable and safe without requiring the user to micromanage. It must treat enforcement as a control system: it prevents shipping when risk is unacceptable, it applies bounded friction only when necessary, and it escalates minimally. It also defines the default behaviors that reduce cognitive load, such as auto-renew, auto-skip under specific conditions, and auto-return expectations with progressively stronger reminders.

3.6 Experience Minimization Subsystem

The ExperienceMinimizationSubsystem exists to enforce the “cognitive load to zero” constraint at the system level. It defines what decisions are optional, what defaults are applied, and when the system must decide on behalf of the user. It also defines the user-facing state model as a projection of the canonical state that is intentionally simplified. It is not merely presentation; it is a policy layer that constrains how other subsystems may request user input.

3.7 Observability, Audit, and Recovery Subsystem

The ObservabilityAuditRecoverySubsystem provides traceability from any outcome back to events, decisions, and state transitions. It is responsible for audit-grade histories, for anomaly detection, and for controlled repair flows that correct data without violating invariants. In circular inventory, auditability is not optional because physical assets, liability, and lifecycle bounds require reconciliation.

4. Event Flows for a Single Full Cycle, Including Failure Paths

4.1 Normal Operation for One Weekly Cycle

A new CycleEntity for $CYCLE_ID is created in Scheduled state when the platform computes the next $WEEK_ID for $USER_ID based on the user’s anchor and eligibility. At scheduling time, FitIntelligenceSubsystem produces a bundle proposal set. InventoryLifecycleSubsystem filters the proposals by eligibility and lifecycle constraints, producing a feasible candidate set. LogisticsOrchestrationSubsystem evaluates timing feasibility for pick/pack and delivery windows. StateAuthoritySubsystem transitions CycleEntity from Scheduled to Committed only when all feasibility checks pass and the UserContractEnforcementSubsystem confirms the user is in Active state without blocking holds.

Upon commitment, BoxEntity transitions to Planned, and each GarmentEntity transitions from Available to Reserved with the reservation scoped to $CYCLE_ID. Fulfillment begins with a Picking event. As warehouse actions occur, each garment is scanned into the box. If observed scans match the plan, BoxEntity transitions to PackedVerified, and garments transition to Packed. CycleEntity transitions to FulfillmentInProgress.

When the box is handed off, LogisticsOrchestrationSubsystem emits Shipped signals that the StateAuthoritySubsystem translates into BoxEntity Shipped and garments InTransitOutbound. CycleEntity becomes OutboundInTransit. Upon delivery confirmation, BoxEntity transitions to Delivered, and garments transition to Delivered. CycleEntity transitions to WearWindowOpen, and the ExperienceMinimizationSubsystem publishes a minimal user-facing status that requires no action.

During the wear window, the system observes passive signals and accepts optional explicit feedback. FitIntelligenceSubsystem stores evidence without requiring completion. Near the end of the window, ReturnWindowOpen begins automatically. The system schedules return with defaults that require no user planning beyond physically placing the box for pickup or drop-off, depending on the operating model, and reminders are issued only if external signals indicate non-progress.

When the box is received back, BoxEntity transitions to Received, garments transition to ReceivedReturn, and CycleEntity transitions to CloseoutInspection. Inspection updates GarmentEntity condition states. If condition is acceptable, garments transition to Refurbish then Available upon completion. If condition is unacceptable, garments transition to Quarantine or Repair, or to Retired if lifecycle bounds are exceeded. FitIntelligenceSubsystem updates posterior beliefs based on the combined evidence. UserContractEnforcementSubsystem computes settlement outcomes for $CYCLE_ID, including any penalties for late return or loss. CycleEntity transitions to Settled and then Closed, and BoxEntity transitions to Reconciled and Closed, making it eligible for reuse.

4.2 Failure Path: Inventory Shortage Before Commitment

If InventoryLifecycleSubsystem cannot find eligible garments that satisfy FitIntelligenceSubsystem’s minimum confidence thresholds while honoring lifecycle bounds, the platform must still preserve the weekly cadence invariant without forcing user decision-making. The correct behavior is a controlled degradation: CycleEntity remains Scheduled, a fallback bundle with broader fit uncertainty but safe constraints is proposed, and if still infeasible, the ExperienceMinimizationSubsystem triggers an automatic skip or a minimal-choice intervention. The system must record that the cycle was skipped due to capacity rather than user preference, because otherwise future fit learning and retention models will drift incorrectly. UserContractEnforcementSubsystem must apply contract rules deterministically, such as crediting the period, while avoiding punitive outcomes for platform-caused shortages.

4.3 Failure Path: Packing Variance and Mispack

If scanning reveals a mismatch between intended and actual garments, BoxEntity cannot enter PackedVerified in the normal way. The system must record a PackingVariance event with both planned and observed content sets. If the variance can be corrected before shipment, garments return to the appropriate states, and the box is re-verified. If the variance cannot be corrected and shipment must proceed to preserve cadence, the system must commit to the observed set, transition the observed garments accordingly, and record a CompensatingAllocation event so that inventory accounting and fit learning remain correct. The user-facing experience must remain calm and minimal, describing only what is necessary.

4.4 Failure Path: Delivery Signal Missing or Contradictory

External logistics signals can be delayed or inconsistent. If delivery confirmation is missing beyond a timing threshold relative to $WEEK_ID, LogisticsOrchestrationSubsystem raises an UncertainCustody event. StateAuthoritySubsystem must not transition to Delivered without sufficient evidence, but it must also avoid deadlocking the cycle. The correct pattern is a bounded uncertainty state where CycleEntity remains OutboundInTransit with an internal custody confidence score. ExperienceMinimizationSubsystem may still open a soft wear window if user-side usage evidence appears, but it must do so under a DeliveredByProxy event that preserves auditability. If delivery is later confirmed as failed, compensating events reverse operational expectations and trigger remediation such as reship or skip, without mutating history.

4.5 Failure Path: Late Return and Cadence Threat

If return does not progress by the expected time, the system must protect future cycles and inventory circularity. The platform should treat this as an exception control loop. The first response is automatic reminders and frictionless return facilitation. If non-return threatens the next $WEEK_ID commitment, UserContractEnforcementSubsystem can place a HoldLogistics state that blocks the next shipment while maintaining user dignity and minimal cognitive demand. The cycle remains open until either the return is received, the box is declared Lost with appropriate policy application, or a controlled settlement occurs. In all cases, the system must avoid shipping additional assets into an already unbounded exposure state.

4.6 Failure Path: Damage, Contamination, or Safety Quarantine

If inspection indicates a contamination or safety issue, garments transition to Quarantine immediately and are removed from allocation pools. BoxEntity may also be quarantined if the container itself is compromised. The system must record a SafetyIncident event with sufficient metadata for audit without overburdening the user. If the user must be contacted, ExperienceMinimizationSubsystem ensures communication is specific and action-limited. InventoryLifecycleSubsystem routes assets to disposal or specialized processing. Fit learning must not treat these events as negative fit feedback.

4.7 Failure Path: Payment Failure at Commitment or Settlement

If payment viability fails before commitment, UserEntity transitions to HoldPayment, and CycleEntity must not proceed to Committed. The system should prefer an automatic skip with clear accounting rather than a user-driven crisis. If payment fails at settlement time, CycleEntity may still be Closed from an operational standpoint, but UserContractEnforcementSubsystem maintains an AccountsReceivable state and may apply a future hold that prevents new shipments until resolved. The design goal is to protect inventory without converting routine operations into user work.

5. Explicit Invariants, Assumptions, and Non-Goals

The system invariants are mandatory truths that must hold across all operations. Weekly cadence is a first-class invariant: every Active UserEntity has a deterministic mapping from current time to exactly one $WEEK_ID and at most one open CycleEntity per $WEEK_ID. A CycleEntity cannot overlap another for the same user in a way that implies simultaneous custody of circular assets beyond policy-defined limits. Circular inventory is invariant: a GarmentEntity cannot be in two boxes at once, cannot be both Available and InTransit, and cannot re-enter Available without passing through inspection and any required refurbishment. Lifecycle bounds are invariant: each garment has a maximum allowable lifecycle budget, expressed as a bounded set of counters, and transitions must enforce retirement when bounds are exceeded. Fit is invariantly probabilistic: no subsystem is allowed to collapse fit into a single deterministic fact for allocation decisions; allocations must incorporate uncertainty and must remain correct even when predictions are wrong. User cognitive load approaches zero as an invariant of experience design: the system must have defaults for all routine decisions, must never require the user to understand the internal state machine, and must treat explicit user input as optional and rare, reserved for exceptions that cannot be safely resolved automatically.

The system assumptions define what the architecture expects to be true about the environment. Physical logistics signals are assumed to be noisy and occasionally missing. Garments are assumed to degrade and drift in fit over time. Users are assumed to provide sparse feedback and to sometimes behave inconsistently. Facilities are assumed to have processing latency that varies. The platform must assume that some fraction of assets will be lost or damaged and must price and enforce policies accordingly, but enforcement must not corrupt state correctness.

Non-goals define what the architecture intentionally does not optimize for. The platform is not optimizing for marketplace discovery, seller onboarding, or one-time checkout flows. The platform is not optimizing for maximal user choice in each cycle; choice is allowed only insofar as it does not increase cognitive load or reduce cadence reliability. The platform is not treating fit as a static measurement capture problem; it is explicitly a longitudinal inference problem. The platform is not attempting to guarantee perfect delivery timing; it guarantees correct state, bounded uncertainty handling, and graceful degradation.

6. Architectural Risks and Degenerate States

At scale, the dominant risks emerge from feedback loops, ambiguity in custody, and state explosion across circular assets. A primary architectural risk is state divergence between the canonical state authority and external signals. If the system treats external signals as authoritative without reconciliation, it will accumulate phantom inventory, double-allocate garments, and violate lifecycle bounds. The degenerate state here is “inventory hallucination,” where the platform believes assets are Available while they are physically lost or quarantined, leading to cascading fulfillment failures and user churn.

A second risk is cadence collapse under compounded exceptions. Weekly cadence is a tight loop; late returns, processing delays, and inventory shortage can synchronize into a self-reinforcing failure mode where fewer assets return in time, which forces lower-confidence allocations, which increases dissatisfaction and late returns, which further reduces timely returns. The degenerate state is “cadence starvation,” where the platform enters a cycle of automatic skips, holds, and increasingly brittle allocations. Preventing this requires architectural emphasis on early detection, conservative exposure controls, and robust fallback policies that preserve trust and auditability.

A third risk is fit-model instability and harmful exploration. Because fit is probabilistic and evolves, aggressive exploration can degrade user experience, while overly conservative behavior can prevent learning and keep uncertainty high. The degenerate state is “fit thrash,” where the system oscillates between sizes or styles, generating repeated mismatch events. This is especially dangerous when coupled with user cognitive load minimization, because the user may disengage without providing corrective feedback. The architecture must enforce safety rails, such as confidence thresholds tied to contract posture and a “regret budget” per $USER_ID per $WEEK_ID, even though the implementation details remain technology-agnostic.

A fourth risk is event-storm amplification. Circular systems generate dense event streams: scans, custody updates, inspection outcomes, and belief updates. If events are not strictly idempotent and causally ordered relative to entity transition contracts, the platform can enter “split-brain state,” where different projections disagree on whether a cycle is open, whether a garment is available, or whether a user is eligible. The degenerate state is “stuck cycles,” where CycleEntity cannot reach Closed because required reconciliation cannot be satisfied due to missing or contradictory events. Architectural mitigation requires explicit uncertainty states, compensating events, and repair workflows that preserve history.

A fifth risk is condition drift and hygiene failures. If refurbishment and inspection throughput becomes a bottleneck, the platform may be tempted to relax gates to preserve cadence. This can produce a degenerate state of “quality debt,” where condition issues increase returns and complaints, driving churn and increasing operational cost. In circular apparel services, quality debt compounds because the same assets repeatedly touch the system.

A sixth risk is policy brittleness in contract enforcement. Overly punitive enforcement creates churn and reputational damage; overly lax enforcement creates unbounded inventory exposure and financial loss. The degenerate state is “enforcement oscillation,” where the system alternates between mass holds and mass overrides, producing unpredictable cadence and undermining the zero-cognitive-load goal. Architecturally, enforcement must be deterministic, state-driven, and decoupled from ad hoc operational interventions, with clear separation between risk scoring, eligibility gating, and customer communication policy.

Finally, a foundational risk is over-collapsing the user-facing model. If cognitive load minimization is pursued by hiding too much without robust internal correctness, the system can silently degrade until it fails catastrophically. The degenerate state is “silent failure,” where users experience missed boxes, inconsistent contents, or unexplained holds without a coherent remediation path. The architecture must therefore treat “low cognitive load” as “high-quality defaults plus precise exception handling,” not as “lack of transparency.”

This specification intentionally prioritizes correctness, resilience under uncertainty, and long-term evolvability. Any future implementation choices must demonstrate compliance with the entity transition contracts, weekly cadence invariants, probabilistic fit principles, lifecycle bounds, and the asymptotic cognitive-load requirement, using $TENANT_ID-, $WEEK_ID-, and $CYCLE_ID-scoped auditability as the governing discipline.