Decision-memory, not generic memory
The goal is not to store everything. The goal is to surface the parts of history that materially change a workflow decision.
Core technology
Intuition Memory Layer
Turns fragmented workflow history into decision-ready context.
Support_v1 is the first pilot-ready application of IML in a bounded support routing workflow.
At a glance
01
IML is the core product thesis
02
support_v1 is the first pilot-ready proving ground
03
An internal eval and pilot-ready stack already exist
04
Broader workflow paths follow only after first pilot evidence
What IML is
A layer for decisions that need more than raw memory recall.
IML sits between memory systems and decisioning systems. It reconstructs historical context into a bounded, reviewable layer that a workflow can actually use at decision time.
Reviewable context, not blind automation
IML is designed to keep decisions inspectable so a pilot can be evaluated with disciplined human review.
A core layer, not a narrow point tool
support_v1 is the first applied vertical, but the underlying technology thesis is broader than support routing.
Technology view
Memory -> IML -> decisioning
A concise view of IML as the layer that turns workflow history into bounded, usable decision context.
Why this layer matters now
Workflows have memory and models, but still lack a disciplined decision layer.
Teams can now store history, retrieve fragments, and run models, but that still leaves a gap between raw recall and a reviewable operational decision. IML is meant to fill that gap.
Memory alone does not decide
A workflow still needs the right historical shape, not just more stored data or a longer context window.
Decisioning needs structure
Operational choices need a layer that can reconstruct decision context in a repeatable and inspectable way.
Proof needs bounded deployments
A credible technology story starts with bounded evidence in a real workflow before it expands into broader platform claims.
Why support is first
Support is the first wedge because it is verifiable, bounded, and commercially useful.
Support gives IML a serious first proving ground: real exports, visible decision points, constrained pilot scope, and a workflow where review quality can be examined directly.
Verifiable decision points
Support routing creates concrete moments where better historical context can change whether a case follows a standard or careful path.
Real workflow data
Exports, event history, timestamps, and case progression create the practical substrate needed for a disciplined pilot.
Pilot evidence before platform claims
Support is the first beachhead because it allows claims to stay bounded while evidence compounds.
Commercial wedge
A narrow first use-case creates a real entry point for partner conversations without pretending the full platform already exists.
First application
support_v1 is the first pilot-ready applied vertical for IML.
support_v1 applies IML to support routing workflows. It is not the whole product. It is the first place where the core layer is being shaped into a bounded pilot-ready implementation.
Applied workflow
support_v1 in practice
A restrained visual for the support_v1 flow from export intake through reviewable routing evaluation.
Workflow
How support_v1 applies the layer
01
Export intake
The workflow begins from a bounded support export or a controlled support slice suitable for pilot evaluation.
02
Validation and normalization
Incoming data is checked for structure, ordering, coverage, and transformed into the working schema needed for evaluation.
03
History reconstruction
Visible support history is rebuilt so routing decisions are evaluated against actual case context rather than isolated records.
04
Routing evaluation
The layer compares routing decisions on labeled points to test whether better decision context improves the path choice.
05
Reviewable pilot output
The result is a reviewable routing layer for a bounded pilot, not a claim of unattended production automation.
Already in stack
What already exists in the pilot-ready stack
Internal eval paths across labeled_support, raw_ingest, csv_ingest, mapped_ingest, and zendesk_like modes
Validation logic for export usability before deeper evaluation continues
Normalization into the working schema used by the current stack
Event and case-history reconstruction for support decision points
Comparison and calibration logic for bounded routing evaluation
Pilot packaging and handoff materials for first external onboarding
Current proof and pilot readiness
The evidence supports a bounded pilot story, not universal proof.
The strongest current claim is that IML already has a serious internal eval layer and a pilot-ready support workflow. The evidence is meaningful enough for a first pilot conversation, while still bounded in scope.
On the strongest current raw_ingest / combined_ab slice, calibrated IML reaches 92.31% versus 69.23% for the best non-calibrated baseline.
Calibrated IML
92.31%
Best baseline
69.23%
Observed delta
+23.08 pp
Strongest current slice: raw_ingest / combined_ab
Honest note
Honest note: this page should not imply universal domain proof, broad deployment, or a fully production-ready platform. The current truth is a core technology thesis with a first pilot-ready application and a bounded evidence layer.
Internal eval stack exists
The current stack is more than a concept. It already supports intake, validation, normalization, reconstruction, evaluation, and pilot packaging.
support_v1 is pilot-ready, not broadly deployed
The right claim is a bounded first pilot path with manual review, not a broad production rollout story.
Evidence remains uneven outside the strongest path
The strongest slices support a pilot discussion, while weaker ingest paths still need more evidence before stronger claims should be made.
Roadmap
From core layer to broader workflow applications, one bounded step at a time.
The roadmap should show expansion logic without skipping the pilot stage. Each step depends on evidence from the prior one rather than on abstract platform language.
01
Core technology: IML
Continue hardening the decision-memory layer, evaluation logic, and reviewable decision framing that define the product thesis.
02
First applied vertical: support_v1
Use support as the first proving ground where IML can be evaluated on real decision points and real export-derived context.
03
First real pilot / export onboarding
Onboard a first partner on one bounded workflow slice, one export path, and one tightly reviewed pilot scope.
04
Second use-case after pilot
Test a second applied workflow such as an e-commerce user-profile layer or a CRM entity workflow, first on synthetic data and then on 1-2 real cases.
05
Broader workflow / agent use-cases
Only after compounding pilot evidence should IML expand into wider workflow and agent-oriented decision contexts.
Roadmap view
Evidence-led expansion
A sequenced view from the core IML layer to the first pilot and only then to broader workflow applications.
Beyond support
The broader story starts after the first pilot proves out the layer.
The next chapter is not an immediate cross-domain rollout. It is a second bounded use-case where the same decision-memory logic can be tested on another workflow shape.
E-commerce user-profile layer
A decision-memory layer that reconstructs user history and profile state before key service, risk, or lifecycle decisions are made.
CRM entity workflow
A layer that keeps account, contact, and entity history usable at the moment a workflow needs to decide how to route or act.
Likely next use-cases
The expected path is synthetic data first, then 1-2 real cases after the first support pilot creates enough evidence to justify a second vertical.
Contact
Discuss a bounded first pilot.
If you have support exports and want to evaluate whether IML can improve decision quality on a bounded workflow slice, the right next step is a pilot-fit conversation.
Share your export shape, current routing workflow, review constraints, and what you want the first pilot to prove.