01
Teams working with requests, commitments and follow-up
Service and hospitality
The same message can carry a request, a promised action and missing information. Losing one distinction can change what should happen next.
Explore this use case →
RESEARCH OBJECTIVE / PRACTICAL POSSIBILITIES
Change the form.
Keep the meaning.
Connect what people say, what a system knows, and what happens next. Renigma is developing inspectable tools for work that depends on context, clear interpretation and reliable outcomes.
FORM STUDYAI-generated art
Not scientific evidence
Not scientific evidence
A research objective, tested one workflow at a time.SOURCE → CONTEXT → OPERATION → CONSEQUENCE
THE PRACTICAL PURPOSE
From information
to an outcome you can check.
A customer message, a product claim and an operating rule all mean something within a context. The challenge is to carry that meaning into a useful decision without quietly losing what matters.
Make the source visible. Make the interpretation reviewable. Make the consequence testable.
- 01 / SOURCE
What was said?
Keep the original message or record.
- 02 / CONTEXT
What does it depend on?
Name the relevant facts, rules and unknowns.
- 03 / OPERATION
What would change?
Review an explicit interpretation or action.
- 04 / CONSEQUENCE
Did it do what we needed?
Compare the expected result with an observation.
Look forward to the result a proposed operation would produce. Trace backward to the statements, assumptions and rules behind that result.
WHERE WE ARE
Working local tools, measured research and proposed domain applications. We will be explicit about which one you are looking at.
POSSIBILITIES IN YOUR DOMAIN
Start with the work.
Then choose the method.
These are potential applications of the research direction. Each starts with an operational question and needs a bounded evaluation in its own setting.
02
Teams comparing a description with reported experience
Commerce, reviews and claims
A product statement, a customer report and an inferred conclusion are different kinds of evidence.
Explore this use case →03
Creators and researchers examining responses to content
Media and audience discussion
Views and comment counts measure activity; they do not by themselves explain what a response contributes or why people engage.
Explore this use case →04
Teams that need an inspectable decision trail
Internal operations and scenario review
A changed instruction can alter a result while older predictions and reports still need to remain available.
Explore this use case →05
People changing a model, representation or numerical method
Research and engineering models
A simpler representation can appear accurate while erasing a distinction needed for the next operation.
Explore this use case →06
Teams with repeated structured calculations
Local analytical workloads
Moving work to a GPU does not guarantee a faster complete task, especially when startup and rebuilding dominate.
Explore this use case →THE CONNECTING IDEA / RESEARCH THESIS
Different domains.
Structured meaning.
A service request, a product claim and an engineering model can each be described through information, relationships and operations. Our research asks whether making those parts explicit helps people preserve the intended purpose and examine what would follow.
This is a research thesis and a way to design tests. It does not establish that every domain has the same structure or that a model can understand unrestricted language.
How the research areas connect →A MESSAGE · A RECORD · A MODEL
Purpose
ContextRelationshipsOperationsConsequences
A designed concept map.
Connections express the research question, not proof of equivalence.
ONE SMALL EXAMPLE
A changed instruction.
A different result.
The simplest useful demonstration needs no advanced mathematics. It needs the right information, the right order and a way to inspect a disagreement.
Green → blue → recall
Store green, replace it with blue, then ask for the value.
Expected answer: blueGreen → recall
Keep the first value and omit the replacement.
Expected answer: greenIf someone reports green against the baseline, retain the disagreement. A different report does not automatically rewrite the prediction or explain what caused it.
Follow the inspectable example →MEASURED RESEARCH / WORKSTATION-003
Use the right computation.
Keep the result intact.
A recent study reused unchanged calculations and selected CPU or GPU methods for each known workload. The test checked every saved output, not just the speed.
11.23×CPU baseline time ÷ selected execution time
48 held-out synthetic workloads. The separately executed choices took 8.15 seconds in total; the one-thread CPU baseline took 91.58 seconds for the same defined work units.
Startup, calibration, input/reference generation, evidence writing and verification are excluded. The measured units include setup, requests, updates, rebuilds, capture and teardown. This is a benchmark result, not an application speedup or production guarantee. This is a research benchmark on one workstation, not a measured speedup for a customer's application.
START WITH YOUR WORK
What needs to
stay true?
Bring a task, a source of information and a result you need to trust. We can discuss where the current tools fit, what would need to be built, and how to test whether it helps.
Discuss your use case ↗mr.white@jtech.aiAn exploratory conversation. Customer integrations and commercial arrangements are agreed separately.