Three states.
A field of possibilities.

Make ternary computation a foundation people can build on.

Our ambition is to make Urizen the premier research lab for ternary computation and its applications. We investigate ternary computation across mathematics, computer architecture, learning, and cryptography.

Our working theory treats learned systems as executable programs whose behaviour depends on context. It connects ternary representations, bounded machine execution, and finite computational cells. We test those connections in hardware, learning methods, and private computation. Each application carries its own evidence and limits.

Intuition opens a path. Reason gives it form.

1. 1

   Start with the theory. State the claim, assumptions, and conditions under which it should hold.

2. 2

   Test what is uncertain. Choose the smallest experiment that can settle the question or change the next decision.

3. 3

   Interpret the result. Ask what the evidence establishes, what it contradicts, and what it leaves unknown.

4. 4

   Revise and build. Let that interpretation change the theory, implementation, or scope. Then repeat.

Imagination gives us questions worth pursuing. Careful reasoning makes them testable. We keep room for play, unexpected results, and a change of mind.

We value precise claims and decisive experiments. When further checking cannot change a decision, we record the limit and move on.

The products put the questions to work.

PaleFox develops ternary computer architecture. SandCat is our specified ternary inference engine project. Structural Descent studies learning and contextual programming. Tiamat explores coordination and settlement around receipts.

Nibiru Engine addresses confidential execution and receipts. Baobab governs goals, context, permissions, and verification. Anansi connects those rules to agent execution and code review.

Heimdall develops privacy-preserving eligibility and agent credentials. Esu connects identity and evidence across tasks. Their interfaces keep each component’s authority and evidence separate.

Say exactly what the evidence supports.

Some mathematical results are proved and machine-checked in Lean 4. Implementations are tested on declared cases. Other parts remain specified, conjectural, or open. A theorem about a bounded machine does not certify a deployed system; an experimental result does not establish every workload.

These distinctions guide both engineering and public claims. Read our evidence labels and product scope notes, or explore the Nibiru and Anansi demos.

Work with the lab.

Our products are in development, with different maturity levels and qualified scopes. Tell us the computation or workflow you have in mind, what must stay private, and what evidence you need. Start a conversation.