cesnimda
3.2 KiB
Owner and operator qualification still required
All ten M09 human/provider cards remain NOT TESTED. Use the existing reproducible cards, which retain their original actions, expected behaviour, recordings and pass/fail criteria. This task supplies no human sign-off. Record the tested commit, actual browser/device/assistive-technology version, language/theme, synthetic account, exact card ID and recording; an automated result cannot replace that evidence.
Prioritise screen-reader reading order and announcements, keyboard/focus and cancellation, contrast/forced colours, actual browser zoom, physical touch/drag and orientation, Bokmål, PDF reopening/physical printing, and provider sandbox/outage recovery. Keep these separate. Preserve failures and incomplete observations. No production account, private CV or live provider connection is required for the local cards. Live provider qualifications require their separately approved environment and owner.
For a local owner session, use the source/build identities in validation.json, a synthetic isolated account and development MariaDB. Keep unavailable integrations and C11/P5-13 withheld. Do not interpret an enabled button or a healthy endpoint as intended-model, semantic or provider acceptance.
Hosted runner operator
Follow the six ordered actions in CI_ASSESSMENT.md. Supply effective job/service configuration and success/failure/cancel/interrupted-run cleanup evidence from a dedicated nonproduction runner. An assigned label, working Docker CLI or successful backup job is insufficient. No production Docker socket, database, deployment runner or secrets may be connected to this test lane. Hosted CI stays BLOCKED until real MariaDB execution and isolation evidence exist.
Model/cache rollout owner — separate production gate
The local qualification uses newly prepared, private, immutable-identity test artifacts. It does not modify or approve an existing production cache. Before any separately authorised rollout:
- Establish independent off-disk backup/restore and filesystem integrity evidence. Earlier EXT4/checksum reports remain unverified.
- Review the exact image, Python/native packages, pinned checkpoint manifest/licence and available memory/storage in a nonproduction rehearsal.
- Prepare and verify a separate cache. Prove its ownership and permissions. Do not mix old and new filelock participants or reset production/Ollama caches.
- Test offline cold start, actual extraction/inference, missing/corrupt artifacts, bounded resources, service failure and recovery using synthetic documents. Record the selected image/checkpoint identities and actual network behaviour.
- Review cache-switch/rollback and old-participant shutdown with the operator before deployment. This document does not authorise those operations or accept residual security risk.
GPU/driver compatibility, human semantic quality/C11, production capacity, application-level cancellation of in-flight trained-model inference, production cache migration and release approval are not established by the local CPU fixture. Their relevance must be decided against the separately authorised deployment/feature requirements.