The Private Intelligence Network

Executive summary

Illustrative decision, not a customer case study. A strategy lead has one funded investigation to place and a dozen plausible problems competing for it. The Discovery Engine assembles interviews, operating records, public signals, contrary evidence, permissions, and missing-data warnings into a ranked shortlist. The lead selects one problem; the evidence, rationale, approval, action, and eventual result remain connected so the next decision starts from what the organization learned rather than from another blank chat.

That is the private intelligence network in miniature: an organization-owned system that turns evidence into a decision, carries the decision into action, and learns from the observed outcome. Models, applications, and interfaces can change. The governed evidence and decision record remain under organizational control.

%%{init: {"flowchart": {"useMaxWidth": true, "htmlLabels": true, "nodeSpacing": 26, "rankSpacing": 34}, "themeVariables": {"fontSize": "17px"}}}%%
flowchart LR
    DATA["Fragmented evidence<br/>and operating data"]
    FOUNDATION["AI-ready Evidence<br/>&amp; Data Foundation"]
    APPS["Orchestrated applications<br/>new + existing"]
    DECIDE["Governed decision<br/>and authorized action"]
    OUTCOME["Observed outcome<br/>and learnable trace"]

    DATA --> FOUNDATION --> APPS --> DECIDE --> OUTCOME
    OUTCOME -->|"improves the next cycle"| FOUNDATION

Executive business flow

The value center is not model output. It is the decision-to-action boundary, where analysis changes research, marketing, sales, strategy, operations, or the allocation of real resources. The system preserves how each decision was reached and what happened next. This is a functional architecture, not an all-at-once implementation plan: rollout starts with the required foundation and connections, then moves through prioritized applications one at a time.

%%{init: {"flowchart": {"useMaxWidth": true, "htmlLabels": true, "nodeSpacing": 34, "rankSpacing": 42, "curve": "basis", "subGraphTitleMargin": {"top": 10, "bottom": 30}}, "themeVariables": {"fontSize": "18px"}}}%%
flowchart TB
    subgraph S["1. Sources and operating environment"]
        direction LR
        PUB["Public evidence"]
        INTERNAL["Internal knowledge"]
        DATA["Scientific and operational data"]
        HUMAN["Human questions, constraints and judgment"]
    end

    subgraph F["2. Evidence & Data Foundation"]
        direction LR
        INTAKE["Governed intake"]
        MEANING["Catalog, semantics and identity"]
        READY["Reusable evidence, datasets, features and state"]
        TRACE["Decision, action and outcome trace ledger"]
        LEARN["Evaluation and governed learning"]

        INTAKE --> MEANING --> READY
        TRACE --> LEARN --> READY
    end

    APPS["3. Orchestrated application network<br/>Applications share foundation data and hand work to one another"]

    subgraph D["4. Decision-to-action boundary"]
        direction LR
        PACKAGE["Decision package<br/>evidence • rationale • uncertainty • alternatives"]
        REVIEW["Human, policy and guardrail review"]
        ACTION["Authorized action<br/>or deliberate no-action"]
        RESULT["Observed result"]

        PACKAGE --> REVIEW --> ACTION --> RESULT
    end

    PUB --> INTAKE
    INTERNAL --> INTAKE
    DATA --> INTAKE
    HUMAN --> INTAKE

    READY <--> APPS
    APPS --> PACKAGE
    REVIEW -->|"route to another application"| APPS

    PACKAGE -. "decision and rationale trace" .-> TRACE
    REVIEW -. "approval, override and rationale" .-> TRACE
    ACTION -. "execution trace" .-> TRACE
    RESULT -->|"new evidence and data"| INTAKE
    RESULT -->|"outcome and learning signal"| TRACE

    classDef source fill:#e9e2d4,stroke:#9a8e78,color:#202a2a;
    classDef foundation fill:#dce7e2,stroke:#58766d,color:#202a2a;
    classDef application fill:#e0e9e9,stroke:#6c8584,color:#202a2a;
    classDef decision fill:#edf2ef,stroke:#58766d,color:#202a2a;
    classDef feedback fill:#f0eadc,stroke:#9a8e78,color:#202a2a;
    class PUB,INTERNAL,DATA,HUMAN source;
    class INTAKE,MEANING,READY foundation;
    class TRACE,LEARN feedback;
    class APPS application;
    class PACKAGE,REVIEW,ACTION,RESULT decision;

One intelligence core, many surfaces

The network is primarily under-the-hood infrastructure. Interfaces and models may change without discarding the governed intelligence or institutional memory beneath them.

What changes when data becomes evidence

Having data is not the same as having evidence ready for a consequential use. The difference is easiest to see in one deliberately simple example:

The governed version does not make the claim true by formatting it. It makes the source, uncertainty, permission, and intended decision use inspectable. That is what allows another application to reuse the evidence without silently upgrading a fragment into a fact.

What exists today

• Observed: a working local demonstration environment shows evidence-backed discovery, owner-specific decision conversations, governed information sharing, bounded refusals, and preserved decision context.
• Observed local corpus: a working public-record layer contains 444,248 U.S. patent records—237,261 grants and 206,987 published applications—with ranked semantic search, running on one workstation.
• Observed scope: these are working internal demonstrations and sales walkthroughs, not a claimed production deployment inside a customer.
• Next proof: run the first bounded Discovery Engine engagement against a buyer's own decision, evidence, constraints, and baseline outcome.

Phased rollout by design

The architecture is the destination, not a demand to build everything at once. A credible rollout begins with one consequential decision and the smallest foundation and application capable of improving it.

%%{init: {"flowchart": {"useMaxWidth": true, "htmlLabels": true, "nodeSpacing": 28, "rankSpacing": 36, "curve": "basis"}, "themeVariables": {"fontSize": "17px"}}}%%
flowchart LR
    SCOPE["1. Scope the first decision<br/>owner; stakes; observable outcome"]
    DATA["2. Build its data spine<br/>sources; harmonization; permissions; connections"]
    APP["3. Launch the Discovery Engine<br/>ranked problems with evidence of demand"]
    EXTEND["4. Prove, harden and extend<br/>observe the result; then apply the Research Engine to the selected problem"]

    SCOPE --> DATA --> APP --> EXTEND
    EXTEND -. "reuse foundation, connections and traces" .-> DATA

The rule is foundation first, leverage next, expansion after proof. For the current product sequence, the first decision is which problem deserves funded attention. The Discovery Engine produces the ranked shortlist; the Research Engine becomes the second act after a problem is selected. A different buyer may begin with another application, but the same rule applies: one owner, one decision, one observable outcome, and no expansion until the loop works.

Application network and potential outcomes

The collapsed view is the executive argument. It is complete without the detail: the shared foundation supports discovery, learning, and action; the observed result returns as governed evidence. The detailed topology that follows shows common application-to-application handoffs without turning the network into one mandatory pipeline.

%%{init: {"flowchart": {"useMaxWidth": true, "htmlLabels": true, "nodeSpacing": 30, "rankSpacing": 44, "curve": "basis"}, "themeVariables": {"fontSize": "17px"}}}%%
flowchart LR
    FOUNDATION["Shared substrate<br/>A fact can be reused without re-researching it"]
    FIND["Discover &amp; understand<br/>A shortlist of problems someone is already paying to solve"]
    LEARN["Learn &amp; predict<br/>A signal early enough to change the plan"]
    ACT["Decide &amp; operationalize<br/>Tradeoffs settled by the trace, not the loudest voice"]
    TRACE["Outcome &amp; trace<br/>What happened returns to evidence"]

    FOUNDATION --> FIND --> LEARN --> ACT --> TRACE
    TRACE --> FOUNDATION

    classDef foundation fill:#dce7e2,stroke:#58766d,color:#202a2a;
    classDef discover fill:#edf2ef,stroke:#58766d,color:#202a2a;
    classDef analyze fill:#e6eeee,stroke:#6c8584,color:#202a2a;
    classDef decide fill:#f0eadc,stroke:#9a8e78,color:#202a2a;
    classDef trace fill:#e9e2d4,stroke:#9a8e78,color:#202a2a;
    class FOUNDATION foundation;
    class FIND discover;
    class LEARN analyze;
    class ACT decide;
    class TRACE trace;

Detailed application topology

This is the extensible map beneath the collapsed view. It names the current application families while preserving the central design rule: every application can reuse governed context and return a traceable record to the shared foundation.

%%{init: {"flowchart": {"useMaxWidth": true, "htmlLabels": true, "nodeSpacing": 34, "rankSpacing": 48, "curve": "basis"}, "themeVariables": {"fontSize": "18px"}}}%%
flowchart TB
    FOUNDATION["Evidence & Data Foundation"]
    CONTEXT["Shared application context and handoffs"]

    FOUNDATION <--> CONTEXT

    subgraph A["Application layer — extensible and orchestrated"]
        direction TB

        DISCOVERY["Discovery Engine<br/>Find problems with real stakes and demand"]
        RESEARCH["Research Engine<br/>Analyze literature and actual datasets"]
        EXPERIMENT["Experiment & Active-Learning Engine<br/>Choose informative next tests"]
        PROCESS["Bioprocess Intelligence<br/>Golden batch • drift • quality • optimization"]
        BIOMOLECULAR["Biomolecular Discovery<br/>Structure • sequence • variants • candidates"]
        FORECAST["Forecasting & Operational Intelligence<br/>Risk • demand • failure • trajectory"]
        RESOURCE["Resource Allocation Intelligence<br/>People • budget • capacity • portfolio"]
        REGULATORY["Regulatory & Evidence Monitoring<br/>Changes • obligations • evidence gaps"]
        OPTIMIZE["Decision & Optimization Engine<br/>Actions • constraints • tradeoffs"]
        WORKFLOW["Governed Workflow Applications<br/>Briefs • copilots • reviews • collaboration"]

        DISCOVERY -->|"selected problem"| RESEARCH
        RESEARCH <--> |"evidence gaps and results"| EXPERIMENT
        RESEARCH <--> PROCESS
        RESEARCH <--> BIOMOLECULAR
        RESEARCH <--> FORECAST
        RESEARCH <--> REGULATORY
        PROCESS --> OPTIMIZE
        BIOMOLECULAR --> EXPERIMENT
        FORECAST --> OPTIMIZE
        RESOURCE <--> OPTIMIZE
        REGULATORY --> OPTIMIZE
        EXPERIMENT --> OPTIMIZE
        OPTIMIZE --> WORKFLOW
        WORKFLOW -. "new question or unresolved decision" .-> DISCOVERY
    end

    CONTEXT <--> DISCOVERY
    CONTEXT <--> RESEARCH
    CONTEXT <--> EXPERIMENT
    CONTEXT <--> PROCESS
    CONTEXT <--> BIOMOLECULAR
    CONTEXT <--> FORECAST
    CONTEXT <--> RESOURCE
    CONTEXT <--> REGULATORY
    CONTEXT <--> OPTIMIZE
    CONTEXT <--> WORKFLOW

    classDef foundation fill:#dce7e2,stroke:#58766d,color:#202a2a;
    classDef context fill:#e9e2d4,stroke:#9a8e78,color:#202a2a;
    classDef application fill:#e0e9e9,stroke:#6c8584,color:#202a2a;
    class FOUNDATION foundation;
    class CONTEXT context;
    class DISCOVERY,RESEARCH,EXPERIMENT,PROCESS,BIOMOLECULAR,FORECAST,RESOURCE,REGULATORY,OPTIMIZE,WORKFLOW application;

Use the expandable families below as the business translation of the technical map: what each application does and what a useful outcome could look like in the reader's world.

Own the core; choose the boundary

"Air-gapped" is accurate only when there is no live network path. A machine that is merely disconnected for a period is offline, but not necessarily air-gapped.

Why own the core

• Data and question privacy. Source material, prompts, intermediate work, and durable records can remain on hardware the organization controls.
• Durable custody of the means of intelligence. The organization owns its hardware, workflows, evidence store, and lawful copies of licensed model artifacts. Rights remain governed by each artifact's license.
• Policy fit for legitimate sensitive domains. Approved biological, regulatory, pre-IP, and security-adjacent work can operate under the organization's own access, biosafety, legal, and review controls rather than the generalized policies of a public chatbot.
• Connection without dependence. External models and SaaS can remain available as optional capabilities through the gateway while the system of record and institutional memory stay local.
• Reuse instead of reinvention. One evidence foundation, connector layer, permission model, and trace can support many applications without rebuilding the same intake and governance work for every use case.
• Adoption through products, not prompt heroics. Advanced users can invent new patterns. The organization can turn the patterns that survive review into shared tools for colleagues who should not have to become prompt engineers. This is consistent with Atlassian's function-specific superuser framing, but it is an operating design choice rather than a universal adoption ratio.

A local model no longer means a toy

Qwen3.8-27B is a compact, downloadable 27B-class multimodal model. Its significance is not that it uniformly replaces hosted frontier models. It is that a model small enough for owned workstation-class hardware can now enter the same performance conversation on selected practical evaluations.

Selected scores from Qwen's vendor-reported model card:

These are vendor-reported point estimates, not an independent parity claim. Harnesses, prompts, tools, quantization, context, and workflow design can change results. The Qwen card compares against Claude Opus 4.6; Anthropic subsequently released Opus 4.8, so the table is evidence of local-model capability, not a current frontier leaderboard.

Anthropic's Opus 4.6 announcement lists standard API pricing of $5 per million input tokens and $25 per million output tokens. Local inference has no per-token model-vendor charge, but still consumes hardware, integration, support, electricity, and time.

Hardware and ownership starting points

A 27-billion-parameter model requires about 54 GB for weights at 16-bit, 27 GB at 8-bit, or 13.5 GB at 4-bit before runtime, context, and application overhead. Those figures are arithmetic estimates, not proof of usable speed or context on a particular machine.

Illustrative U.S. hardware examples checked on 16 August 2026:

Prices are examples, not quotations or total project budgets. Storage, backup, integration, support, tax, security, and operating costs are additional. A machine that loads a model has not yet proved the workflow.

Design rules

1. Roll out in phases. Scope the first important decision, construct the evidence foundation and connections it requires, deploy the highest-leverage application, observe the outcome, and extend only after the loop works.
2. Start with evidence. Sources and the Evidence & Data Foundation come before applications.
3. Do not confuse available data with AI-ready data. Fragmented inputs must become fit for a bounded use case; organization-wide readiness adds governed reuse across applications, teams, and decisions.
4. Make applications interoperable. Every application can read traceable evidence and write governed outputs back to the foundation.
5. Separate the intelligence core from its surfaces. Govern evidence, permissions, provenance, decisions, and outcomes beneath the interface so the same capability can appear in existing or new tools without becoming trapped in one UI or chat history.
6. Orchestrate without creating a rigid pipeline. Applications can route work and share context without forcing every problem through one sequence.
7. Carry the decision record into action. Evidence, rationale, uncertainty, alternatives, constraints, and approvals travel with the decision.
8. Reconnect action to outcome. Decision traces, actions, and observed results return as learnable records.
9. Govern learning. Outcomes may improve evaluation, routing, and future decision policies, but must not silently rewrite evidence or expand an application's authority.
10. Preserve deployment choice. The owned core can run air-gapped, inside the company firewall, or in hybrid mode through logged connections.

Learning-loop interpretation

The architecture is best described as a closed-loop decision-learning system. It becomes literal reinforcement learning only when an application has a valid reward signal, an explicit policy that may change, controlled exploration, and evaluation gates that prevent harmful or misleading updates. In other cases, the foundation supports organizational learning by preserving which evidence, rationale, decision, approval, action, and outcome belonged to the same chain.

A decision and reasoning trace does not mean a model's private chain-of-thought. It means auditable decision provenance: the sources, transformations, analyses, claims, assumptions, alternatives, uncertainties, rules, tool actions, approvals, overrides, final action, and observed outcome needed to reconstruct and evaluate why a decision was made.

Evidence notes

• Application outcomes are hypotheses to validate against a buyer's baseline; no universal savings or uplift is claimed.
• Model scores are vendor-reported from the linked Qwen model card and should be reproduced on target workflows before procurement or deployment.
• Hardware prices were observed on official U.S. vendor pages on 16 August 2026 and may change.
• Deployment terms describe architecture choices, not automatic compliance. Security, privacy, legal, biosafety, and regulatory controls remain specific to the organization and use case.
• Local corpus counts were read from the working database on 17 August 2026. The corpus is CPC- and date-scoped rather than a claim of complete patent coverage; public-record matches remain signals until sources are fetched and graded for a decision.