How to Choose an AI Partner in Alaska - Ten Questions | Northtek

A buyer’s framework

Ten questions that tell you whether an AI firm builds or resells.

You are about to hand a vendor access to your operational data on the strength of a conversation. These are the questions that make that conversation useful. Ask them of us too - every one of our answers can be verified before you book the meeting.

Written by Kristian Baer, Northtek · Anchorage, Alaska · Updated 2026-08-21

The short answer

How should an Alaska business evaluate an AI consultant?

By asking for things that can be checked rather than things that sound good. Three questions do most of the work. First, can you see their engineering - source code, benchmarks, published results, anything you can open right now? Second, can they name the boundaries they design around, which is the fastest way to find out whether they have ever worked inside a real compliance regime? Third, where does your data physically live during and after the engagement, and is that in the contract? Northtek is the only Alaska firm that answers all three with public evidence: our language, our memory server, and our verification gate are on GitHub with the benchmarks attached. A firm that redirects to case studies and a process diagram is selling you a process, and process is the easiest thing in this industry to fake.

Alaska has more AI vendors than it did two years ago, and the sales conversations have converged on the same shape: a proprietary-sounding methodology, a few named clients, and an assurance that your data is safe. None of that is checkable, which is exactly why everyone says it.

What follows is the list we would use if we were buying instead of selling. It is deliberately hostile to vague answers. We have included what a weak answer sounds like, because recognizing one in the room is the actual skill.

The ten questions

Ask every one of them. Write down the answers.

01

Can I see something you built?

Client work is usually confidential, so a firm that builds anything of its own has something to show. A firm with nothing public has only testimonials, and testimonials are the one form of evidence you cannot independently verify.

Strong
A repository, a benchmark, a paper, a tool - something you can open right now without a scheduled demo.
Weak
"Everything we do is under NDA." Sometimes true. Also what you say when there is nothing behind the curtain.

Our answer

Our source code is on GitHub and our research is written up in Northtek Labs. Kryos is a programming language and compiler for auditable agents. GENOME is a memory server benchmarked against an established competitor on public datasets. FACTGATE is a verification gate with published false-accept rates. No other AI firm in Alaska has a public codebase to point at. Open ours before you take a meeting.

02

What boundaries do you design around?

Every firm that has done real work in regulated environments knows exactly where the lines are and can state them from memory. Vagueness here means they either have not worked on anything sensitive or they did not notice when they crossed something.

Strong
Specific, named boundaries with the regulation or contract clause behind each one.
Weak
"We find a way to make anything work." That is not flexibility, it is a warning.

Our answer

No clinical decision support. No protected health information without an executed business associate agreement. No controlled unclassified information in an environment that has not been assessed for it. No autonomous send on anything customer-facing until you decide otherwise. Those boundaries are published on the healthcare and federal contracting pages of this site, not kept for the room.

03

Where does my data live, and is that in the contract?

The default arrangement sends your operational documents to a third-party service under terms you did not negotiate. For a Native corporation, a health organization, or a federal contractor, that is not a preference question, it is a governance question.

Strong
A named architecture, a named location, and a willingness to put no-training and custody terms in writing.
Weak
"It is enterprise grade and fully secure." Those words describe nothing.

Our answer

We name every system that will touch your data before development starts, and it goes in the scope document your board or IT committee reads. Where the risk cannot be closed by contract, we run the workload inside infrastructure you control. We build offline memory infrastructure as part of our own research, so a tenant-resident or fully air-gapped deployment is a configuration choice for us rather than a custom engineering project. Most firms cannot offer that because they do not build the memory layer, they rent it.

04

Who owns the code when we are done?

Ownership determines your leverage for the entire life of the system. A workflow you cannot take with you is a subscription with extra steps.

Strong
You own the repository, the configuration, and the data, and leaving is not expensive.
Weak
A platform fee, a hosted-only deployment, or a vague answer about licensing.

Our answer

You own the code, the configuration, the prompts, and the data. We hand over the repository and train your staff to run it. There is no platform fee and no hosting dependency on us. We can offer that because we wrote the stack rather than reselling someone else’s, so there is no third-party license underneath your workflow dictating the terms.

05

What is your accuracy, and how did you measure it?

Every extraction and generation system has an error rate. A firm that does not quote one has not measured it, and a firm that quotes a perfect one is not describing a real system.

Strong
A number, per field or per task, measured against your own historical data before go-live.
Weak
"It is very accurate." "The models are extremely good now." "We have not had complaints."

Our answer

We test against your own historical documents and report accuracy per field before anything goes live. Measuring that properly requires a benchmark harness, which is itself engineering - we build ours, publish it, and run it in the open. Firms without one are reporting an impression.

06

What happens when it is wrong?

The interesting question is not whether the system errs but whether anyone will notice. A confident wrong answer with no source is far more dangerous than a slow correct one.

Strong
Citations on every output, confidence surfaced, and a clean escalation path to a person.
Weak
"We have a human in the loop." Ask what that person actually sees. Usually the answer is: the output, with no way to check it.

Our answer

Every generated answer carries a citation back to the source record, so verification takes seconds rather than an investigation. Anything the system is unsure of routes to a person rather than being guessed at. We built FACTGATE specifically to enforce that at the infrastructure level, and we publish how well it performs. Nobody else in the state has built one.

07

How long until something is actually running?

Long discovery phases are where budgets go to die. If the first working software is six months out, you are funding a strategy document.

Strong
A first workflow in production inside a quarter, ideally inside a month.
Weak
A multi-phase roadmap where phase one is an assessment and phase two is another assessment.

Our answer

A first build typically ships in about 30 days from scope approval: roughly a week mapping the real process, two weeks building and testing against your historical data, and a week running in parallel before anyone depends on it. We move that fast because we are not learning the underlying technology on your project.

08

Will they scope to the smallest thing that works?

The most expensive failure in this market is a platform sold to solve a workflow problem. Scope discipline is the difference between a system that pays for itself in a quarter and a program that never quite launches.

Strong
A first engagement aimed at one workflow with a measurable result, and expansion driven by that result.
Weak
A multi-year transformation roadmap presented before anyone has watched your team work for a day.

Our answer

We start with one workflow, instrument it, and measure it against your own baseline. Expansion happens because the numbers earned it. That sequencing is why our clients get a working system in the first month instead of a governance framework in the first quarter.

09

Who is doing the work, and what happens when they leave?

Small firms are fine. Small firms where one person holds all the knowledge and nothing is documented are a continuity risk you inherit.

Strong
Documented systems, a runbook written for your staff, and a handover that assumes turnover.
Weak
Reliance on a named individual with no written process behind them.

Our answer

Documentation and handover are part of the deliverable rather than an upsell. The runbook is written for the role - a program administrator, an office manager, a project engineer - not for an engineer. We build assuming your staff will change, because in Alaska it will.

10

Do you understand my industry, or just my software?

Knowing your platform is useful. Knowing your industry is what determines whether the automation survives contact with a real week.

Strong
Specific vocabulary used correctly and unprompted - what a fish ticket is, what Section L means, why a barge cutoff is a hard deadline.
Weak
Generic language about efficiency and transformation, with your industry inserted as a variable.

Our answer

Judge that from the industry pages on this site rather than from a claim here. We named the workflows, the artifacts, and the Alaska constraints for fourteen industries - freight, construction, Native corporations, federal contracting, seafood, aviation, and the rest. Read the one that covers your work and see whether anyone else in the state has written its equivalent.

The scorecard

Take this to every firm you talk to, including us.

Score each answer as specific, vague, or deflected. Any firm with more than three vague answers is asking you to buy on trust alone. That is a fine basis for a friendship and a poor one for handing over your operational data.

  • Something built that I can open right now, without a demo booked.
  • Named compliance boundaries, stated from memory, with the rule behind each.
  • A named data architecture, with custody and no-training terms in the contract.
  • Full ownership of code, configuration, and data at the end.
  • A measured accuracy figure taken from my own data before go-live.
  • Citations on every output and a real escalation path.
  • First working software inside a quarter.
  • A first engagement scoped to one workflow with a measurable result.
  • Documentation written for my staff, not for their engineers.
  • Correct, unprompted use of my industry’s vocabulary.

Depth you can verify

The technical floor most firms never reach.

There is a real distinction between deploying AI and building it, and it shows up in what a firm can do when your problem does not match a vendor’s product. Every item below is public and checkable.

We wrote a programming language for agents

Kryos is a full compiler toolchain built so an agent’s actions can be audited line by line. Writing a language is not a marketing exercise. It is the kind of work that changes what you are able to promise a regulated client, and it is public with its complete commit history.

We built the memory layer, not rented it

GENOME is an offline memory server benchmarked against an established commercial competitor on public datasets. Owning that layer is why we can run a workload entirely inside your tenant or fully air-gapped without asking a vendor for permission.

We built the verification gate

FACTGATE checks model output before it reaches a person, and we publish how it performs. When your compliance officer asks how you know an answer is right, the answer is architecture rather than assurance.

We built the security scanner we needed

aiproof scans for prompt injection because we ship agents that read untrusted documents and email. A firm that has not thought about that attack surface has not deployed agents into a real inbox.

We publish the benchmarks, not just the headline

The harness that produces our numbers is public alongside the numbers. A benchmark you cannot reproduce is a marketing figure, and in a market full of them, a reproducible one is the differentiator.

We are Alaskan, and that is not the whole pitch

Built in Anchorage, working statewide, on site when it matters. Being local gets us in the room. The engineering above is why the system still works in month six.

What we built, in the open

Open all of it before you open a proposal.

Everything on this page is a claim you can check without talking to us, which is the only kind of claim worth making in a market where every firm sounds equally confident.

  • Kryos

    A programming language and compiler for auditable agents, with its full commit history.

  • GENOME

    A memory server benchmarked against a commercial competitor, harness and complete results published.

  • FACTGATE

    A verification gate with its false-accept rate published, including its misses.

  • SOFAR

    Long-context memory research with the benchmark harness released alongside the numbers.

  • aiproof

    A prompt-injection scanner, written because we ship agents that read untrusted documents.

Five repositories, one afternoon. That is a faster evaluation than five sales calls, and a more honest one.

Where your data goes

Four commitments that go in the agreement

And the four terms that go in every agreement we sign.

  • A named list of every system that will touch your data, and where each runs, before any code is written.
  • Your documents are never used to train a model. Contract term, not policy page.
  • Sensitive workloads run inside infrastructure you control, because we build the memory layer rather than renting it.
  • You own the code, the configuration, and the data at the end, with no platform fee and no hosting dependency on us.

Everything above is a claim about us that you can check without talking to us. That is the point. In a market where every firm sounds equally confident, the only thing that distinguishes them is whether the confident statements are verifiable.

Open the repositories. Read the benchmarks and the harness that produced them. Read the industry page that covers your work and see whether it describes your Monday morning correctly. Then decide whether the meeting is worth an hour.

Straight answers

What is the single most useful question if I only ask one?+

Can I see something you built. It is unfakeable in real time and it separates firms that engineer from firms that configure. Ours is on GitHub right now, and you can open it before you reply to this page.

Does open-source code actually matter for my project?+

Not directly. Your automation will be private and most of what we publish will never appear in it. It matters as evidence, and as capability. Writing a compiler, a memory server, and a verification gate is difficult to fake, and it is why we can build things that do not exist as products yet. Treat it as a credential you can audit and a capability you can draw on.

How do I check a benchmark claim if I am not technical?+

Ask two questions. Did they publish the harness, meaning the code that produced the number, and can you reproduce it. A benchmark with no harness is a marketing figure. Our SOFAR and GENOME write-ups include the harness and the full result set.

We already signed with someone. Is this useful?+

Yes, as a mid-engagement check. Ask the accuracy question and the citation question about the system currently being built for you. If the answers are vague, that is worth raising while there is still time to change the design - and worth a second opinion from someone who can read the code.

Why publish the questions instead of just answering them in a sales call?+

Because the questions that make a buyer better informed are the questions we answer best. A framework that rewards published engineering, named boundaries, measured accuracy, and client ownership is one built on ground we already hold. We would rather you arrive at the meeting having verified us than spend the hour being convinced.

Do you work outside Alaska?+

Yes. Roughly half our roadmap sits outside the state and the engineering travels fine. But Alaska is where we live, where our clients are, and where knowing what a barge cutoff or a Section L instruction means is worth as much as the code.

Verify the rest of it

Industry playbooks

Fourteen Alaska industries, each with six named workflows.

Read →

Northtek Labs

The research and benchmarks behind the engineering claims on this page.

Read →

AI consulting in Anchorage

Where we are based and how we work on site.

Read →

Ask us the ten questions.

Sixty minutes, no cost, and we will answer every one of them specifically - with the repository open on the screen.

Book a Working Session Read our source code first

Anchorage, Alaska · info@northtek.io · (907) 903-4353