Start here

From a messy packet to a decision you can defend.

T2K maps supported source material into structured, reviewable knowledge through deterministic workflows. It keeps the source, proposed meaning, recommendation, and human decision separate so you can see exactly how an answer was reached.

Start the tutorial Learn the model first

Understand it in two minutes

T2K gives information a job and a boundary.

The ontology is the reusable language. Facts belong to a specific business or project. Reasoning combines those facts with an objective and policies. A person or authorized system still owns the decision.

Source

The document, note, file, or URL where information came from.

A customer concentration report or owner interview.

Ontology

The shared vocabulary that says what kinds of things exist and how they relate.

A Customer renews a Contract; a Policy constrains an Action.

Claim

A statement the system can trace, review, accept, dispute, or replace.

Three customers represent 58 percent of recurring revenue.

Knowledge graph

The local network of entities, claims, relationships, and evidence for one project.

Northstar, its customers, renewal risk, and the sources supporting each fact.

Decision Context

A frozen decision packet: facts, objective, policies, options, uncertainty, and authority.

Renewal plan vs. security remediation, judged against first-100-day goals.

Publication

An approved copy of selected knowledge shared with another graph.

A redacted diligence metric shared without exposing the source business identity.

The important separation

Evidence can support a decision. It cannot quietly become one.

A source is evidence, not automatically a fact.
An extracted claim is a proposal until its support is checked.
A recommendation is not an authorized decision.
An action is not complete until its outcome is recorded.
Knowledge does not cross graph boundaries without an explicit publication.

After the decision

Turn outcomes into evidence for the next policy.

Decision Episodes preserve state, reasoning, authorization, execution, observation, reward, and policy provenance without silently changing production behavior.

Learn the closed loop

Hands-on tutorial

Build your first useful workspace in 15 minutes.

You will turn one fictional SMB note into a cited risk view, review a system suggestion, and produce a diligence handoff. No integration or ontology expertise is required.

01
Create
Open the right workspace
From Home, choose Diligence Research Pilot. Name it Northstar Bicycle Supply review and create the workspace.
Done when: The workspace opens and Diligence Research appears in its metadata.
02
Intake
Add one useful source
Set the source title to Operations and risk summary, keep Kind as Note, paste the example below, and select Queue source.
Done when: The source status becomes ready and the source appears in the left rail.
03
First Pass
Check what T2K understood
Read the first-pass brief. Confirm that company, customer concentration, security review, and an open diligence gap appear.
Done when: You can name one extracted fact and one missing piece of evidence.
04
Graph
Inspect meaning and evidence
Open a node, claim, and relation. Follow the support text back to the source anchor; do not approve an item you cannot trace.
Done when: You have verified at least one claim against its cited source span.
05
Grounded Q&A
Ask only what the workspace can support
Choose Biggest concerns. Read the answer, citations, confidence posture, and next move. Mark it Supported, Weak, or Wrong.
Done when: An answer run and your feedback appear in Answer History.
06
Suggestions
Keep the human in control
Review the missing renewal evidence suggestion. Accept, reject, or leave it open based on the source, not the recommendation label.
Done when: The review decision is visible in the queue and activity history.
07
Research and Report
Fill a gap, then produce the handoff
Run internal research first. Keep outside research off unless needed. In Report, inspect the briefing and evidence tabs, then export the memo.
Done when: The report distinguishes supported facts, open gaps, and reviewed decisions.

Example source

Operations and risk summary

Northstar Bicycle Supply is a 24-person bicycle-parts distribution company. The company sells through an online ordering platform and a field sales team.

Three enterprise customers represent 58 percent of annual recurring revenue. The largest customer renews in 90 days. The current packet lacks cohort-level retention evidence and still needs stronger evidence about customer renewal patterns.

The security review found that vendor access is removed manually. SOC 2 remediation is in progress, but an owner and completion date have not been documented.

The buyer's objective is to protect recurring revenue during the first 100 days while keeping gross margin above 30 percent. Company policy requires finance approval for discounts above 10 percent and 30 days of notice before a material pricing change.

Open question: should the transition team prioritize the renewal plan or the vendor-access remediation first?

Fictional training data. It is intentionally small enough to verify every extracted claim against the original text.

Your finish line

You are done when you can answer four questions.

What does the source actually say?What did T2K infer?What is still unknown?Who is allowed to decide what happens next?

Practical how-to

Use the same control pattern for common work.

When in doubt, return to the source, preserve uncertainty, and make review or authorization explicit.

01Correct something T2K extracted

Open Graph, select the node, claim, or relation, and compare it with its support. Edit the object when the meaning is wrong. Use Suggestions when the proposed change came from the system. The activity log preserves who changed what.

02Handle two sources that disagree

Keep both source-backed claims. Mark the conflict, open a review comment or dispute, and decide which source has authority for that predicate and time period. Do not silently overwrite one source with the other.

03Research beyond uploaded material

In Research, run Internal only first. Switch to External beta only when the workspace policy permits it and an internal gap remains. External findings stay in a separate review lane until a person accepts a graph change.

04Bring a teammate into the review

Open Access & Settings, create an invite, and choose viewer, editor, or owner. Assign review items and use object comments so the reason for a correction stays attached to the knowledge it concerns.

05Review a TransferOS ontology

Choose TransferOS Ontology Review. Add the approved business-context profile first, then the ontology manifest JSON. Review identity, relationships, source authority, time, policies, and decision rights. Keep raw client records outside the manifest.

06Connect another application

Use an API key with the versioned /api/v1 routes or connect through MCP. Start with a private workspace graph, write entities and evidenced claims, then create Decision Contexts. Sharing to another graph always uses a controlled publication.

07Learn from what happened after a decision

Deploy the baseline before creating the final Decision Context, then open a Decision Episode so the frozen policy cannot drift. Record receipts and sourced observations, assess the reward vector, and use disjoint held-out episodes for computed replay. Proposal, evaluation, promotion, deployment, and rollback remain separate governed steps.

For SMB teams

Start with a real decision, not a giant ontology.

Pick one recurring decision, three to seven representative sources, and the people who can verify them. Expand the ontology only when the next case needs a distinction the current model cannot express.

Create a workspace

For developers

Integrate through one governed contract.

Use @t2k/core, /api/v1, or MCP. Compile ontology packs before binding them, keep project facts graph-local, preserve evidence locators, and freeze a Decision Context before authorizing actions.

Developer platform

For ontology authors

Reuse meaning without copying project data.

Start with the SMB Ontology Authoring template. Declare the business context, test normal and exception cases, and promote a definition only after it proves reusable across projects.

Pack templates