# XVII. Operating Cadence

### Part 17 — Operating Cadence

#### 1. Cadence Doctrine

1.1 **Cadence is a control.** The Guild’s operating rhythm is a safety, integrity, and quality control—designed to prevent ad-hoc publication, reduce capture risk, maintain reproducibility, and ensure correctionability.

1.2 **Default lightweight; surge by record.** The Guild operates “lightweight by default” with defined surge windows for:\
1.2.1 coordinated disclosure events;\
1.2.2 quarterly benchmark and dataset refresh;\
1.2.3 major platform releases; and\
1.2.4 material corrections affecting reliance.

1.3 **No output without a record.** Any output represented as a Guild output requires:\
1.3.1 a docket entry;\
1.3.2 an assigned steward/maintainer;\
1.3.3 an explicit quality mark election (or “unmarked”); and\
1.3.4 a published correction and supersession path.

***

#### 2. Monthly Guild House Meeting

2.1 **Purpose.** The Monthly House is the minimum governance loop for:\
2.1.1 backlog triage;\
2.1.2 release readiness and risk review;\
2.1.3 dispute intake and resolution tracking; and\
2.1.4 membership good-standing operations (handling discipline, COI, contribution posture).

2.2 **Attendance posture.**\
2.2.1 Required for **Active** status for maintainers, stewards, and integrity roles (attendance may be satisfied by approved written participation).\
2.2.2 Open to observers where handling class permits.

2.3 **Standing agenda (minimum).**\
2.3.1 Handling and safety notices (competition-safe reminder; dual-use constraints).\
2.3.2 Records roll call (prior action register; overdue corrections; deprecations).\
2.3.3 Release docket review (datasets, benchmarks, modules, reports).\
2.3.4 Risk register review (capture signals, gaming attempts, legal compulsion events).\
2.3.5 Dispute clock review (open disputes; required correction clocks).\
2.3.6 Decisions and assignments (named owners; dates; required artifacts).

2.4 **Records required.**\
2.4.1 agenda;\
2.4.2 minutes with role markers (no unnecessary identity disclosure);\
2.4.3 action register;\
2.4.4 decision record(s) for any designated approvals; and\
2.4.5 distribution log where Controlled/Restricted materials are referenced.

***

#### 3. Module Clinics

3.1 **Purpose.** Clinics are domain-specific working sessions to:\
3.1.1 validate methods;\
3.1.2 review evidence sufficiency and reproducibility;\
3.1.3 manage benchmark integrity and anti-gaming controls; and\
3.1.4 reduce drift between measurement and interpretation.

3.2 **Clinic families (typical).**\
3.2.1 Infrastructure (DNS/DNSSEC, PKI/CT, hosting/CDN concentration).\
3.2.2 Security (OWASP, vuln intelligence, supply chain).\
3.2.3 Privacy & rights (tracking ecology, consent, cross-border patterns).\
3.2.4 AI-on-web & agents (synthetic media, agent containment, prompt injection surfaces).\
3.2.5 Web3 (contract/oracle/bridge risk, governance concentration).\
3.2.6 Accessibility (WCAG, inclusion metrics, low-bandwidth patterns).\
3.2.7 Performance & resilience (Core Web Vitals, outages, cascade modeling).\
3.2.8 Standards & governance interoperability (W3C/IETF/ICANN mapping, policy hooks).\
3.2.9 Measurement & benchmarks (sampling, drift, error budgets, appeals).

3.3 **Clinic outputs.** Each clinic may produce:\
3.3.1 method notes (Public-safe by default);\
3.3.2 test harness updates;\
3.3.3 dataset refresh proposals;\
3.3.4 benchmark version candidates; and\
3.3.5 red-team findings and “do-not-deploy” conditions.

3.4 **Clinic records.** A clinic must produce at minimum:\
3.4.1 a docket entry;\
3.4.2 change proposals with rationale;\
3.4.3 a risk note (dual-use, gaming, bias); and\
3.4.4 a decision record if changes are accepted into release.

***

#### 4. Build Sprints and Replication Sprints

4.1 **Build sprints.** Time-boxed engineering/research cycles for:\
4.1.1 reference implementations;\
4.1.2 module integration;\
4.1.3 performance improvements;\
4.1.4 new measurement collectors; and\
4.1.5 documentation and curriculum outputs.

4.2 **Replication sprints.** Time-boxed reproducibility cycles for:\
4.2.1 replaying benchmark runs;\
4.2.2 validating dataset integrity;\
4.2.3 verifying result stability across environments; and\
4.2.4 confirming error budgets and uncertainty intervals.

4.3 **Sprint entry criteria.**\
4.3.1 scoped objectives;\
4.3.2 identified owners;\
4.3.3 handling class election;\
4.3.4 risk review (dual-use and gaming); and\
4.3.5 defined acceptance tests.

4.4 **Sprint exit criteria.**\
4.4.1 SBOM/SLSA posture for releasable code;\
4.4.2 updated runbooks;\
4.4.3 reproducibility claims scored (RS level);\
4.4.4 limitations and reliance bounds updated; and\
4.4.5 release notes drafted for the next quarterly cut (or emergency correction).

***

#### 5. Demo Days

5.1 **Purpose.** Demo Days are evidence-first showcases that:\
5.1.1 do not function as a deal room;\
5.1.2 do not imply endorsement; and\
5.1.3 require limitations and uncertainty to be presented alongside results.

5.2 **Mandatory demo disclosures.**\
5.2.1 the artifact version(s);\
5.2.2 dataset/benchmark version(s);\
5.2.3 RS/E/DQ levels claimed;\
5.2.4 error budgets and known blind spots;\
5.2.5 handling class; and\
5.2.6 correction path.

5.3 **No operational claims.** Demos may show capability, but must not:\
5.3.1 claim operational SOC/CSIRT services;\
5.3.2 provide exploit-enabling detail; or\
5.3.3 represent results as certification or compliance determinations.

***

#### 6. Quarterly Research Releases

6.1 **Quarterly release objective.** The quarterly release is the principal stability point for:\
6.1.1 benchmark updates;\
6.1.2 dataset refresh and drift notes;\
6.1.3 module versioning;\
6.1.4 documentation and curriculum updates; and\
6.1.5 correction and supersession rollups.

6.2 **Minimum contents.** Each quarterly release includes:\
6.2.1 release notes with scope and limitations;\
6.2.2 an errata and deprecation summary;\
6.2.3 benchmark integrity statement (anti-gaming posture, drift monitoring);\
6.2.4 dataset quality statement (coverage/bias/drift/provenance); and\
6.2.5 a forward plan (next quarter docket).

6.3 **Release gate.** No quarterly release may be issued without:\
6.3.1 integrity steward sign-off (handling + dual-use + competition-safe checks);\
6.3.2 reproducibility attestation for claims made; and\
6.3.3 published correction/supersession pointers.

***

#### 7. Annual “State of Web Resilience” Report

7.1 **Purpose.** The Annual Report is a methods-forward, benchmark-grade publication that:\
7.1.1 summarizes longitudinal trends;\
7.1.2 explains methodology changes and their effect;\
7.1.3 discloses uncertainty and sampling limits; and\
7.1.4 provides cross-domain coupling analysis for systemic risk.

7.2 **Mandatory inclusions.**\
7.2.1 methods and sampling disclosure;\
7.2.2 major corrections and deprecations log;\
7.2.3 benchmark integrity narrative (gaming attempts and mitigations, where safe);\
7.2.4 portability notes and non-equivalence warnings; and\
7.2.5 a public-safe research roadmap.

7.3 **No enforcement posture.** The Annual Report remains an evidence product; it does not instruct enforcement, censorship, procurement, or operational response.

***

#### 8. Records Spine

8.1 **Record types.** The Guild maintains at minimum:\
8.1.1 dockets;\
8.1.2 decision records;\
8.1.3 action registers;\
8.1.4 release notes;\
8.1.5 correction/errata/deprecation logs;\
8.1.6 distribution logs (for Controlled/Restricted);\
8.1.7 dispute records and outcomes; and\
8.1.8 incident registers (integrity, disclosure, benchmark disputes).

8.2 **Role markers and minimized identity.** Records are written using role markers by default. Identity disclosure is minimized and governed by handling rules.

8.3 **Correction clocks apply to records.** Records are correctionable artifacts. Silent edits are prohibited; supersession must be explicit and versioned.

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/xvii.-operating-cadence.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.