Plan a pilot

Test Muninark on a real engineering task.

Choose a task your team knows well. Agree which sources to use and how to judge the answers before the pilot starts.

A proposed evaluation path
01

Choose one meaningful problem

Select a recurring task and the people who judge its outcome. Record how the work is done today.

Deliverable

An agreed question set and a baseline.

02

Define the boundary

Choose the source history, identities, model services and infrastructure. Confirm what stays outside the pilot.

Deliverable

A scoped integration and data-flow plan.

03

Connect and evaluate

Validate ingestion and access. Evaluate answers on representative questions, including difficult cases and missing evidence.

Deliverable

Reviewed answers, gaps, operating effort and measured costs.

04

Decide what comes next

Compare the results with the agreed baseline. Identify remaining integration work and requirements for ongoing use.

Deliverable

An evidence-based decision about expansion.

Agree the measures first

Does it help your team complete the task?

Compare results with the original question set and baseline. Include difficult cases, plus questions that were held back from tuning.

Quality

Source support, significant omissions, incorrect claims, appropriate refusals and correct historical scope.

Task outcome

Time and quality of completing the work, including the reviewer effort needed to use the result responsibly.

Operating cost

Initial import, ongoing updates, model usage, infrastructure and the time spent by operators and experts. The operator console reports token use and estimated cost per model, including the calls made while answering questions.

Saved time is capacity. It becomes a financial saving only where the organization can realize it. Pilot results should keep those measures separate.

Before the conversation

Planning the pilot.

A product owner, an engineer who knows the source systems and a security contact are a useful starting group.

How long does a pilot take?

The schedule depends on source access, corpus size, history quality and security review. We establish a timeline after scoping, rather than promise a fixed period before seeing the work.

Do we need complete documentation?

No. Existing code history, tickets and documents can be useful even when incomplete. Missing rationale must remain an explicit gap, and the evaluation should establish which questions the available record can support.

How much expert time is needed?

Your experts help select meaningful questions and assess the answers. We include their effort in the pilot plan and in the cost of operating the system.

What determines the price?

The proposed engagement separates platform licensing, integration, support, infrastructure and model usage. Scope and operating requirements determine the quote. There is no public price schedule yet.

Does Muninark automatically change our code?

The core platform serves knowledge and analysis. Optional agent processes can help coordinate work in a host environment; permissions, human reviews and any write actions must be explicitly configured.

What would you like to test first?

Send a short description of the task and the systems that hold the relevant records.

Discuss your use case