Operating and evidence method

Two status systems

NeuroForge reports two independent dimensions:

• Commercial availability asks whether an engagement can be scoped: available, qualified, gated design partner, research only, or held/no-bid.
• Evidence maturity asks what a technical record supports: validated, provisional, candidate, unproven, or blocked.

Candidate does not mean available. An internal gate does not mean production ready. An available founder-led service does not mean repeatable software or a production SLA.

Source ownership

The business repository owns company positioning, offers, durations, boundaries, prerequisites, no-bid rules, and acceptance templates. ERAIS owns technical implementation facts, claims, evidence maturity, artifacts, and prohibited inferences. The site owns presentation, accessibility, discovery, and committed public-safe snapshots.

The production build never reads a mutable sibling repository. Every public record retains an exact full source commit and artifact identity.

Engagement lifecycle

1. Qualify. Name the decision, economic owner, technical and data owners, deadline, rights, environment, and fatal no-bid conditions.
2. Freeze. Lock the workflow or question, representative inputs, baseline, model/data/config identities, acceptance, failure taxonomy, and stop rules.
3. Build, audit, or run. Preserve failures, warnings, deviations, interruptions, and source changes contemporaneously.
4. Witness. Test the result against the signed matrix; a successful demo is not acceptance by itself.
5. Hand over. Deliver evidence, limitations, and an appropriate restore, rollback, or reproduction path.
6. Decide. Accept, remediate, extend, or stop—without silently changing thresholds.

Public evidence lifecycle

1. Select a deliberate, pushed ERAIS candidate and resolve it to a full commit SHA.
2. Read committed artifacts from that exact Git object, never dirty worktree state.
3. Import only the approved public-proof disclosure tier and sanitised aggregate evidence.
4. Validate schemas, counts, units, finite values, source digests, and status vocabulary.
5. Reject private paths, prompts, datasets, checkpoints, weights, sensitive identities, secrets, and protected mechanisms.
6. Keep measured results, controls, and projections visually and semantically separate.
7. Build charts, tables, pages, downloads, claims, and machine context from the same records.
8. Require human review before the one production deployment.

Negative and null results

A negative result is not a publishing failure. If a sparse rung regresses, an audit recommends hold, a workflow cannot fit the boundary, or a hypothesis fails, the outcome stays in the record and may be the correct decision. Thresholds, baselines, and holdouts are not rewritten to rescue a desired narrative.

Scout results

Scouts can guide engineering. They cannot reach the public site as performance or quality claims until the exact candidate is pinned, identity/parity checks pass, the relevant endpoint is repeated under a declared protocol, claim review closes, and the result retains every material limitation. Component timing is labelled as component timing.

Threats to validity

Small probes may not generalise to larger models, workloads, contexts, or hosts. Implementation breadth does not establish customer operability. A complete evidence inventory does not prove model quality. Projections can be useful yet operationally wrong. Controlled-disclosure aggregates may not enable independent reproduction without an approved agreement.

Inspect the claim register, status, and evidence details for the source and boundary attached to each public statement.