# Runtime is more than HTTP 200

KF01 · Descriptive case report · 2026-10-05

A status service returned valid JSON while three external sources were missing. The browser and worker paths told different stories.

## Question

What does a successful HTTP response establish about an AI status service’s actual function?

## Method

A retrospective single case based on retained delivery logs and a browser report. The case was selected because transport checks, source data and browser interaction were documented separately. Selection was retrospective rather than random.

The worker response was read for HTTP status, content type and the three service result fields. An earlier browser report was placed alongside it without merging the timestamps or execution paths.

## Results

At 09:18 UTC on 5 October, /api/status returned HTTP 200 and application/json. All three providers still had unavailable / unknown results with source_read_failed. The delivery log’s outer passed value therefore did not establish successful retrieval of all provider reports.

The separate 09:28 UTC snapshot still returned HTTP 200. All three providers now had fetch_redirect_rejected. These fields alone do not establish the cause.

The earlier browser report recorded at 00:06 UTC showed three available reports and a working native refresh. It concerns the browser’s public CORS fallback and does not verify the worker path checked later.

The local correction record documents a native fetch bridge, bounded failure categories and passing focused fixtures. Its handoff explicitly calls actual r2 provider retrieval unknown. A passing fixture remains separate from the real runtime.

## What others can put into practice.

Check useful payload content as well as HTTP status: expected, present, fresh and usable?

Retain failed responses and verify fallback paths individually. A browser fallback should not erase a failing server path from the record.

Write separate acceptance statements: transport works; source retrieval works; the interface displays the supported state.

## Limits

One service with several dated execution paths. No claim about AI systems in general, today’s provider status or the final worker failure cause. No physical phone coverage or revenue evidence.

## Sources

- status-r1: cloudflare-ai-delivery-r1.json; SHA-256 2ccbfd544bf553a8b40faf6c3cf422bb95853d7750d94b0bc464897f51339e20; https://ki-forschungsportal.pages.dev/data/status-r1.json
- status-r2: cloudflare-ai-delivery-r2.json; SHA-256 1cd64421a4e6484c1298a4620d4edf1b4bd6042ee947cfd3761fc680baf8b6c0; https://ki-forschungsportal.pages.dev/data/status-r2.json
- status-browser: ai-status-final-browser-review.json; SHA-256 a8c5526f1c1fd43b600e5a1ddba3bc6e8a4f244abca2fc82af9e9dd8ce760330; https://ki-forschungsportal.pages.dev/data/status-browser.json
- status-correction: runtime-correction2-evidence.json; SHA-256 93e167320600250759a43c1028265ab6b921add51a25276b71763c999591358b; https://ki-forschungsportal.pages.dev/data/status-correction.json

Conflict of interest: The operator reports on owned projects. Selection is retrospective; no external peer review or sponsor-directed findings.

https://ki-forschungsportal.pages.dev/en/fallberichte/laufzeit-http-200/


---

# A 3D design needs its actual renderer

KF02 · Descriptive case report · 2026-10-04

A microphone model was visible, yet the initial styling was wrong. This retained case shows why runtime, styles and fallback need to be checked together.

## Question

How can a 3D extension be checked while preserving the browser tool’s core function and chosen style?

## Method

A retrospective design and implementation case based on two retained render images and a dated 3D review. Both images show the owned microphone interface without recordings, user data or account pages.

The review checked the actual procedural scene, native rotation controls, disable/re-enable, synthetic signal states, offscreen updates and forced WebGL unavailability. It covered the existing extension rather than a new hardware study.

## Results

The first render shows a white surface and partly default typography; the corrected image preserves the dark ink palette, cyan accents and readable native controls. The review records stale CSS on a reused local origin. A versioned stylesheet URL corrected the delivered identity.

Documented scene draw calls decreased from 43 to 20, with 37,960 triangles. These are structural measurements of this model. Without runtime measurements they do not establish a particular frame rate or general speed improvement.

During a synthetic offscreen signal change, the render count stayed at 1; re-entry painted the current 0.75 value at count 2. Forced WebGL unavailability preserved the native interface with an honest fallback.

The public 375 × 812 view had 360-pixel client and scroll widths according to the review. The retained template rebuilt offline to an identical bundle. This did not establish a later independent website reuse.

## What others can put into practice.

Compare the actual browser render with the chosen style. Visible geometry alone does not complete a design.

Check native core controls with 3D disabled and WebGL unavailable.

Pause unnecessary offscreen drawing and check that re-entry shows the current state. Keep scene structure counts separate from FPS measurements.

## Limits

Synthetic levels do not verify microphone hardware. No physical phone GPU or FPS benchmark. A real WebGL context-loss event and OS reduced-motion were not exercised. No causal quality or time comparison.

## Sources

- spatial-review: spatial-design-review.json; SHA-256 0f5c2140ae2cfe3ef7bab7d3a192ff02f43e9ad99f198bb0a103b0269ab73557; https://ki-forschungsportal.pages.dev/data/spatial-review.json
- template-render: template-copy-render-review.json; SHA-256 1616cacade6725766538599bb0db940dafbeffd79f7c768ce29acfcc8a56b296; https://ki-forschungsportal.pages.dev/data/template-render.json

Conflict of interest: The operator reports on owned projects. Selection is retrospective; no external peer review or sponsor-directed findings.

https://ki-forschungsportal.pages.dev/en/fallberichte/3d-entwurf-renderer/


---

# A package is not yet market success

KF03 · Descriptive case report · 2026-10-05

A checked 24-file package contained articles and ownership files. Which claims follow from that evidence, and which require new observations?

## Question

Where does a local release package’s evidence end?

## Method

A retrospective document analysis of the r4 package report for an owned guide portal and four related tools. The analysis ends at the recorded local handoff on 5 October. Later changes are outside this case.

For each claim level, the question was: which check actually ran? Package validation, runtime, browser delivery, ownership verification, indexing and market outcomes were read separately.

## Results

The report records a final 24-file package: four factual new articles, an exact IndexNow key and retained existing assets. Unchanged core files and corrected footer links were documented for the four tool packages.

Guards rejected unbound or conflicting manifests, input-bearing origins and incorrect key hosts. An initial QA assertion expected /api/* and rejected the valid narrower /api/upload-test route; it was corrected in a focused continuation.

Both runtime_calls and browser_checks were 0; publication was false. IndexNow ownership files were packaged, but delivery, ownership verification and submission were not established by this report.

Independent visits, ad revenue and per-tool revenue attribution remained explicitly unknown. Existing provider bindings alone do not establish use or payment.

## What others can put into practice.

Define an evidence ladder for each release: package → actual delivery → core function → external visit → attributable revenue.

Retain failed test assumptions too. An incorrect test can reject a valid narrow route.

Treat packaged keys as preparation until actual verification is recorded. Do not claim success metrics from internal QA alone.

## Limits

One local r4 handoff, not a statement about the portal’s present state. Reused earlier core checks are separate from new browser checks. Demand and profitability were not tested.

## Sources

- guides-package: r4-package-evidence.json; SHA-256 13941ecdfe9c5e3541d4f21431fd1b6fb1a3341ca732641a7790e62d43b487f7; https://ki-forschungsportal.pages.dev/data/guides-package.json

Conflict of interest: The operator reports on owned projects. Selection is retrospective; no external peer review or sponsor-directed findings.

https://ki-forschungsportal.pages.dev/en/fallberichte/paket-markterfolg/


---

# What a journal can actually measure

KF04 · Descriptive case report · 2026-10-06

The historical snapshot contains 131 events and 23 known total durations. It describes documentation gaps, not proof of faster or better AI work.

## Question

Which performance claims can a heterogeneous local evidence journal support?

## Method

A descriptive analysis of stored completeness aggregates dated 6 October 2026. The public extract contains only counts, observation date and the source fingerprint. Private event text is not published.

Counts capture whether total duration, input tokens, output tokens, a transfer field and a comparison key were present. Events were not randomised and comparable tasks were not reconstructed after the fact. This historical snapshot is not the current size of the subsequently expanded journal.

## Results

Of 131 events, 23 contained a total duration and 108 did not. This is 17.6% with a documented duration; the denominator is only this dated snapshot.

No events contained measured input or output token values. The newer transfer field was absent too. One event had a comparison key.

This does not imply zero token use. Missing values are unknown. Known durations are neither a random sample nor a controlled comparison of two workflows.

The visible figure shows field completeness only. A future comparison would need tasks, model/tool conditions, time basis, error costs and independent quality acceptance defined before execution.

## What others can put into practice.

Separate missing values from zero. An unmeasured value must not become 0 in a chart.

Record complete total durations with their time basis, including failures and rework.

Define a comparable workload and quality acceptance before the experiment; a result involving several skills does not isolate one skill’s effect.

## Limits

No causal effectiveness study, random sample or measured skill speedup. The fingerprint identifies the historical source state and does not establish external peer review.

## Sources

- journal-snapshot: research-portal-data-basis.json; SHA-256 8300f6829ccbc4d1ebe8cecfca7b0441f854eac21c966124b00f745b13d564b0; https://ki-forschungsportal.pages.dev/data/journal-snapshot.json

Conflict of interest: The operator reports on owned projects. Selection is retrospective; no external peer review or sponsor-directed findings.

https://ki-forschungsportal.pages.dev/en/fallberichte/journal-messgrenzen/
