Research and operating-system architecture

Architecture objective

The operating system must let multiple human and machine providers conduct falsifiable FE research, preserve contradictory and negative results, and move accepted knowledge into engineering without confusing:

• a source with evidence;
• evidence with an inference;
• an inference with a decision;
• an accepted record with an execution draft;
• tool conformance with scientific validity;
• repository coherence with field maturity.

Layered model

Required separation of state

1. Execution-local draft: provider-owned, mutable during the run, never treated as canonical.
2. Submitted candidate: content-addressed or commit-addressed packet, closed for review.
3. Reviewed candidate: findings and objections recorded; still not accepted.
4. Accepted canonical: promoted by named authority under a decision record.
5. Superseded or rejected: retained, discoverable, and linked to its successor or rejection rationale.

Generated registries are indexes of these records; they are never authority by themselves.

Minimum record envelope

Every research and engineering record should carry:

• stable ID, record type, title, semantic version, status;
• creation and update timestamps;
• author/provider and execution ID;
• governing profile and repository commit;
• parent, source, evidence, hypothesis, theory, decision, and derived-artifact dependencies as applicable;
• confidence and completion expressed separately;
• supersedes and superseded-by links;
• change summary and migration impact;
• explicit limitations and next action.

Content schemas then add type-specific fields. A confidence value must state what claim it qualifies; completion must state which contract was completed.

Evidence semantics

Mission lifecycle

1. Orient to canonical state and inspect repository changes.
2. Register a mission and decision owner.
3. Freeze question, dimensions, candidate explanations, outcome measures, exclusions, stop rules, and analysis plan.
4. Create provider execution boundaries and immutable source identifiers.
5. Collect direct observations; record access failures and negative evidence.
6. Search explicitly for counterexamples and full subsumption.
7. Build claim-to-source and claim-to-hypothesis traceability.
8. Run validators and substantive review independently.
9. Submit a closed candidate packet.
10. Decide, promote, narrow, reject, or supersede with impact analysis.
11. Export accepted engineering inputs through a release contract.
12. Monitor downstream use, cost, failures, and recovery; retire when the boundary or value no longer holds.

Validation stack

No lower row can be inferred from a higher row. In particular, schema validity cannot stand in for empirical validity.

Human and agent control model

• Every execution declares provider, model/tool version where applicable, role, write boundary, allowed actions, and conflict owner.
• Same-provider role separation is not independent replication.
• Agents may draft evidence and syntheses but may not self-authorize acceptance, theory mutation, or consequential deployment.
• High-impact decisions require a named human or institutionally delegated authority.
• Concurrent writes use disjoint execution paths; canonical promotion is a serialized operation.
• Prompt, tool, source, and environment changes are configuration changes and must be recorded.
• Secrets, private data, licensed source text, and personally identifiable information stay outside research artifacts unless explicitly governed.
• A failed or interrupted execution retains a partial manifest and reason; it is not silently erased.

Minimal and full modes

Minimal mode

Use for reversible, low-consequence, narrow work:

• mission;
• pre-registration or acceptance statement;
• sources/inputs;
• result;
• limitations;
• handoff;
• schema and reference validation.

Full mode

Add for novel, cross-domain, safety-relevant, high-cost, or canonical work:

• competing hypotheses and kill criteria;
• source registry and evidence ledger;
• comparative or controlled protocol;
• risk and ethics review;
• independent replication or adjudication;
• decision record and migration plan;
• monitoring, incident, recovery, and retirement plans;
• cost and cognitive-burden telemetry.

The selected mode and reason must be recorded. Artifact count is never a proxy for rigor.

Export contract into engineering

Research output may enter the engineering discipline only through a versioned release packet containing:

1. accepted definition and boundary;
2. supported and unsupported claims;
3. requirements and quality attributes;
4. evidence and confidence per claim;
5. architecture decisions and alternatives;
6. machine-readable schemas and conformance tests;
7. risks, ethical constraints, and prohibited uses;
8. acceptance criteria and test vectors;
9. compatibility, migration, rollback, and retirement rules;
10. unresolved hypotheses and required telemetry.

The receiving discipline should import this packet, not the entire mutable research workspace.

Maturity gates

The immediate goal is G3, not curriculum, credentialing, or discipline branding.

The controlling EX-FE-0002 mechanism-boundary experiment is a dependency inside G2: it remains Stage A incomplete and Stage B blocked. This package's same-provider source synthesis is candidate repair input, not satisfaction of its independence, blinding, recognition, or review requirements.

Architectural decisions

• Preserve v1.0 as the accepted pilot; propose compatible v1.1 changes.
• Treat FE-CFDP as one evidence stream, not as the umbrella for all FE missions.
• Add an explicit mission/experiment stream for boundary and utility studies.
• Validate execution-local draft records and packet completeness before submission.
• Generate registries for every supported record type and taxonomy, or explicitly mark a type as non-indexed.
• Make cross-repository dependencies machine-checkable.
• Record accepted research exports as releases with a receiving owner.
• Delay automatic framework generation and autonomous theory mutation until G3–G5 evidence exists.
• Complete or explicitly supersede EX-FE-0002 before starting the matched outcome experiment; preserve its inconclusive state until then.