GCF FrameWorks Ltd · UK deep-tech company

The model should never be the security boundary.

AI is moving from answering questions to remembering, using tools, accessing credentials, executing code and taking actions across real systems. GCF is being built as the governed control layer between AI intelligence and real-world authority.

GCF separates intelligence from authority, so persistent AI can become more capable without automatically gaining unrestricted access or control.

See how GCF works Investor brief

StatusWorking runtime

Raise£250k pre-seed

NextExternal validation

FounderBilly Payne

001The road to GCF

From an idea to a company.

// this timeline is honest, not curated. It shows what was true at each point, including the rebuilds, dead ends and changes in direction.

2020
The idea begins

Long-term idea for an AI assistant that persists and stays local.
November 2023
Serious development

Memory, tools, credentials, authority - governance architecture emerges.
2024–2025 P1
Foundation work

Governance, memory, routing, tools, authority separation become core.
August 2026 P1 done
Core baseline

GCF architecture reaches a stable baseline for forward dev.
September 2026 P2 begins
Company incorporated

GCF FrameWorks Ltd formed. Move to formal company, raise, validation.
Sept 2026
Evidence pack ↗

Runtime, governance, model config, internal test evidence.
Now P3 active
Foundation hardening

Stability, regression, closeout - before the next stage.
Next
External validation

Controlled evaluators, adversarial testing, security assessment.
Later
Early Access

Limited cohort after hardening to test reliability and demand.

002The problem

When AI is connected to everything, wrong can become dangerous.

The risk changes when a model is no longer only generating text. A manipulated, compromised or simply incorrect model should not automatically inherit control over the systems around it.

[PROMPT]

Prompt injection

Untrusted instructions can try to steer an agent toward actions its operator never intended.

[MODEL]

Compromise or failure

A model error should not become permission to access sensitive systems, credentials or data.

[TOOLS]

Tool misuse

Code execution, APIs, files and deployment tools turn bad decisions into real system changes.

[AUTH]

Excessive authority

Capability can grow faster than the controls governing what the system is actually allowed to do.

003The response

Separate intelligence from authority.

GCF places a governed control layer between the model and the real world. The model can think. It cannot act on its own.

Governance boundary outside the model itself.
Scoped credentials issued only for approved actions.
Multi-axis memory with permission inheritance.
Resource control for compute, network and external actions.
Approval flows for high-authority operations.

gcf / runtime

$ gcf check

model .................. scoped

memory ................. governed · persistent

tools .................. scoped · audited

credentials ............ scoped · on-demand

authority policy ....... active

// GCF makes persistent AI safe to connect to real systems.

004Architecture

A governed control stack around the model.

The AI can reason. The wider system owns persistence, permissions and authority.

MODEL

Replaceable intelligence

Local-first today. External and custom providers are planned extensions, not a dependency of the core architecture.

GOVERN

Policy & authority

Risk, permission and high-authority checks happen before sensitive actions are allowed to continue.

MEMORY

Governed persistence

Identity, continuity and memory belong to the wider system, not to whichever model happens to be active.

CREDENTIALS

Sensitive access boundary

Credentials are designed to remain isolated from ordinary model context and memory.

TOOLS

Scoped capabilities

Files, APIs, shell access and other tools can be permissioned, limited and audited.

ACTIONS

External effects

The last step is not "the model wanted it". It is whether the governed system authorises it.

// Public website language avoids internal version labels. Detailed engineering stages remain in technical documentation.

005Evidence today

Built far enough to test the idea seriously.

The project has working internal evidence, including a technical evidence pack capturing the runtime, governance block, model configuration and internal test evidence from prior runs.

Open technical evidence ↗ Pitch deck ↗ Live status

006First product on GCF

ISAC proves GCF in practice.

ISAC is the first product built on GCF. It demonstrates the architecture working on a single realistic user: a persistent assistant with controlled authority.

Read about ISAC

The model is replaceable. The governed intelligence system is the durable layer.

Persistent identity across model changes.
Governed memory rather than unmanaged context alone.
Scoped tools controlled through the GCF boundary.
Local-first baseline with external providers planned later.

007Where GCF can go

One control problem, several future environments.

Show ambition without making unverifiable commercial commitments.

Initial market

Business / Enterprise

Technical teams and organisations deploying persistent AI with organisational data, software, tools and internal systems, where permission boundaries, audit and controlled authority matter.

Later product

Consumer AI

Personal assistants with continuity and user-controlled memory, permissions and connected services.

Long-term

Robotics / Private Sector

Longer-term deployments across robotics and other private-sector physical systems, where AI actions can affect the real world and governed authority, human override and independent hardware safety controls become critical.

Future R&D

Efficient models

Explore greater capability per unit of compute, while preserving the same principle: more intelligence does not automatically mean more authority.

008Pre-seed

Fund the move from internal proof to external evidence.

£250k

The round is intended to accelerate engineering, independent security work, compute, external validation and productisation. The aim is not to "finish an assistant". It is to test the architecture seriously against the problem it was built to address.

Investor brief

EngineeringIncrease delivery capacity beyond a single founder.

SecurityAdversarial testing and independent assessment.

ComputeInfrastructure for deeper testing and later model R&D.

ValidationExternal evaluators, workflow evidence and commercial testing.

009The log

Keep the dispatches.

The research-log personality is part of the site's strength. Historical posts can stay historical while the main company pages carry the updated story.

All dispatches →

Security