Explore enterprise products and AI capabilities built for industry.
Let’s talk about your businessProducts, integrations and partnershipsBring AI into the enterprise.
Automated data-warehouse builder
Automated high-quality datasets
AI appliance for business decisions
Opens in a new tabDedicated offline AI bidding appliance
Connect AI to products and operations.
Explore the interfaces and integration paths for our AI capabilities.
Models, foundational frameworks and the engineering behind AI systems.
Explore collaboration across products, technology and delivery.
Frameworks, tools and examples for developers to understand and reuse.
Updates, technical thinking and industry observations from IDENIFE.
Our focus on education, talent and sharing knowledge.
ID Axis · Multi-agent reasoning & autonomous execution
ID Axis is IDENIFE’s self-developed framework for multi-agent reasoning and autonomous execution. It connects models, tasks and tools to turn an understood goal into work that can progress.
See how Axis worksProducts · Goals and acceptance criteria
Framework · Reasoning, orchestration and execution
Model · Understanding, generation and evaluation
How ID Axis works
Turn general agent execution into a specialised approach to data production.
Using DeepSeek Harness as its main reference, alongside engineering practices from leading agent runtimes, ID Axis adapts execution to data types, business semantics and quality requirements. Models reason; the framework gives each call a contract, a recovery path and a recorded outcome.
Goals, execution and acceptance keep agents working towards the same data outcome.
Read schemas, field types, documents and samples. Establish business definitions, processing scope and acceptance criteria.
Assign parsing, mapping, processing and verification. Define dependencies and give each agent the context it needs.
Match plugins to data types, validate arguments and record node state, tool receipts and intermediate artifacts.
Check structure, quality and business definitions. Return failures to the relevant nodes; deliver accepted outputs with evidence.
Plugin generation and self-optimisation turn gaps discovered during a task into reusable capabilities.
Compare needs with existing tools
Implementation & I/O contract
Examples, permissions & failures
Keep a stable version & rollback path
Inspect quality & failure causes
Run feedback and failure cases inform the next generation, validation and optimisation cycle.
Self-optimisation depends on testable improvement. Compare a candidate with the existing version and validate it before an update. A failed candidate retains its findings without replacing the stable version.
Completing a data task depends on what happens before and after each tool call.
Include field types, data granularity, entity relationships and metric definitions in task context. Choose capabilities suited to tables, documents and files.
Keep collaboration and processing grounded in the data, reducing translation between general conversation and specialist operations.
Combine I/O validation, timeouts, bounded retries, checkpoints and receipt reconciliation. Check external writes separately to establish whether they already completed.
Preserve completed work through malformed responses, lost connections and partial failures, avoiding blind repetition.
Link execution feedback, failure cases and quality rules to plugin versions. Evaluate changes on consistent criteria and retain reusable domain capabilities.
Feed problem resolution into the next iteration, so subsequent tasks can reuse what has already been validated.
Open engineering methods inform a specialised design for data work.
01 / Framework primitives
An extensible runtime needs separate ways to express the goal, available knowledge, permitted actions and final results. Clear responsibilities give models, tools and business workflows room to evolve independently.
Translate intent into a goal with a testable completion condition. Tasks carry input references, dependencies and acceptance rules; subtasks inherit the constraints they need.
Goal / Dependencies / Completion criteriaSupply a decision with information that has a source. Distinguish original material, verified facts and untested assumptions, with access scoped to each responsibility.
Sources / Visibility / VersionWrap model calls, data processing or business actions in checkable input and output contracts. Declare permissions and side effects for the execution layer to enforce.
Inputs / Outputs / Execution boundariesGive results an independent, referenceable form. Tables, files, reports and checks retain their provenance for downstream tasks and product delivery.
Content reference / Provenance / ValidationThe architecture below presents the engineering direction of ID Axis. State structures, isolation mechanisms and extension contracts are research designs, subject to formal documentation and actual delivery.
02 / State & data contracts
Conversation records communication; task state records execution facts. A runtime needs to know which inputs are fixed, which node is waiting, which outputs are accepted and what enables the next step.
Only an accepted state update can enable the next dependent step.
Parallel nodes should submit their own result deltas. At a join, field-level merge rules handle updates and surface conflicts. Shared state does not imply unrestricted overwrites.
goalDefine completion before execution. A changed goal creates a new revision.
context_refPass references and necessary information instead of sharing an ever-growing conversation.
node_stateRepresent waiting, failure, cancellation and completion separately so missing results never imply success.
artifact_refLink results to their inputs and producing steps, preserving evidence that can be examined.
03 / Multi-agent execution graph
Organize complex work as nodes with explicit dependencies. Models can propose decomposition and repair; the execution layer checks preconditions, schedules ready nodes and joins branches under defined validation rules.
Branch & join
Parsing source material and organizing rules can progress independently. A join checks that both results are ready and their references are compatible before processing begins.
Define → Prepare in parallel → Join → Process → Validate → Deliver
Independent tasks run in parallel. Dependent tasks wait for required results. Scheduling follows dependencies and available resources.
At a join, check provenance, versions and conflicts. Missing, contradictory or unvalidated results do not silently propagate.
Every retry carries a cause and remaining budget. Unattributable failures stop or move to human handling instead of iterating indefinitely.
04 / Plugins & capability extension
When existing capabilities do not cover a data task, ID Axis can generate a plugin implementation, validate it in isolation and bring it into execution. Run feedback and failure cases inform self-optimisation of tool selection, plugin implementations and processing strategies.
input / outputpermissionseffectscompatibilityverificationStart with a gap in the task. Produce an implementation and interface description, making dependencies, permissions and expected behavior explicit.
A capability candidate that can be reviewedCheck input and output structures, normal and failure cases, resource access and error handling. Associate findings with the exact implementation examined.
Evidence with a defined verification scopeAfter verification, loading policy determines visibility and invocation conditions. Running tasks retain a reference to the version they use.
Participation within explicit execution boundariesLink execution feedback and failures to plugin versions, then propose improvements. Compare candidates on the same tasks and quality rules before enabling a new version, with a rollback path retained.
Retain validated improvements as reusable capabilitiesStructural validation checks whether data matches a contract. Behavioral validation also needs examples, failure cases and runtime constraints. Generated code does not acquire execution permission by itself.
05 / Runtime isolation
Agents share goals while keeping context, resources and permissions distinct. Isolation design helps contain a node’s error, timeout or extension instead of letting it disrupt the entire task.
Permission checks and result receipts
A node receives the information needed for its role, with traceable sources and versions. Tool output enters the workflow as data to be processed.
Keep the proposed plan separate from execution authority. Requested resources must match the operations allowed for the current task.
External writes require receipts and outcome reconciliation. A timeout means the wait ended; it does not prove that an external operation never happened.
Set limits on time, retries and resources. Record failure at the relevant node; dependencies determine the affected scope.
06 / Evidence, reproducibility & evaluation
Execution research needs to examine output quality and explain the process. Connecting inputs, versions, actions and outcomes makes it possible to locate failures, compare changes and give the next iteration a sound basis.
Data references, goal revisions, acceptance rules and context sources.
Node relationships, model and tool configuration, capability versions and environment.
Calls, state transitions, failure causes and external outcome receipts.
Referenceable outputs, quality checks, unfinished work and stop reasons.
Reconstruct execution from recorded events and call results to understand how an output was produced. Replay reads history and should not trigger external writes again.
Fix the inputs, model configuration, tool versions and evaluation criteria that can be fixed, then execute again and compare. Model sampling and external environments can still introduce variation.
Apply task acceptance rules to output structure, content consistency and constraint satisfaction.
Check dependencies, resource scope, stop rules and external side effects against the execution contract.
Compare versions with the same task set and criteria, explaining changes alongside failure categories and environmental differences.
These are evaluation methods and engineering objectives, not published benchmark results, measured improvements or guarantees of determinism.
07 / One foundation, different products
Axis provides shared reasoning orchestration and tool execution. Omnia and Optima define their own domain tasks, data contracts and quality requirements on top, turning the framework into practical production workflows.
Coordinate ingestion, cleaning, standardization and modeling, translating business entities, data layers and field rules into deliverable data assets.
Coordinate parsing, mapping, processing and checks to produce AI-ready corpora, training samples and business metrics from material and data assets.
08 / Open source & collaboration
ID Axis connects developers through open source. We focus on capabilities that can be understood, verified and composed, bringing expertise from different domains into a shared language of execution.
Connect additional data sources, tools and business systems.
Express expert workflows as checkable tasks and plugins.
Clarify behavior through examples and failure analysis.
These public engineering resources provide further reading. They do not imply that ID Axis uses the implementations or dependencies described.
A foundational study of graph computation and coordinated execution.
A reference for describing and validating object data structures.
An overview of standards for entities, activities and provenance.