Nightingale

Nightingale is a provenance, reproducibility, review, and governance workstation. It records scientific identity and versioned context around work performed in its owning product; it is not itself a scientific computation engine. Start with stable IDs and clear project membership so each record can be followed back to its source and owner.

The first local investigation is a clearly labeled demonstration. Create a local account and research project for your own science. Keep the demonstration separate from production evidence and preserve the distinction between imported facts, manually linked relationships, and inferred links.

Register scientific objects with stable global IDs, domain identifiers, source origin, classification, context, and a specific version. Link their dependencies upstream and downstream so a reviewer can see which data, methods, or product records contributed to a result. The lineage explorer distinguishes manually linked from inferred relationships.

Open the universal inspector for an object before relying on the graph. Confirm the current version, source context, status, and the exact dependency edges. A graph layout communicates connectivity, not quantitative influence or proof that a result can be reproduced.

Use Review Queue to attach a checklist, evidence checked, and a disposition to an exact object version. Record the reviewer and the reason for the decision. When scientific context changes, the current review state resets so an old approval is not silently carried over to a new version.

Review is a recorded judgment about a defined version, not proof that a result is correct. Inspect incomplete execution context, missing outputs, AI participation, assumptions, uncertainty, and possible duplicates when those dimensions apply. Keep the evidence consulted with the review so a later team can understand its scope.

When an upstream object changes, use dependency drift and impact views to identify downstream records that may need review. Compare the new dependency version with the pinned version used by each analysis or report. Do not automatically rebind a result to a newer source without checking whether the change affects its scientific meaning.

Nightingale exposes reproducibility dimensions and possible freshness issues. Use them as prompts for a human review, not as a single trust score. If a dependency is missing, stale, or unavailable, keep that status visible and explain whether it blocks the intended reuse.

Search audit events by object, actor, action, text, and capture time. Inspect before-and-after records for the change you care about. The audit trail can support internal review by making application events easier to follow; it does not guarantee that the underlying database has never been altered.

Capture immutable project snapshots when a state needs to be frozen. Compare snapshots to identify changes and apply release policies appropriate to the project. Export frozen states with the supplied files and SHA-256 fingerprints, then check the manifest and classification restrictions before sharing.

Project membership supports administrator, scientist, reviewer, and viewer roles. Membership changes take effect on the next request. Object classifications affect export handling; they are not a separate object-level access-control system. Accounts in a local instance are not externally identity-verified.

Local hashes and append-only application records detect or resist ordinary application-level changes but are not tamper-proof against a database administrator. Retention settings are advisory and automatic purge is not implemented. Before production use, configure backups and retention, review authorization boundaries, and plan for the operational scale of the graph.

The repository implements a local governance service and workstation. Live product connections, scientific computation, wet-lab execution, external AI generation, SSO, externally anchored signatures, and regulatory certification are not configured. Its deterministic provenance assistant runs documented graph queries and labels its behavior accordingly.

The current server evaluates the selected project's graph locally. Million-node operation requires a different graph projection and worker infrastructure and has not been validated. Treat Nightingale as a practical local recordkeeping and review layer whose controls need independent operational and scientific assessment before regulated or high-scale deployment.

Nightingale is a provenance, reproducibility, review, and governance workstation. Create a project for the group of records that shares an ownership and review boundary. Register an object with a stable global ID, domain identifier, source origin, classification, and scientific context so downstream systems can refer to it without relying on a display name.

The initial local investigation is demonstration data. Create a fresh project for real work and distinguish imported source records, manually entered relationships, and inferred links. Classification helps control export handling; it is not an object-level access policy. Do not use an illustrative record as a validated scientific result.

Create relationships that identify the upstream data, method, or product object on which a downstream result depends. Pin edges to versions and label a relationship as manually linked or inferred. Use the interactive graph to navigate neighbors and the universal inspector to check object identity, source context, current version, and relationship details.

A lineage graph displays recorded dependency and identity relationships; its layout does not represent measured influence or guarantee reproducibility. If the graph truncates a neighborhood or a source is missing, inspect the notice and use the record search or API to find the complete object set. Keep an explicit source citation for any relationship that carries scientific meaning.

When an object changes, enter a reason and create a new immutable version. The system retains earlier versions and structured field diffs so reviewers can see what was added, removed, or changed. Fork an object when you need to explore an alternative, archive an obsolete line of work, or restore historical state according to the project workflow.

A new version can change scientific context and invalidate an earlier review. Do not update labels in place to make a record appear unchanged. Inspect the source and derived-object links after each revision so downstream teams know whether they need to rerun, rebind, or review their work.

The review queue attaches a checklist, evidence checked, reviewer, and disposition to an exact object version. Record the scope of the review and any exceptions. If the scientific context changes, the current review state resets so a prior approval is not silently applied to a new object state.

Review is a recorded human judgment about a defined version, not proof of scientific truth. Consider assumptions, uncertainty, AI participation, missing outputs, execution context, and plan-versus-actual deviations where relevant. Keep the evidence used in the review accessible so another person can assess the disposition without reconstructing the reviewer’s memory.

When a dependency version changes, use drift and impact views to identify downstream records that may need review. Compare the new upstream state with the version pinned by a result or report. A freshness warning should prompt a human assessment; it does not prove the downstream result is wrong or automatically recompute it.

The reproducibility assessment covers documented dimensions such as missing dependencies, freshness, incomplete execution context, AI participation, output availability, and deviations between plan and actual execution. Treat these as separate diagnostics. A single completeness label cannot certify that a scientific result is reproducible, and an absent dependency must remain explicit rather than being silently rebound to the newest version.

Create an immutable snapshot when a project state needs to be frozen for an internal review or handoff. Compare snapshots to identify changed objects, relationships, reviews, or artifacts. Use the release policy to decide whether the current classifications and completeness state permit export, and record the policy and reviewer responsible for the release.

Exports include frozen project state and supplied artifacts with a structured manifest and SHA-256 fingerprints. Restricted classifications in current and historical state are checked during export. A manifest can show which objects and files were included; a fingerprint can detect changed bytes but cannot guarantee that an administrator has not modified the database or that the science is correct.

Search audit events by object, actor, action, text, and capture time. Open a record to compare its before and after state and export a filtered audit history. Source-reported event timing and local capture time are recorded separately so delayed integration delivery does not rewrite when an upstream system says an event occurred.

The project journal, source inventory, AI-participation inventory, assumption and uncertainty registry, notifications, and watchlist provide different views into research activity. Use the journal for sequence and context, the source inventory for origin, and audit search for change events. A complete audit log is useful evidence for review but is not itself tamper-proof storage.

Project membership supports administrator, scientist, reviewer, and viewer roles. Access is enforced at the project boundary, and revocation takes effect on the next request. Accounts authenticate to the local instance but are not externally identity-verified. External SSO is not configured in the repository, so deployers need to review their identity and access requirements separately.

Product integrations send authenticated, product-scoped event objects with stable retry IDs. Nightingale can write objects, links, and event records atomically, detect duplicates, and report failure diagnostics. Check the product scope, project, object versions, and source timestamp in the integration response. A successful ingestion records provenance; it does not execute scientific computation or independently validate the event's scientific statement.

The command palette and scientific console provide bounded domain queries rather than arbitrary shell access. The provenance assistant runs deterministic graph queries and identifies its behavior accordingly. It does not execute product jobs or generate scientific conclusions. The API and SDK can support integrations; authenticate them with scoped credentials and preserve stable object and event identifiers.

Original attachments preserve their bytes and checksums within documented per-file limits. Back up the SQLite database and associated artifacts together, and test restore procedures. Retention settings are advisory and automatic purge is not implemented. The current server evaluates the selected project's graph locally; million-node scale requires different projection and worker infrastructure and has not been validated.

Append-only application events and SHA-256 fingerprints can detect or resist ordinary application-level changes. A database administrator can still alter local storage, and no externally anchored signature service is configured. These controls should be described as integrity aids, not as tamper-proof audit evidence.

Nightingale is not a regulatory certification, validated electronic-signature system, or guarantee of scientific reproducibility. Live product connections, computation, wet-lab execution, external AI generation, SSO, automatic retention purge, and regulatory certification are not configured. Before production use, review authentication, backups, classification policy, operational capacity, and independent security or scientific validation.