Custom AI systems

Build the intelligence your operation actually needs.

Custom AI systems is Naevum's build path for leaders whose work no rented tool fits, so that their folders, memory and model use become one stack they own.

  • Custom AI
  • Accountable delivery
  • Private model calls
Discuss your environment
Selected context, declared purpose and distinct evidence. An illustrative context landscape relating sources, responsibilities, capabilities and possible futures.
Loading model
Technical descriptionsInteractive model unavailable. The static illustration and descriptions remain available.
Identity and responsibility anchors
Keep people, roles and delegation sources distinguishable.
Technical data

Inputs

Selected roles, accounts and responsibility sources.

Transformation

Keep people, roles and delegation sources distinguishable.

Retained state and outputs

Selected people, accounts and roles.

Delegation and responsibility sources, not inferred authority.

Constraints

A relationship or inferred role does not create authority.

Selected-source interfaces
Make inclusion, exclusion, access and freshness explicit.
Technical data

Inputs

Actual source inclusion and access; not a UI inspection event.

Independent dated observation.

Transformation

Make inclusion, exclusion, access and freshness explicit.

Retained state and outputs

Explicitly included sources and exclusions.

Dated observation, source and access state.

Constraints

Opening an explanatory panel does not include a source or grant access.

Temporal knowledge and relationships
Retain facts, claims, decisions and corrected interpretations with their lineage.
Technical data

Inputs

Source-bearing observation with time and scope.

Selected relevant role and responsibility.

Separately supplied evidence correcting an earlier inference.

Attributed action/consequence history and retained uncertainty.

Transformation

Retain facts, claims, decisions and corrected interpretations with their lineage.

Retained state and outputs

Evidence, time and unresolved contradiction.

Current inference differs from source observation; correction preserves ancestry.

Constraints

An inference remains distinguishable from its source observation.

Infrastructure and capability map
Relate selected assets and dependencies to observations and responsible operators.
Technical data

Inputs

Selected assets, capabilities and dependencies.

Transformation

Relate selected assets and dependencies to observations and responsible operators.

Retained state and outputs

Asset, dependency and operator relationships.

Known capability, unavailable integration and unknown state.

Constraints

A known capability or dependency is not an execution grant.

Purpose, preference and scenario workbench
Relate context to declared aims while keeping forecasts and inferred habits distinct.
Technical data

Inputs

Known capabilities and operator/dependency relationships; no permission.

Explicit objective, commitment or corrected preference.

Evidence connected to the declared objective and role.

Transformation

Relate context to declared aims while keeping forecasts and inferred habits distinct.

Retained state and outputs

Explicit objectives, commitments and instructions.

Inferred pattern and explicit correction.

Possible futures are forecasts, not observed facts.

Constraints

Possible futures remain forecasts rather than observed facts.

Action and consequence ledger interface
Relate proposed work to existing authority and independently observed results.
Technical data

Inputs

Possible next action grounded in corrected context.

Actual applicable decision, when supplied; context grants none.

Independent record of what actually occurred under the proposal identity.

Later observed consequence, distinct from the decision and action record.

Transformation

Relate proposed work to existing authority and independently observed results.

Retained state and outputs

Bounded proposal and pending decision.

Supplied authority, actual action record and independent consequence when present.

Constraints

The exact proposal, applicable decision, actual action and later consequence retain distinct evidence.

An illustrative context landscape relating sources, responsibilities, capabilities and possible futures.

Additional mechanisms are described in the technical reference.

Start with one decision that keeps coming back.

Illustrative first engagement: a procurement lead needs to explain changed supplier commitments using a bounded set of approved policy and supplier documents.

  1. Bound the sources and responsibility

    The procurement lead selects the documents, the recurring question and the decision that remains theirs. Record access rights, excluded material, freshness and the deployment boundary.

    Starts with
    An approved policy set, supplier revisions and a recurring planning question.
    Produces
    A source/rights map and an agreed evaluation question set.
  2. Follow one changed commitment

    A supplier revises a delivery date. The working slice recovers the earlier answer from the earlier evidence and proposes a current planning update from the revised source.

    Produces
    An explainable answer with source and validity, plus a proposed next step.
    Condition
    The procurement lead retains the procurement decision.
  3. Deliver and examine the slice

    Deliver the bounded application, deployment/recovery instructions and acceptance evidence. Test historical answers, excluded-source refusal, correction propagation and the agreed interrupted-work case.

    Produces
    A useful scoped system and a documented decision about the next increment.
    Condition
    This is an engagement design, not a universal integrated installation claim.

A world model you can inspect.

Connected sources become structured context. Observations keep their origin; inferences remain open to correction. This is the architecture of a dedicated engagement, shaped around the world you choose to connect.

Source history, temporal interpretation and recall. An illustrative method for retaining canonical evidence and answering scoped historical questions.
Loading model
Technical descriptionsInteractive model unavailable. The static illustration and descriptions remain available.
Attributed record store
Preserve source-connected history with two distinct time axes.
Technical data

Inputs

Original or changed policy with source and both time axes.

Transformation

Preserve source-connected history with two distinct time axes.

Retained state and outputs

Source, holder, validity and recorded-at time.

Earlier records and operation ancestry.

Constraints

Valid time and recorded-at time remain distinct.

Claim-operation interpreter
Apply the actual semantics of revision, contest and historical use.
Technical data

Inputs

Claims and typed operations.

Validity time, knowledge time and scope.

Transformation

Apply the actual semantics of revision, contest and historical use.

Retained state and outputs

Supersession, contest, suppression and retraction differ.

Validity question and knowledge cutoff.

Constraints

Supersession, contest, suppression and retraction have different historical meanings.

Bounded retrieval and indexes
Assemble relevant evidence without confusing derived lookup with canonical memory.
Technical data

Inputs

Historically appropriate or contested evidence.

Rebuilt derived structures; canonical history remains.

Transformation

Assemble relevant evidence without confusing derived lookup with canonical memory.

Retained state and outputs

Derived lookup and canonical-source link.

Scope/byte bounds and explicit abstention.

Constraints

A derived lookup does not replace canonical source memory.

Contextual relation assembly
Relate the selected evidence to the right responsibility and objective.
Technical data

Inputs

Bounded source-bearing selection or abstention.

Selected role/objective and explicit corrections.

Transformation

Relate the selected evidence to the right responsibility and objective.

Retained state and outputs

Selected identity, role, infrastructure and purpose.

Corrected inference with its lineage.

Constraints

A corrected inference retains its source and responsibility context.

Maintenance and promotion
Annotate, test and retain useful derived structures without rewriting history.
Technical data

Inputs

Canonical records and typed retention requirements.

Measured harms, utility and remaining uncertainty.

Transformation

Annotate, test and retain useful derived structures without rewriting history.

Retained state and outputs

Duplicates, conflict and typed retention/forgetting.

Proposed generalization remains distinct from promoted instruction.

Constraints

A proposed generalization does not silently become an instruction.

Evaluation and reuse register
Keep actual utility, failures and subsequent-use evidence available.
Technical data

Inputs

Actual retrieval use, not automatic future utility.

Independent useful/failing reuse evidence.

Transformation

Keep actual utility, failures and subsequent-use evidence available.

Retained state and outputs

Measured failure and caution/release basis.

Attributed retrieval use and independent future utility.

Constraints

Claims of future usefulness need independent later-use evidence.

An illustrative method for retaining canonical evidence and answering scoped historical questions.

Additional mechanisms are described in the technical reference.

Your environment connects the sources and capabilities you choose.

Identity and representation

People, organizations, roles, accounts and delegated responsibilities.

Inspect the active identity, who may act for whom and the source of an attribute.

Your digital footprint

Selected documents, repositories, communications, applications, devices and services.

Choose connected sources, exclusions, freshness requirements and access permissions.

Knowledge and time

Claims, decisions, episodes, contradictions and the intervals when they apply.

Follow the evidence, correct a claim and define retention and deletion behavior.

Infrastructure

Assets, services, dependencies, capacity and operating conditions.

See the topology, current observations, unknowns and responsible operators.

Purpose and commitments

Objectives, priorities, obligations, success criteria and resource limits.

Change what the environment is working toward and how success will be judged.

Behavior and preferences

Your explicit preferences and supported patterns in authorized work.

Correct an inference and distinguish it from an instruction you deliberately gave.

Possible futures

Forecasts, horizons, uncertainty and alternative actions.

Examine assumptions and keep a scenario distinguishable from an observation.

Authority and consequences

Permitted actions, consent, effect identities, results and recovery obligations.

Inspect what may happen, what happened and what remains uncertain; stop or revise the work.

Observations keep their sources. Inferences remain open to correction. You can inspect the model and change what it is allowed to do.

Explore memory & knowledge

What the research says

Plans for AI run ahead of working systems

Leaders expect agents in their workforce, few European firms use AI at all, and the rented route is priced per seat.

Intent is high and practice is thin: leaders expect agents while most EU firms still use no AI at all. The gap sits in the system around the model, so a custom engagement builds that system first, around one decision your team already makes.

It starts with the world you already work in.

Your systems contain much of what your organization knows. The difficult part is connecting that knowledge to the work that needs to happen next.

We design a dedicated environment around your sources, people, infrastructure and objectives. A versioned world model connects identity and digital footprint to memory, reasoning and permitted action.

Hyperpersonalization comes from that inspectable context: the responsibilities the system respects, the preferences you can change and the tasks by which you judge its usefulness. Each engagement selects and evaluates the capabilities it needs.

Context that keeps its history.

An answer needs its source and the time when it applies.

Connected sources

Choose systems and records within an agreed access boundary. Monitoring cadence and freshness remain visible.

Correctable understanding

Distinguish observations from inferences. Define correction, retention and deletion across source-connected indexes.

Useful action

Turn a named objective into an admitted workflow with a result, operator controls and a recovery path.

Build on the stack, or commission a custom part?

A chief digital officer decides which work the stack covers and which part Black Box Factory builds. Illustrative, with a synthetic regional distributor.

  1. 1 of 5The chief digital officer names one recurring decision, which orders get expedited dispatch, and shares the folders behind it.Decision: Which recurring decision comes first.
  2. 2 of 5The stack reads the folders in place and indexes each file with its source and date.
  3. 3 of 5Memory gathers past dispatch decisions with who made them and on which orders, so the team can question them.
  4. 4 of 5The scoring rule the distributor needs exists in no product, so Black Box Factory builds it as a first working slice.
  5. 5 of 5A separate reviewer checks the slice against the tasks the chief digital officer named; the review lands in the record.Decision: The chief digital officer accepts the slice or sends it back.
Select any part of the drawingScroll to step · Esc to skipFig. 1
  1. 1 of 4The chief digital officer asks for a weekly view of late shipments and the reasons customers were given.
  2. 2 of 4The sources are already in the knowledge base: order files, carrier messages and the reasons agreed with customers.
  3. 3 of 4The stack proposes a program for the report, and nothing is installed until the chief digital officer reviews it.Decision: Approve, change or reject the proposed program.
  4. 4 of 4No custom part is needed, so Black Box Factory is not engaged, and each run of the approved program lands in the record.
Select any part of the drawingScroll to step · Esc to skipFig. 1
  1. 1 of 4Black Box Factory hands over the reviewed slice with its operating instructions and the evidence from its acceptance tests.
  2. 2 of 4The chief digital officer assigns the dispatch team to operate the system and names who may approve changes.Decision: Who operates the system, and who approves changes.
  3. 3 of 4The dispatch team runs the system, and each consequential action lands in the verifiable record.
  4. 4 of 4A requested change goes back through the same separate review before it reaches the running system.
Select any part of the drawingScroll to step · Esc to skipFig. 1

Systems behind it

What Custom AI systems is built from.

The next decision has more to learn from.

Your business has diagnostic skill, accepted decisions and failed experiments whose meaning depends on its own operating context. A dedicated learning study can examine how that experience should inform the next task.

We can scope a study around one recurring task. An engineering team might bring expert-corrected diagnostic drafts and the observed results of interventions; an R&D team might bring a reproducible method and the variants that failed.

The study chooses what should change: source-connected memory, a procedure, a calibrated estimate or a trainable model. Targeted adaptation is considered when the selected model supports it and the examples are permitted for that use.

We agree a no-update baseline and a source-grounded retrieval comparison, then evaluate new work, retained capabilities, data exposure and total cost. An accepted candidate needs its own version, promotion decision and recovery path. The evaluation determines the next operating decision.

Keep the business evidence intact

Retain expert corrections, outcomes and negative findings with their source, time and permitted use.

Choose the layer that needs to learn

Compare memory and procedure changes with targeted model adaptation on the same task and evidence basis.

Judge the next work independently

Reserve unseen cases and earlier accepted tasks. Evaluate useful behavior, retained knowledge, cost and exposure before promoting a candidate.

Questions about Custom AI systems.

Do we need to replace our existing systems?

The first task is to map the systems and workflows you already use. The architecture determines which integrations are useful and where a new component is justified.

What will we own and operate?

Source, data custody, deployment, intellectual-property terms, support and operating responsibilities are agreed for the engagement. Discovery makes those choices concrete.

Custom AI systems in the stack.

Works with

Memory and attention

Temporal context around actual work.

Works with

Model and action boundaries

Control what context reaches an observer.

Works with

Continuing purpose

Work that can persist between instructions.

Built on

Application experience

Domain workflows and interfaces.

Delivery system

System delivery

Build and hand over the selected architecture.

Start where the advantage matters.

Six ways to turn a difficult operating problem into a system you can use.

Built through Black Box.

A clear chain from the work you need to the system you can operate. Each stage leaves something concrete to inspect.

Explore the development system
  1. Discover and define

    Map the workflow, sources, people, constraints and current baseline. Decide what a useful result would change.

    • System brief
    • Outcome definition
    • Data and rights boundary
    • First architecture
  2. Prove the critical path

    Build one representative slice through the intended integrations or an agreed test environment. Examine failure cases before expanding the scope.

    • Working vertical slice
    • Evaluation results
    • Failure cases
    • Decisions for the full system
  3. Build and integrate

    Implement the selected scope with review, acceptance and operational responsibilities attached to the exact release.

    • Reviewed software
    • Integration contracts
    • Operator controls
    • Acceptance record
  4. Operate and improve

    Agree monitoring, support, recovery and change control. Evaluate improvements against actual tasks and retained baselines.

    • Operating handbook
    • Recovery procedures
    • Support responsibilities
    • Review cadence
Technical reference1 further section

Context that keeps its history.

Connected sources. Choose systems and records within an agreed access boundary. Monitoring cadence and freshness remain visible.

Correctable understanding. Distinguish observations from inferences. Define correction, retention and deletion across source-connected indexes.

Useful action. Turn a named objective into an admitted workflow with a result, operator controls and a recovery path.

System story

From a hard problem to an accountable system

An illustrative custom-development journey from a recurring operational problem to handover.

Follow the story

Which decision does your team make every week that no product on the market fits?

Discuss your first slice