Project work
Scientific analysis,
adaptation and review.
Start with one research question and a workflow we can examine. Agree the scope, evidence and deliverables before work begins.
Workflow map · illustrative scope
Carry the meaning with the data.
Each stage changes the data. Its contract records what must remain true and what needs a separate review.
-
01 / INPUT
Counts + metadata
Genes in rows. Cells in columns. Study information alongside.
Check at this boundaryMatch cell identifiers to metadata. -
02 / PREPARE
Choose + transform
Record filters, normalization choices and their dependencies.
Check at this boundaryKeep identities aligned after filtering. -
03 / COMPARE
Define a comparison
State the contrast, experimental unit and family of hypotheses.
Check at this boundaryPreserve contrast direction and family identity. -
04 / REPORT
Result + evidence
Attach the method, code revision, scope and unresolved questions.
Check at this boundaryBind each result to its analysis record.
Study designDo the samples support the intended comparison?
Statistical modelAre its assumptions suitable for these observations?
Biological meaningDoes the interpretation follow from the study and its limits?
How could evidence attach to a stage?
A test covers chosen cases. A runtime check inspects a run. A proof establishes a formal claim within stated assumptions.
The appropriate evidence depends on the property and its implementation. These checks are examples, not completed verification work.
Research illustration. The arrows describe a possible workflow, not a claim that a complete pipeline has been formally verified.
Scientific analysis
Work can begin with a biological question and a dataset. The initial focus is single-cell transcriptomics, starting from counts matrices and study metadata.
Possible projects include analysis planning, reproducible workflows and interpretation of computational results. The study design determines which comparisons are meaningful.
Possible deliverables: an analysis plan, reproducible code, documented choices and a report that separates results from limitations.
Adaptation and review
Changing a dataset or extending a pipeline can change the meaning of an analysis. We can examine those changes alongside the code.
A review may trace preprocessing dependencies, check contrast definitions, or make the family of hypotheses explicit before multiple-testing correction.
Possible deliverables: a workflow map, a record of assumptions, focused tests and a list of changes worth making.
Verification feasibility
Start with one property that matters. Write it precisely, identify the implementation it concerns, and assess whether a machine-checked proof is practical.
Formal verification is part of our ongoing R&D. Proof work is scoped after a feasibility review; an entire existing pipeline may remain outside that scope.
Possible outputs: a reviewed specification, a proof for an agreed component, or a documented account of unresolved proof obligations.
What a project should make clear
- The question, inputs and unit of analysis.
- The exact code and properties covered.
- Which results come from tests, checks, proofs or scientific assumptions.
- What remains uncertain, and who reviews it.
A mathematical claim and a biological conclusion need different kinds of evidence. See the distinction.
Starting a conversation
A dedicated route for project inquiries is being prepared. For now, the mailing list can record your interest in future updates.
Confirmation emails are not being sent yet. The signup page explains the current delivery status.