Conformance and Evidence

Conformance is scoped to a tested implementation revision, workflow, selected exact profiles, release artifacts, suite and environment. A schema-valid object, support declaration or passing deterministic test is insufficient evidence of production enforcement. The execution contract defines processing; control profiles define the obligations to assess.

Three distinct claims

Current repository status: the first two surfaces are implemented. Five synthetic composed workflows cover personal scheduling, enterprise refund, delegated research, a lost provider acknowledgment and a high-assurance release with missing runtime evidence. Their useful reference paths pass while runtime assessments remain insufficient_evidence. Simulated “verified” inputs test assessor logic; they are never production attestations.

Report scope and trusted inputs

ConformanceReport includes its version/ID, implementation ID/revision, workflow ID, selected profiles, effective required controls, registry/suite/release refs, environment description/configuration ref, observation interval, evaluator, control rows, utility rows and declared outcome. Control statuses are passed, failed, unsupported and not_evaluated. Each control row includes case results, evidence refs, reasons and limitations.

ConformanceAssessmentInput supplies the pinned contract/registry/support, trusted admitted feature set, expected workflow/implementation/release/environment scope, required utility-case IDs, explicit evaluation time, trusted assessors/observers and separate verification observations. The report cannot select its own easier required utility case or claim verified evidence merely by adding a flag to a row.

The report-verification digest binds the complete canonical report under contextos.conformance_report.v1. Evidence observations bind that digest, the evidence artifact and its actual bytes, provenance (runtime or synthetic), trusted observer and validity interval. Adapters must authenticate these observations and assessor identities before invoking the pure TypeScript assessor. Identical strings in untrusted JSON do not establish authenticity.

Assessment algorithm and failure outcomes

1. Validate closed bounded shapes and safe canonical serialization. Reject malformed inputs without exposing caller payloads or exception details.
2. Negotiate the exact selected profiles and feature-conditional union against the pinned registry/support declaration. Unsupported mandatory controls prevent admission.
3. Match implementation, workflow, release, environment, registry, profiles and effective control set to trusted scope. Verify the report digest, evaluator and current report interval.
4. Reject duplicate/conflicting control or evidence rows. For every mandatory control, require current verified runtime evidence and all registered useful/denied case IDs. Additional failed cases cannot be hidden behind passing registered cases.
5. Require every trusted workflow utility-case ID to pass with current evidence. An always-deny implementation fails utility. Empty control/test/evidence arrays cannot produce a vacuous pass.
6. Preserve optional unsupported controls and explicit limitations. Return passed, failed or insufficient_evidence for the exact scope.

Observed verified failed controls/cases yield failed. Missing, stale, unverified, unsupported, synthetic or not_evaluated mandatory evidence yields insufficient_evidence. A report’s self-declared passed outcome never overrides those checks. Both non-passing outcomes prohibit a passing runtime-conformance claim; deployments define the corresponding admission/escalation action.

Evidence collection responsibilities

Required evidence is proportional to the actual workflow and threat/failure model. Authorized fault/abuse testing stays within an agreed environment and scope. A reference fixture does not authorize live attacks, customer effects or third-party messages.

Reproducible reference checks

The repository’s module tests exercise policy-error failure, full nested canonical hashing, authority attenuation, exact approval binding, boundary readiness, all nine data-flow stages, memory lifecycle, explicit run transitions, provider-specific retry gates, checkpoint pins, aggregate budgets, profile composition and evidence aggregation. The composed workflow suite calls those real helpers together using fixed times and synthetic artifacts.

rtk npx vitest run tests/execution-workflows.test.ts
rtk npx vitest run tests/conformance.test.ts tests/deployment-profiles.test.ts
rtk npm run typecheck

These commands are reference verification instructions, not a claim that they ran in the reader’s environment. ReferenceValidationReport binds suite, release and fixture refs to actual case statuses and explicitly sets runtime_controls: "not_evaluated". It cannot use the runtime outcome passed. The initiative’s version-controlled verification log records observed commands and limitations; a passing result does not replace runtime evidence.

Release changes, portability and domain assurance

Change policy, tools, models, extensions, processor routes or sandbox configuration only with impact review and reevaluation of affected evidence. Restore pins rather than silently interpreting saved work under new policies. Document rollback limits and provider-model revisions that cannot be pinned. Expired evidence must be renewed before protected work depends on it.

Cross-runtime portability requires independently tested runtimes interpreting the same profiles and fixtures, with recorded interoperability results. This repository has not established that evidence. A single TypeScript reference and JSON Schema validity cannot prove it.

For mission-critical workflows, write the scoped assurance case: intended/forbidden effects, threat/failure model, dependencies, responsible humans, stop/escalation authority, recovery objectives, observed drills and known limitations. Clinical, financial, legal, industrial and physical-control obligations require domain-specific review and independent safeguards. No ContextOS profile alone proves legal compliance, professional authorization or physical safety.

Publication and rights

Normative requirements, reference checks, illustrations and demonstrated runtime properties must be labeled accurately across docs, pages, articles, schemas and downloads. Preserve historical dates; correct unsafe examples with truthful modification metadata and current canonical links. Published content must not promote synthetic evidence into a certification or claim universal readiness.

ContextOS makes the specification publicly readable and describes interoperable boundaries. The current repository license remains all rights reserved; this work grants no additional reuse rights. Standards stewardship/licensing decisions and externally certified claims require separate authorization. See Runtime API Schemas for the serialization surface and Control Profiles for exact applicability.