S8-VOICE-001 / CONTROLLED
System 8 writing and programmatic-specificity standard
Start with the fault. Name the component. Run the smallest useful test. Show the result. Explain the next branch. Keep the conclusion proportional to the evidence.
Source boundary
The individual voice model comes from Dylan's full-name Whirlpool technical posts and public Delimiter comments. The strongest sample diagnoses an Asterisk problem by separating SIP signalling from RTP media, running sip set debug ip 1.2.3.4, reading the returned SDP address and port, and selecting the next network test.
The Senate Select Committee item is submission 70, produced with the NBN Alliance Wiki community. It supports collaborative research discipline. It is a submission with multiple contributors and is not Hansard or sentence-level authorship evidence.
Observed writing method
- Open with the failing interface and exact environment.
- Split the service into components that can fail independently.
- Name the command, field, API route or packet capture.
- State the expected result and the meaning of an empty, denied or contradictory result.
- Choose the next discriminating check.
- Explain risk through a concrete event and affected record.
- State uncertainty once, then identify the test that resolves it.
AI-smell limits
| FLAG | RELEASE RULE |
|---|---|
| “This is not X. It is Y.” | Zero decorative uses; write Y directly. |
| “does not prove” formula | Name the fields or path missing from the capture. |
rather than | Maximum one per 1,200 words; direct wording preferred. |
| House abstractions | evidence-first, control boundary, plane and surface appear once only when defined. |
| Symmetric conclusions | End with the acceptance result, remaining unknown and next safe action. |
Safety prohibitions remain. Each one names the prohibited action and its concrete consequence.
Programmatic specificity contract
| ELEMENT | REQUIRED EVIDENCE |
|---|---|
| Environment | Tenant/workload, deployment type, identity context, product or module version and capture UTC |
| Symptom | Failing operation, identifier, status code or visible result |
| Acquisition | Command, API route, portal path, export or log query |
| Output | Named fields and a representative redacted result |
| Interpretation | Supported inference, remaining causes and next branch |
| Change | Exact setting, grant, binding, layer, rule or file |
| Safety | Authority, pre-change capture, stop and rollback |
| Verification | Positive persona, prohibited persona, retry and retained evidence |
| Limits | Untested path, platform limit or unresolved dependency |
A 1,200-2,000 word field note needs five named artefacts, three exact commands/routes/fields, two result branches, positive and negative tests, a stop or rollback condition, and primary sources for material behaviour claims.
Score and automatic failures
Publication requires 85/100 across opening, decomposition, programmatic detail, diagnostic reasoning, safety, verification, sources and rhythm. Unsupported client claims, unbounded production-changing commands, platform selection before tested requirements, unsafe negative tests, fabricated first-person experience and mismatched citations fail the release.
Review procedure
- Run the voice lint and specificity inventory.
- Read only the opening, headings and conclusion; confirm they form a diagnostic sequence.
- Review every command with its prerequisite, expected result and stop condition.
- Replace decorative antithesis and repeated house language.
- Add missing fields, outputs and branches from verified sources or labelled lab evidence.
- Validate links, schema, accessibility, responsive behaviour and production headers.
- Record the score and exceptions in the release report.