Skip to content
Lihok TechnologiesOPC— home

Technology

How we build

Our products are being built on Lihok Intelligence — one shared, governed intelligence foundation, applied to different jobs in different fields. The problem it solves is not conversation, but work a business can trust. That means deciding what should happen, keeping it inside the limits the business sets, and stopping for a person when a decision is consequential. It also means being able to show afterwards what was done and why. This page describes what that means, concretely.

The governed operating model

How the governed operating model worksThe same model drawn vertically. A request descends a spine through governed knowledge, which is what the system may state; authority, which is what it may attempt; four governed checks, each able to refuse; and a decision. From the decision the path forks: a branch leaves to a refusal rail on the right, where it ends, and the spine continues down to act and then to evidence, a durable record rather than a claim. Refusal and action are outcomes of the same rank.RequestGoverned knowledgewhat may be statedAuthoritywhat may be attemptedGoverned checksfour, each able to refuseDecisionact or refuseActEvidencea record, not a claimRefusedan ordinary outcome

Any stage may refuse. Refusing is an outcome.

In simple terms

What Lihok Intelligence is, without the architecture.

Lihok Intelligence is the shared intelligence layer we are building across all ten of our products. It is not a chatbot, and it is not something you can buy on its own — it is the part all ten are meant to share.

Each product gives it a different job, different information and different permissions. Frontline is live in production today. Atiman is being built to use it with equipment knowledge, and Tactica would use it on project schedules once that work is done. The five planned products are designed to be able to use it; nothing has been built for them yet.

When something important is about to happen, it does not simply go ahead. It prepares the action and stops for a person to approve it, and it keeps a record of what was actually done.

The layer

How the layer is arranged.

One operating layer, six bands, and a human authority boundary above all of them.

The operating architecture

The Lihok operating architectureA layered operating architecture. Human authority sits above a dashed authority boundary. Below it, lanes run in order: Lihok Intelligence as the platform, then a governance band, then delegated specialist agents, then capabilities, then business systems, then execution. Three vertical connectors drop from Lihok Intelligence through the governance band to three agents; each connector carries a gate glyph where it crosses the band, showing that governance constrains delegated execution. Policy travels down from authority into the governance band on the left. Evidence returns upward from execution to authority along the right edge.Human authorityowner · policy · approvalLihok IntelligenceGOVERNANCESpecialist agentsCapabilitiesBusiness systemsWork performedevidence
  • Lihok Intelligence, the platform
  • Governance constraint
  • Specialist agent
  • Capability
  • Business system
  • Execution
Read the bands as strata and the verticals as delegated work. Governance is a band rather than a step: every path from the platform down to a specialist crosses it, which is why a capability cannot be reached by a route that policy does not cover. Evidence climbs back out through the same layers it was produced in.

The layer

Lihok Intelligence sits above the models.

It is not a model and not a chatbot. A model produces language. Lihok Intelligence decides what work has to happen, hands each part to the right model, agent or tool, runs the work, and stops wherever the rules require a person to decide.

Because the layer sits above the models, the models can be replaced. That is a design requirement rather than a slogan: providers retire models at short notice, and a system that has to be rewritten each time one is retired is not one a business can rely on.

Authority

Consequential actions stop for a human.

Actions are sorted into types. The types that matter — privileged, destructive, external, personal-data, and AI-initiated — do not go ahead without explicit approval from the owner. Each approval is fingerprinted to the exact command and parameters it authorises, so it cannot be reused for anything else, and it can be used once.

Capability grants are a separate mechanism on purpose: something doing the work cannot perform what it was never granted. One rule limits what may be attempted; the other limits what may go ahead.

Knowledge

Knowledge answers. Only an authorised action moves.

Every organisation that uses Frontline has one approved knowledge source — a single canonical record — and only a reviewed, permitted part of it is ever published.

That is what stops a fluent answer from being mistaken for a completed action. The system may state an outcome — an approval, a price, a booking — only after an authorised action tool has actually reported success.

Refusal

Any of four checks can say no.

Refusing is an ordinary outcome, at the same rank as acting — not an error path beside it.

Four stages, any of which can say no

How a request becomes an actionThe same four governed checks drawn vertically. A request descends a spine through identity, authority, policy and capability; every check branches right onto one shared refusal rail so any of them can stop the request. A request that passes all four reaches Action and then Evidence.RequestIdentityAuthorityPolicyCapabilityRefusedActionEvidence
  • Refusal
  • Check
  • Evidence
Four governed checks — identity, authority, policy and capability — each able to stop the request, and all four feeding one shared refusal outcome. Only a request that passes every check reaches action, and evidence follows action. The interesting property is not that the system works, but that it is able to say no.

Capabilities

One layer, and several families of capability inside it.

The layer is not one capability but a set of them, grouped into families: knowledge, reasoning, interaction, context, and web or external intelligence. A family is a category, in the same way a maturity label is a category — it classifies what the layer may be able to do, and it is not a product, a module or something you can buy.

Naming a family is not a claim that everything in it is finished. The members shown beside this are examples of what the family covers, and each one is direction until something separately says otherwise. What makes the architecture useful is that the categories are stable even while the contents are being built.

  • Knowledge

    What the organisation knows, and where it came from.

    • Governed organizational knowledge
    • Retrieval
    • Provenance
    • Source grounding

  • Reasoning

    Working something out, and helping a person decide.

    • Reasoning
    • Analysis
    • Planning intelligence
    • Decision assistance

  • Interaction

    How a person meets the system.

    • Conversation
    • Voice
    • Vision
    • Human-facing interfaces

  • Context

    What the system is allowed to remember about the work.

    • Governed memory
    • Mission context
    • Authorized retained state

  • External intelligence

    What is knowable outside the organisation, retrieved under governance.

    • Web intelligence
    • Current external information
    • Governed retrieval

  • These are the categories a capability belongs to, not a list of finished features. A named example is something the layer is intended to be able to do; it is not a claim that it has been built, or that any product is already using it. A family is not a product, and none of them is one of the ten.

Governed access

A product asks. The layer decides.

A product does not reach a capability directly, and it is not entitled to one because it belongs to the portfolio. It asks, and the request is resolved against the rules in force: the product, the tenant, the person signed in, their role, their permissions, the approved sources, the governance that applies, the capability's own maturity, and what has actually been implemented and made available.

That resolution happens before anything runs, and it can come back negative. A refusal is an ordinary outcome rather than a failure — a product asked for something it is not permitted to reach, and nothing happened. An architecture whose only possible answer is yes is not a governed one; it is a wiring diagram.

Which is why the per-product capability directions on this site are written as direction. They say what a product is designed to draw on. They are not a statement that the capability is implemented for that product, and the two things are separated deliberately, because the difference between them is the whole reason this page exists.

Governed access: One access point inside Lihok Intelligence resolves what a product is asking for, and decides whether it may proceed, before the capability runs.

What happens when a product requests a capabilityThe path a capability request takes, drawn as six steps descending a narrow screen. A product asks for a specific capability; the request meets governed access and is resolved against the rules in force; then the decision, which can be no. A refused request reaches a refusal band and nothing runs. A permitted request reaches only what was authorized and produces a result with its record.ProductStep 1Requested capabilityStep 2Governed accessStep 3Permitted?Step 4Permitted capabilityStep 5ResultStep 6RefusedNothing ran. An ordinary outcome,not a failure.

Requested · resolved · permitted or refused · recorded

What the decision is resolved against

Nine conditions, and all of them apply.

The product
What the product was built to do, and which domains it operates in.
The tenant
Which organisation's context the work belongs to, and what that organisation has approved.
The person
Who is signed in, and what they are accountable for.
Their role
The function they hold, so the same capability is not reached the same way by everyone.
Their permissions
What has actually been granted, which is narrower than what the role could imply.
Approved sources
Which knowledge and material the capability is allowed to work from.
Governance in force
The rules applied to the request, including where a consequential action must stop for a person.
Capability maturity
How far the capability itself has actually been taken.
What is implemented
What has been built and made available, which is what decides the answer — not what has been designed.

Knowledge

Lihok Vault holds what the organisation is allowed to know.

Vault is the shared governed knowledge platform. Approved material is ingested and classified, permissions are applied, and it is indexed so that it can be retrieved with its provenance attached.

It is architecture in progress, and one thing in particular is not being claimed: Frontline's production knowledge is not described as having migrated to Vault. Live Frontline production knowledge is a separate matter with its own evidence, and it stays that way here.

Vault plays two roles, and they are different roles of the same named concept. It is a shared knowledge capability within Lihok's architecture: it governs what may be known and where it came from, which is a different job from holding files, and it is not a file store. It is also a commercial product in development — the tenth product in the portfolio, with its own page and its own provisional mark — and it is not yet publicly available.

Shared governed organizational knowledge

How governed knowledge reaches the layer.

  1. 01Approved knowledge

    Material the organisation has decided may be used.

  2. 02Ingest and classify

    What it is, and what it is allowed to inform.

  3. 03Apply permissions

    Who and what may reach it.

  4. 04Index and retrieve

    Retrieval that keeps its provenance attached.

  5. 05Lihok Intelligence

    The layer works from governed knowledge rather than from whatever a model happens to generate.

  6. 06Authorized product, LEI or LEX

    Reached through governed access, by whatever was permitted.

  • Not generic file storage. Vault governs what may be known and where it came from, rather than holding files.
  • Not a released product. Lihok Vault is commercial product #10, in development, with its own page and provisional mark, and it is not yet publicly available. It is also a shared knowledge capability within Lihok's architecture — and the capability does not mean the product is already available.
  • Not a completed migration. Frontline's production knowledge is not described as already running on Vault, and no migration is claimed.

Evidence

Work ends in a record, not a claim.

Every mission leaves a permanent, append-only record — one that can only be added to: what was planned, what a person approved, what actually ran, and what came back. When work is interrupted halfway, anything that changes something fails closed: it stops for a person to review rather than being quietly retried.

  • Plannedwhat was intended
  • Approvedwhat a human authorised
  • Executedwhat actually ran
  • Resultedwhat came back

The interface

One mission, and everything that happens to it.

An operating interface for work

The Lihok Intelligence interfaceThe Lihok Intelligence operating interface at mobile width. A mission objective sits above a plan of four steps, one of which is an approval gate that stops for a human. Beside it, an orchestration region holds specialist agents above a capabilities region. Across the bottom, an evidence region carries the result, its verification and the audit trail.Lihok IntelligenceMISSIONObjectivePLANUnderstandRouteApprovalExecuteORCHESTRATIONCAPABILITIESEVIDENCEResultVerificationAudit trail
  • Lihok Intelligence
  • Specialist agent
  • Approval required
  • Evidence
Not a conversation. One mission, the work it decomposes into, the point where a human has to authorise it, the agents and capabilities that carry it out, and the record that comes back. The approval row carries the strongest weight because that is the difference being claimed: consequential actions stop there, and an executor cannot perform what it was not granted.

Availability

Lihok Intelligence is not a product you can buy today.

Lihok Intelligence is not offered for general use and is not sold on its own. It is the shared layer our products are intended to be built on. The layer itself is still in development, and it is not one of the ten products.

Every Lihok product is LEI-capable by design, which is a statement about the architecture rather than about today: the layer operates according to the product, the tenant, the person signed in, the permissions they hold, the capabilities available and the governance in force.

What you can use today is Lihok Frontline, which is live in production.

Interfaces

LEI and LEX are how people meet it, not what it is.

Lihok Intelligence is the foundation. LEI and LEX are the human-facing presentation identities through which people work with that foundation and with the governed capabilities of a product — LEI as the primary female presentation and LEX as the primary male one.

They are two ways of meeting one intelligence foundation. They are not two intelligence systems, neither of them is the foundation itself, and neither is a product. Choosing between them changes voice and presentation only: authority, permissions, governance, memory and the state of a mission in flight are unchanged either way.

These are the identities our interfaces present. That is a decision about how the assistant presents itself, not a claim that every system behind it has finished carrying a different name.

Interfaces

Two presentation identities. One governed intelligence.

LEI and LEX are two presentations of the same Lihok Intelligence, and the figure beside this shows what they share: the same governance, the same memory, the same capability routing, the same permissions and the same mission state. What differs is identity, voice and style, and nothing about authority.

They are not routes into the layer for machine-to-machine work. A product reaching a capability does so through governed access rather than through a persona, which matters because a persona is something a person chooses and a capability grant is something an executor either holds or does not.

LEI and LEX are two presentations of one governed intelligenceTwo presentation identities over one governed intelligence, stacked for a narrow screen. Lihok Intelligence as a single core, then LEI, the primary female presentation, then LEX, the primary male presentation, then one bar spanning both: the same governance, memory, capability routing, permissions and mission state.LIHOK INTELLIGENCELEIPrimary female presentationLEXPrimary male presentationSame governance · same memorysame routing · same permissionssame mission stateTwo presentation identities.One governed intelligence.

Two presentation identities · one governed intelligence

One foundation

Products built in sequence, on the same foundation.

Every Lihok product is intended to be built on Lihok Intelligence. What each product supplies is its own subject matter: the context, the data, the workflows, the tools and the limits on what may happen that make the intelligence useful in that field.

That is why the portfolio is built one product at a time rather than all at once. The expensive part is the governed intelligence, the rules about who may do what, and the record-keeping. That part is built once and reused, so each product starts from what the previous one already solved instead of beginning again.

See what is live today

An honest note

Some of this is becoming ordinary.

Asking a person to approve an action, and keeping a record of what ran, are increasingly available as bought-in services, open-source features and free tools. We do not present them as our moat.

What we think remains genuinely hard is making the authority model explicit and correct per capability, keeping execution fail-closed under adversarial input, and producing evidence that an auditor will accept across a heterogeneous set of vendors. That is the layer we are building, and we would rather concede the rest than overstate it.

Brand system

One family, drawn from one grammar.

Ten products have to read as one company's products. This is the grammar that does it — and it is provisional work, not a finished identity.

Product identity system

Provisional

One mark grammar, rearranged ten ways.

Every mark below is built from the same two elements as the master Lihok mark — corner brackets reading as a governed boundary, and a forward chevron inside them — drawn on the same square frame, at the same stroke weight, with the same round joins and no fills. Only the arrangement changes. That is what makes ten products read as one company's products rather than ten separate ones.

  • Lihok Frontline

    Available now

    The master arrangement: brackets closed, chevron travelling outward.

  • Atiman

    In development

    Four corner brackets, the master's own boundary, with the chevron centred.

  • Lihok Tactica

    In progress

    A single vertical spine between the brackets, reading as a schedule or a sequence.

  • Ayoha

    In development

    Two opposed brackets, opening the frame horizontally rather than closing it.

  • Lihok Media

    Planned

    Two concentric chevrons inside one boundary, reading as layers.

  • Lihok Coach

    Planned

    One edge of the bracket opened into an aperture, so the frame reads as a gate.

  • Lihok Academy

    Planned

    The same chevron reversed, reading as intake rather than output.

  • Lihok Traveller

    Planned

    Brackets drawn off-centre against each other, reading as movement.

  • Lihok Preloved Bags Marketplace

    Planned

    An open frame with the chevron reversed into it, reading as intake through a threshold.

  • Lihok Vault

    In progress

    An open frame with the chevron crossing it, reading as passage through a gate.

Provisional, and reversible

Provisional design-system work. These are demonstrations of one shared mark grammar derived from the master Lihok mark, not final product identities, not approved trademark assets and not registered. They may be replaced in full.

No trademark symbol appears beside any of them, none is registered, no per-product colour has been assigned, and name clearance has not been undertaken. Final product marks require a separate approved design process and separate acceptance.

Common questions

Questions about how it works.

The ones that come up once the shape of the system is clear.

What does “governed” actually mean here?

Three things are decided in advance and then enforced: what the AI is allowed to do, what has to stop for a person, and what gets recorded afterwards.

So consequential actions do not proceed on their own. Approvals are fingerprinted to the exact command and its parameters and are single-use, and the work ends in a record that can be inspected rather than a statement that it went well.

Can it take real actions, or only answer questions?

It takes real actions, inside limits that are set explicitly. Knowledge answers; tools act — and a tool runs only where authority for it was granted.

A conversational agent may state governed knowledge freely. It may announce an outcome only once an authorised action tool has returned success.

What are LEI and LEX?

They are the two ways people meet Lihok Intelligence — the assistant identities a person talks to. LEI is the primary female presentation, LEX the primary male one.

They are not two intelligence systems, and neither is the foundation itself. Switching between them changes voice and presentation only — the governance, permissions, memory and mission state are the same either way.

These are the identities our interfaces present — a presentation decision, not a claim that every system behind them has finished changing the name it carries.

Can Lihok work with systems a business already uses?

Where there is a boundary, we state it rather than implying an integration we have not built. Atiman is built for maintenance operations to run alongside the enterprise asset-management systems a business already has — it does not replace them, and its page names that boundary precisely.

For the rest, we would rather say what is finished than let a diagram suggest more.

Who decides what the AI is allowed to do?

The business does. Each product supplies its own domain context, data, workflows, tools and authority boundaries, and the foundation enforces those limits rather than being trusted to respect them.

Anything consequential still stops for owner approval before it happens.

Questions about how it works underneath?

We are happy to go as deep as you want, including where we are not finished.

Request a consultation