A grounded product architecture combining operational intelligence, bounded AI execution, observability integration and evidence-driven release. It defines what is viable with technology available today—and what still requires specialist validation before production.
Halibut does not replace every enterprise platform. It coordinates authority, execution, evidence and release across the systems organizations already use.
A control and evidence layer that receives a task, evaluates identity and policy, issues narrowly scoped authority, supervises execution and records resulting decisions and outcomes.
Primary outcome: AI-assisted work becomes bounded, inspectable, interruptible and attributable rather than operating as an unrestricted tool call.
A visual and conversational building interface that translates an approved intent into a versioned project, executes generation and tests in isolated runners, previews the result and requires policy checks before deployment.
Primary outcome: users gain accessible creation while Halibut adds controlled execution, evidence, change review and deployment governance.
The framework separates what is technically viable, what requires an integration spike and what must not be presented as proven before independent validation.
| Statement | Assessment | Production interpretation |
|---|---|---|
| Short-lived signed capability tokens can constrain agent actions. | Technically viable | Requires explicit scopes, audience, expiry, request binding and deny-by-default verification. Token format alone does not provide authorization correctness. |
| PASETO v4.public can use Ed25519 and managed KMS signing. | Integration spike | The signing input must be constructed exactly to specification. Interoperability and official test vectors must be validated. |
| Cloudflare Workers can serve as unrestricted build/test pods. | Do not claim | Use isolated containers or jobs for general code generation, build and test. Workers may handle edge APIs, lightweight checks and orchestration. |
| Opik is a security information and event management system. | Do not claim | Opik is for LLM and agent observability, evaluation and tracing. Security decisions should also flow to a security log platform or SIEM. |
| Halibut is SOC 2 compliant after controls are implemented. | Do not claim | Controls may support readiness. Only an independent qualified CPA firm can issue a SOC 2 report. |
| Fixed latency, cost, throughput or audit outcomes are guaranteed. | Remove | These depend on workload, region, vendors, scope and operating maturity. They must be measured in a prototype and pilot. |
The architecture keeps human authority explicit, AI recommendations bounded and every material action attributable.
Halibut maintains task state, policy state, approvals and execution results explicitly—not hidden inside a conversation.
Task, project, environment, approvals, policy version and execution result remain explicit and reviewable.
The first production version should rely on deterministic rules and measured signals. AI may summarize or recommend; it must not silently override authorization.
Production deployment, secret access, data export and policy modification require stronger authentication or explicit approval.
The builder is a focused product mode for validating how governance can remain visible throughout AI-assisted creation.
Halibut can integrate with established observability and creation platforms while owning the authority-and-evidence layer between them.
Halibut can send AI traces to Opik rather than duplicating its established observability role.
Halibut differentiates through task-level AI execution governance and portable evidence—not through unsupported security comparisons.
Before Halibut existed as software, its operating logic was practiced manually during AI-assisted product and infrastructure work.
Observed result: deliberate task routing, staged approvals and visible handoffs reduced avoidable rework and improved implementation discipline. This is product-discovery evidence—not proof of production security, autonomous reliability, regulatory compliance or endorsement by any model provider.
| Manual behavior | Halibut product equivalent | Required validation |
|---|---|---|
| Isha selected the appropriate model. | Routing policy based on task type, sensitivity, cost and capability. | AI systems expert validates routing and fallback criteria. |
| Isha narrowed the task before code generation. | Structured task manifest defining allowed actions, files, limits and acceptance criteria. | Security architect validates scope semantics and deny-by-default behavior. |
| Isha watched for drift and redirected work. | Execution traces, checkpoints, policy events and human intervention controls. | AI expert validates which signals are reliable enough for supervision. |
| Work moved through deliberate phases. | State machine for plan, approve, execute, test, review and release. | Platform engineer validates durability, retries, idempotency and recovery. |
| Outputs were tested before acceptance. | Isolated runner, automated checks, artifact versioning and release gate. | AppSec and SRE validate isolation, dependency controls and resilience. |
AI review can support analysis, but it is not a certification, security sign-off or substitute for qualified human accountability.
| Validator | Required decision | Evidence expected |
|---|---|---|
| Principal Security Architect | Threat model, trust boundaries, key custody, revocation, runner isolation and fail-closed behavior. | Signed architecture review, misuse cases, acceptance criteria and unresolved-risk register. |
| Senior Platform / SRE Engineer | Topology, capacity, queues, databases, disaster recovery, observability and runbooks. | Infrastructure prototype, load tests, recovery exercise and measured cost model. |
| Application Security Engineer | Path traversal, dependency attacks, prompt-to-tool escalation, token replay and cross-tenant isolation. | Independent review, penetration tests and remediation verification. |
| Specialized AI Systems Expert | Agent architecture, model/tool contracts, evaluation sets, containment and approval placement. | Evaluation protocol, failure taxonomy, model-agnostic interfaces and measured reliability. |
| GRC / Privacy Counsel | System boundary, data classification, vendor obligations, regional requirements and controls. | Control matrix, data-flow inventory, retention schedule and policy set. |
| Frontier model review | Critique manifests, policies, failure cases and developer documentation. | Recorded findings reviewed and accepted by a responsible human expert. |
These are planning ranges—not delivery guarantees. Work can overlap where risk allows, but security architecture and data handling should not be deferred until after external use.
Confirm use cases, boundaries, data classes, trust assumptions, token alternatives and validation team.
EXIT · ARCHITECTURE DECISIONOne task flow from request → policy → authority → isolated execution → evidence → preview.
EXIT · MEASURED POCOne stack, limited integrations, human approvals, operational dashboards and incident exercises.
EXIT · PILOT REVIEWIndependent AppSec, tenant isolation, DR, SLOs, privacy controls, support model and evidence readiness.
EXIT · GO / NO-GOThis console is an interface concept—not a functioning security implementation. It demonstrates how creation, authority, checks and release evidence can be made visible in one workflow.
Track requests, approvals and delivery status.
The necessary components exist today, but the product becomes credible only through a narrow use case, measured evidence and controlled external validation.
The technical claims in this framework should be checked against current primary sources during implementation and specialist review.
ViTech Intelligence welcomes constructive feedback from enterprise operators, security and platform specialists, potential design partners, strategic collaborators and aligned angel investors interested in developing a grounded, accountable and regionally adaptable Halibut OS.