Guided learning paths
Orient new teams with short, opinionated paths: first governed run, first promoted claim, first publish bundle—each with checkpoints that match how R&D actually reviews science.
For humans
Human documentation
Use these guides when people choose datasets, pick discovery modes, review findings, and decide what is worth acting on. They help researchers, reviewers, and operators collaborate without losing the thread from raw data to a usable result.
Campaigns and operational rhythm
Understand how longitudinal programs map to campaigns and runs so program managers, lab leads, and platform owners share one vocabulary for scheduling, budgets, and completion.
Explaining review rigor
Learn to explain Truth Dial tiers, negative controls, and ledger provenance to partners who will never read the notebooks but still need to trust the evidence chain.
Tutorials and cookbooks
Task-focused recipes for common scenarios: importing instrument data, comparing discovery modes, exporting replay recipes, and attaching claims to downstream systems.
Getting started
Your first interaction with CDE typically follows a predictable arc: create a project, attach a dataset, run a governed discovery pass, and review the resulting claims. This section walks through each step so you can orient quickly before branching into more specialized workflows.
A project is the top-level container for your research. It defines the scope, the team membership, and the governance configuration that applies to all campaigns and runs within it. When you create a project, you also select the default autonomy policies that will govern how automated systems interact with your data—these can be refined per-campaign later.
Once a project exists, you attach one or more datasets. CDE supports structured tabular data, time-series streams, and semi-structured formats. During attachment, the platform runs an initial profiling pass that characterizes the data's shape, coverage, and potential quality issues. This profile informs the causal discovery strategy and what constraints the engine can enforce.
Your first governed run
A run is a single execution of a discovery mode against a dataset within the context of a campaign. Governed runs differ from ad-hoc analysis because every step is recorded in the Evidence Ledger and every resulting claim enters the Truth Dial at the Explore tier.
Step 1: Define your causal question
Specify what you want CDE to discover: directed causal structure, governing equations, intervention effects, or a combination. CDE selects and combines internal methods based on your data profile and the causal question. You configure the scope, not the method.
Step 2: Configure and launch
Configure parameters for the causal discovery run: temporal windows, intervention specifications, constraint sets, and governance tier. The platform validates parameters before launch and warns if the configuration is unlikely to produce meaningful causal claims given the data profile.
Step 3: Review claims
After a run completes, its claims appear in the Explore tier of the Truth Dial. Each claim includes the evidence that supports it, the scope boundaries within which it holds, and references back to the specific data subsets and parameters that produced it. Each claim review includes evaluating the evidence chain that connects the conclusion to the raw data.
Step 4: Promote or refine
Claims that survive scrutiny can be promoted to the Validate tier, which signals that they have passed initial review and warrant further investigation—perhaps through negative controls, alternative mode runs, or cross-dataset validation. Claims that do not hold up are flagged but never deleted; the Evidence Ledger preserves the full history so future researchers can understand what was tried and why it was set aside.
Campaigns and runs
Campaigns are the organizational unit between projects and runs. A campaign groups related runs that share a research hypothesis or operational objective. For example, a pharmaceutical team might create a campaign for each screening round, with individual runs for different compound libraries or target configurations.
Campaigns carry their own budget allocations, completion criteria, and governance overrides. A campaign can tighten the default autonomy policy of its parent project—for instance, requiring human approval for any claim promotion during a sensitive validation phase—or it can expand permissions if the project configuration allows it.
Runs within a campaign are ordered chronologically and linked through the Evidence Ledger. When a researcher opens a campaign view, they see the full run history: which modes were used, what claims emerged, which claims were promoted or set aside, and how the overall evidence landscape evolved over time. This longitudinal view is what makes campaigns useful for programs that span weeks or months, not just individual analysis sessions.
Explaining review rigor
Review surfaces only matter if teams can explain them clearly. This section covers how to show non-technical stakeholders why a claim is credible and what the platform did to earn that credibility.
Explaining the Truth Dial
When presenting to external partners, frame the Truth Dial as a maturity model rather than a confidence score. Explore means "we found something interesting and recorded how we found it." Validate means "we tested it against alternatives and negative controls, and it held up." Publish means "we are confident enough to attach our institutional reputation to this claim, and here is the complete evidence trail." This framing avoids false precision and focuses on the process.
Presenting negative controls
Negative controls are the strongest governance signal because they represent attempts to disprove the claim. When presenting results, lead with what the negative controls tested and their outcomes. A claim that survived permutation tests, alternative-explanation checks, and subset holdout validation tells a stronger story than one that was only confirmed positively. If controls were skipped, the ledger records the reason—present this transparently.
Using ledger provenance
The Evidence Ledger provides content-addressed entries that trace every step from data ingestion to published claim. When compliance or regulatory partners ask "how did you arrive at this conclusion," the ledger answers that question with cryptographic integrity. Each entry links to its predecessor, forming a chain that cannot be modified without detection. Present this as an audit trail that exists independently of any individual researcher's notes.
Common workflows
These task-focused patterns cover the most frequent operations that research teams perform in CDE. Each workflow is self-contained and includes the governance implications of each step.
Importing instrument data
Attach raw instrument output to a project, run the profiling step, review the data quality assessment, and resolve any coverage gaps before launching discovery. The profiling step creates the first ledger entries for the dataset, establishing its provenance baseline.
Comparing discovery modes
Run the same dataset through multiple discovery modes within a single campaign to compare their outputs. The platform does not prescribe which mode is "better"—comparison is domain-specific. The campaign view lets you see all claims side by side, with provenance links back to the mode and parameters that produced each one.
Promoting claims through tiers
Select claims from the Explore tier, run negative controls against them, review the control outcomes, and promote surviving claims to Validate. Record the rationale for each promotion decision. Claims that reach Validate can later be bundled into a publish package with frozen evidence context for external distribution.
Creating publish bundles
Publish bundles freeze the evidence context for a set of claims at the Publish tier. The bundle includes the claims, their full provenance chains, the negative control results, and any attached artifacts. Once sealed, a bundle cannot be modified—it serves as the permanent external-grade record of what was found and how it was validated.
Pair these guides with the API and SDK references when you are ready to automate—human docs explain intent; machine docs explain contracts.