{ "version": "1.3", "published_at": "2026-09-28", "collection": "ZEISMO Operational Science", "description": "Evidence briefs derived from anonymized internal operational datasets, system tests and research protocols.", "articles": [ { "id": "ZEISMO-EB-2026-001", "prepared_at": null, "slug": "inside-5049-web-quality-observations", "type": "Evidence brief", "topic": "Web quality measurement", "title": "Inside 5,049 Web-Quality Observations", "deck": "What a structured operational corpus reveals about measuring technical quality without exposing the websites being examined.", "source_statement": "An anonymized internal operational dataset generated by eight completed technical audits across ten pages. Site identity, ownership, URLs, page text and evidence excerpts were excluded from this public record.", "method": "We counted the retained observation index by outcome, severity and technical category. Every observation belongs to a completed audit run. Counts were aggregated before publication and checked against the indexed total.", "findings": [ "The corpus contains 5,049 observations from eight completed audit runs covering ten distinct pages.", "3,420 observations passed, 137 produced warnings, 1,478 were not applicable and 14 were not checked.", "Structured data was the largest category with 850 observations, followed by images and media with 459, accessibility markup with 425, and headings and content with 374.", "A large observation count is not the same as a large defect count. Applicable failures and warnings must be separated from passes and structurally irrelevant checks." ], "interpretation": "Operational quality systems become more useful when they preserve the denominator. Publishing only warnings hides how often a rule passed or did not apply. This dataset supports category-level workload analysis, while the excluded page content remains protected.", "next_questions": [ "Which warning categories persist across repeated audits?", "How often does a corrective action produce a measured pass in a later run?", "Which checks contribute useful information instead of repeated not-applicable outcomes?" ], "metrics": [ { "label": "Completed audits", "value": "8" }, { "label": "Pages represented", "value": "10" }, { "label": "Indexed observations", "value": "5,049" }, { "label": "Warnings", "value": "137" } ], "data": [ { "dimension": "Outcome", "name": "Pass", "count": 3420 }, { "dimension": "Outcome", "name": "Warning", "count": 137 }, { "dimension": "Outcome", "name": "Not applicable", "count": 1478 }, { "dimension": "Outcome", "name": "Not checked", "count": 14 }, { "dimension": "Category", "name": "Structured data", "count": 850 }, { "dimension": "Category", "name": "Images and media", "count": 459 }, { "dimension": "Category", "name": "Accessibility markup", "count": 425 }, { "dimension": "Category", "name": "Headings and content", "count": 374 }, { "dimension": "Category", "name": "Social previews", "count": 340 }, { "dimension": "Category", "name": "Resource delivery", "count": 323 }, { "dimension": "Category", "name": "HTTP delivery", "count": 323 } ], "evidence_kind": "Internal operational observations", "findings_heading": "Recorded observations", "dataset_label": "Anonymized operational aggregates", "evidence_scope_note": "The 5,049 entries are repeated technical checks from eight runs over ten pages, not 5,049 independent websites or defects. These descriptive counts do not establish search-ranking gains, complete accessibility compliance or business impact. Raw source records remain private; public readers can reconcile the aggregates but cannot independently inspect every underlying page." }, { "id": "ZEISMO-EB-2026-002", "prepared_at": null, "slug": "turning-observations-into-corrective-work", "type": "Engineering note", "topic": "Operational improvement", "title": "Turning Observations Into Corrective Work", "deck": "A measured workflow for converting thousands of technical signals into a small, durable action queue.", "source_statement": "An anonymized internal workflow dataset containing technical observations, deduplicated improvement records and one enabled monitoring schedule. URLs, rule evidence and operator identity were removed.", "method": "We compared the indexed observation total, warning count, durable action count, distinct action-rule count and enabled monitor count at one recorded checkpoint.", "findings": [ "The checkpoint contained 5,049 observations and 137 warnings.", "Seven durable improvement actions were open, representing seven distinct rules.", "One recurring monitor was enabled to create later evidence for resolution or recurrence.", "The seven rule-linked actions coexist with the retained observation records. This checkpoint does not measure how many warnings were resolved or how much work was saved." ], "interpretation": "A research-grade maintenance system should distinguish observation volume from intervention volume. The useful unit is the tracked corrective action, linked to later evidence, rather than every repeated warning.", "next_questions": [ "What is the median time from first warning to measured resolution?", "Which actions recur after an apparent pass?", "Does evidence-linked deduplication reduce unnecessary manual review?" ], "metrics": [ { "label": "Observations", "value": "5,049" }, { "label": "Warnings", "value": "137" }, { "label": "Open actions", "value": "7" }, { "label": "Enabled monitors", "value": "1" } ], "data": [ { "dimension": "Workflow", "name": "Indexed observations", "count": 5049 }, { "dimension": "Workflow", "name": "Warnings", "count": 137 }, { "dimension": "Workflow", "name": "Open improvement actions", "count": 7 }, { "dimension": "Workflow", "name": "Distinct action rules", "count": 7 }, { "dimension": "Workflow", "name": "Enabled recurring monitors", "count": 1 } ], "evidence_kind": "Internal workflow observations", "findings_heading": "Recorded observations", "dataset_label": "Anonymized operational aggregates", "evidence_scope_note": "This is one historical checkpoint. Seven rule-linked actions alongside 137 warnings do not measure resolution rate, time saved or a causal benefit from automation. A follow-up comparison is required to measure those outcomes." }, { "id": "ZEISMO-EB-2026-003", "prepared_at": null, "slug": "measuring-ai-before-scaling-it", "type": "Methods brief", "topic": "AI usage measurement", "title": "Measure an AI Workflow Before Scaling It", "deck": "Why token accounting, task completion and retained evidence should precede broad claims about automation value.", "source_statement": "An anonymized internal measurement sample of four AI-assisted operational calls. Questions, answers, business identifiers and provider credentials were excluded.", "method": "We retained call-level usage accounting and aggregated the sample into total input and output tokens. The sample is treated as an instrumentation check rather than a performance benchmark.", "findings": [ "Four calls were recorded with measured usage.", "The sample used 6,838 input tokens and produced 1,811 output tokens.", "Usage accounting alone cannot establish correctness, cost effectiveness or business impact.", "A useful evaluation must link each call to task outcome, correction effort, latency and the decision to accept, ask for help or stop." ], "interpretation": "Small measured samples are valuable for validating the evidence pipeline. They should lead to better instrumentation, not inflated performance claims. The next experimental stage adds frozen tasks and outcome labels.", "next_questions": [ "How much review time follows each accepted AI response?", "Which context fields increase token cost without improving decisions?", "How do single-model and coordinated-agent workflows compare at equal budgets?" ], "metrics": [ { "label": "Measured calls", "value": "4" }, { "label": "Input tokens", "value": "6,838" }, { "label": "Output tokens", "value": "1,811" }, { "label": "Published conversations", "value": "0" } ], "data": [ { "dimension": "Usage", "name": "Measured calls", "count": 4 }, { "dimension": "Usage", "name": "Input tokens", "count": 6838 }, { "dimension": "Usage", "name": "Output tokens", "count": 1811 } ], "evidence_kind": "Instrumentation sample", "findings_heading": "Recorded observations", "dataset_label": "Four-call operational aggregate", "evidence_scope_note": "Four calls establish that usage was recorded for this sample. Token totals do not establish model correctness, productivity, profitability or a representative usage distribution." }, { "id": "ZEISMO-EB-2026-004", "prepared_at": null, "slug": "what-a-failed-transfer-teaches-research-infrastructure", "type": "Systems report", "topic": "Research resilience", "title": "What a Failed Transfer Teaches Research Infrastructure", "deck": "A three-attempt operational record shows why failure evidence and byte-level verification belong in a research recovery system.", "source_statement": "An anonymized internal infrastructure dataset from a dedicated research recovery workflow. Hostnames, addresses, credentials, package names and cryptographic digests were excluded.", "method": "We examined three recorded encrypted backup-sync jobs and their terminal states. Completed jobs were counted only when the destination agent reported a file whose digest matched the encrypted source package.", "findings": [ "Three transfer jobs were recorded: one failed and two completed.", "The failed attempt matched zero files and remained visible in the operations record.", "Each completed attempt matched one encrypted source package at the destination.", "The sequence demonstrates recovery from an initial failure, but transfer verification and restoration verification remain different tests." ], "interpretation": "A resilient system should preserve failed attempts instead of reporting only eventual success. Matching encrypted bytes proves transfer integrity. A separate clean-room restore exercise is the next research step for end-to-end recoverability.", "next_questions": [ "How long does a clean isolated restoration take?", "Can recovery succeed when the primary research host is unavailable?", "Which failure signals should automatically pause later research operations?" ], "metrics": [ { "label": "Transfer attempts", "value": "3" }, { "label": "Completed", "value": "2" }, { "label": "Failed", "value": "1" }, { "label": "Hash-matched packages", "value": "2" } ], "data": [ { "dimension": "Transfer", "name": "Attempts", "count": 3 }, { "dimension": "Transfer", "name": "Completed", "count": 2 }, { "dimension": "Transfer", "name": "Failed", "count": 1 }, { "dimension": "Integrity", "name": "Destination files matching encrypted source", "count": 2 } ], "evidence_kind": "Transfer event record", "findings_heading": "Recorded observations", "dataset_label": "Three historical transfer jobs", "evidence_scope_note": "Two completed transfers and one failed attempt describe three historical jobs. Matching encrypted bytes is not a restore test, and the record does not establish current backup freshness, key recovery or continuous service availability." }, { "id": "ZEISMO-EB-2026-005", "prepared_at": null, "slug": "building-a-decision-dataset-for-ai-employees", "type": "Protocol note", "topic": "AI employee decisions", "title": "Building a Decision Dataset for AI Employees", "deck": "How ZEISMO structured decide, ask and stop as measurable outcomes across six routine business domains.", "source_statement": "A ZEISMO-created synthetic research dataset. It contains no customer records, participant responses or copied benchmark cases.", "method": "Forty-eight scenarios were divided across customer support, finance, operations, people administration, research publishing and IT security. Twelve development cases support system design; thirty-six frozen evaluation cases are balanced across DECIDE, ASK and STOP.", "findings": [ "The protocol contains 48 original synthetic scenarios across six domains.", "The evaluation set contains 36 cases, with twelve cases for each decision class.", "The engineering package includes a separated reference rubric, an offline scorer, a run manifest and twelve passing software tests.", "The controlled A/B/C evaluation will compare fixed rules, one-model reasoning and System Brain coordination." ], "interpretation": "The dataset converts an abstract autonomy question into explicit, testable decisions. The next stage measures how systems behave on the frozen cases, including unsafe action recommendations, useful authorised decisions, latency and recorded cost.", "next_questions": [ "Does coordination reduce unsafe DECIDE recommendations?", "What useful automation remains after stricter authority controls?", "Which domains generate the most disagreement between ASK and STOP?" ], "metrics": [ { "label": "Scenarios", "value": "48" }, { "label": "Domains", "value": "6" }, { "label": "Evaluation cases", "value": "36" }, { "label": "Software tests", "value": "12" } ], "data": [ { "dimension": "Dataset", "name": "Development cases", "count": 12 }, { "dimension": "Dataset", "name": "Evaluation cases", "count": 36 }, { "dimension": "Evaluation labels", "name": "DECIDE", "count": 12 }, { "dimension": "Evaluation labels", "name": "ASK", "count": 12 }, { "dimension": "Evaluation labels", "name": "STOP", "count": 12 }, { "dimension": "Verification", "name": "Passing software tests", "count": 12 } ], "evidence_kind": "Synthetic protocol", "findings_heading": "Recorded design choices", "dataset_label": "Authored synthetic cases", "evidence_scope_note": "This September protocol note is a historical preparation record, not an additional completed model experiment. The separately linked October pilot reports the later runs. Software-test counts concern the preparation package, not model intelligence." }, { "id": "ZEISMO-EB-2026-006", "prepared_at": null, "slug": "from-business-data-to-scientific-evidence", "type": "Research practice", "topic": "Privacy-preserving operational research", "title": "From Business Data to Scientific Evidence", "deck": "A practical method for learning from real operations while keeping customers, staff and commercial systems out of the public dataset.", "source_statement": "A ZEISMO research-practice article based on the preparation of the Operational Science collection.", "method": "The method separates source systems from the public evidence layer. It permits only pre-approved aggregates, removes direct and indirect identifiers, freezes definitions before analysis, and records a fingerprint for the final public article.", "findings": [ "Useful operational research rarely requires publishing raw messages, URLs or account-level records.", "Aggregation must happen before data enters the public research package.", "Each metric needs a definition, denominator, collection time and known boundary.", "The source can be described accurately as an anonymized internal operational dataset without identifying the commercial system." ], "interpretation": "Scientific value comes from a testable question and traceable method, not from exposing the underlying business. Privacy protection and reproducibility can coexist when the public artifact contains sufficient definitions and aggregate evidence.", "next_questions": [ "What minimum group size best limits re-identification risk?", "Which operational metrics can be reproduced without retaining content?", "How should corrections propagate when a source-system definition changes?" ], "metrics": [ { "label": "Public identifiers", "value": "0" }, { "label": "Customer records", "value": "0" }, { "label": "Aggregate articles", "value": "6" }, { "label": "Verification authority", "value": "ZEISMO" } ], "data": [ { "dimension": "Publication control", "name": "Direct customer identifiers", "count": 0 }, { "dimension": "Publication control", "name": "Published customer messages", "count": 0 }, { "dimension": "Publication control", "name": "Published credentials", "count": 0 }, { "dimension": "Collection", "name": "Evidence briefs", "count": 6 } ], "evidence_kind": "Methods guidance", "findings_heading": "Methodological recommendations", "dataset_label": "No new empirical dataset", "evidence_scope_note": "This article explains the collection’s editorial workflow. Its recommendations and document counts are not experimental findings, validated privacy guarantees or a separately measured business outcome." } ], "modified_at": "2026-10-17", "editorial_note": "Collection 1.3 distinguishes retained operational observations, a synthetic protocol and methodological guidance. It adds evidence boundaries without changing the reported aggregate totals or original publication date. Version 1.2 removed preparation dates whose exact days were not established by retained records." }