Turning institutional judgment into enforceable software behavior.
Organizations accumulate information, decisions, policies, and research. But the reasoning behind those decisions is often scattered across documents, conversations, systems, and individual employees.
Sentinel explores a different approach: preserve institutional questions, evidence, disagreement, and decisions as governed records—and make the rules controlling them part of the software itself.
The result is an implemented experimental research system with persistent data models, bounded AI reasoning, independent challenge, and human-controlled adjudication.
2026 · Institutional Research Systems & AI Governance · Implemented Experimental System
At a glance
19
database tables
4
Alembic migration revisions
42
Python source modules
1,082
test functions
These figures describe implementation scope, not commercial deployment, independently verified passing tests, or Andrew’s personal code authorship.
Andrew’s contribution
Directing the system, governing the boundaries, and deciding what earned implementation.
I directed Sentinel as an independent AI-assisted product and research initiative.
My role included establishing and governing project scope, reviewing implementation plans, issuing or adopting requirements, coordinating AI coding agents, evaluating evidence, requiring verification, and deciding when work needed correction before the next milestone.
I maintained a deliberate boundary between the institutional judgment system Sentinel was intended to own and generic technical infrastructure it did not need to recreate.
The implementation code was produced by AI agents. AI collaborators also contributed substantive architecture and design proposals. I do not claim individual software-engineering authorship or sole origination of the system’s mechanisms.
The professional contribution is the ability to direct a complex technical implementation while keeping its purpose, evidence standards, and acceptance boundaries coherent.
The institutional problem
When an organization cannot reconstruct why it believes something.
Imagine an institution trying to answer a consequential question.
It may have relevant data in several systems, prior research that reached different conclusions, staff members who understand the workflow, and policies governing what information can be used.
The challenge is not simply retrieving more documents.
It is determining:
• What is the actual question?
• What evidence supports the current answer?
• Which sources can be trusted?
• What assumptions are being introduced?
• Who disagrees, and why?
• What information is missing?
• Who is authorized to resolve the disagreement?
• When should the conclusion be reconsidered?
Sentinel was developed to give those questions a durable operational structure.
What Sentinel actually implements
A governed research system—not another chatbot.
Sentinel is a PostgreSQL-backed Python application organized around persistent research objects and explicit workflows.
A Study defines the investigation. Hypotheses make proposed explanations inspectable. Evidence records what supports or challenges those explanations.
Trust Findings identify concerns about source reliability. Workflow Findings capture problems in how information or decisions move through an organization.
Evidence Gaps record what cannot yet be answered, while Candidate Sources represent possible ways to resolve those gaps.
Receipts preserve evidence of consequential system or workflow behavior, including failures and remediation needs.
The system also models context packages, AI model runs, adversarial-review sessions, synthesis reviews, routing events, adjudications, and baseline assessments.
These are implemented data and service objects, not just names in a conceptual diagram.
The essential difference: Sentinel treats a conclusion as a governed institutional object with evidence, context, lifecycle, and authority—not as the last answer an AI assistant happened to produce.
How a question moves through Sentinel
From institutional uncertainty to a reviewable decision.
INTAKE → ANALYSIS → CHALLENGE → DECISION
01
Frame the question
A Study establishes the scope of the investigation and the question the institution needs answered.
02
Gather and assess evidence
Evidence is associated with the investigation. Trust and workflow findings can expose weaknesses in sources or in the processes that produced them.
03
Identify what is missing
Evidence Gaps make uncertainty explicit. Candidate Sources represent possible recovery paths rather than allowing the system to fill gaps with unsupported assumptions.
04
Assemble bounded context
A ContextPackage defines the evidence and information an AI model is permitted to use for a particular task. The package is locked and hashed so the supplied context can be inspected afterward.
05
Challenge the interpretation
An Inside model develops a reasoned interpretation. An Outside model challenges it through structured steelman and dissent procedures.
06
Require human review
Disagreement is preserved. The system’s adjudication workflow requires governed human review before the decision can be resolved.
07
Preserve the result and its obligations
Findings, reviews, routing records, and re-audit requirements help keep institutional conclusions traceable and subject to reconsideration.
The central mechanism
An AI system should not be allowed to certify its own reasoning.
Sentinel implements a governed adversarial-review process known as GAIP.
It separates three responsibilities.
BOUNDED CONTEXT
INSIDE → OUTSIDE → HUMAN AUTHORITY
RESOLUTION PERMITTED ONLY AFTER HUMAN REVIEW
INSIDE
Develop the strongest supported interpretation.
The Inside role reasons within a defined research context and produces an analysis grounded in the evidence available to it.
OUTSIDE
Challenge the interpretation independently.
The Outside role receives bounded context and must first steelman the interpretation before challenging it.
Its challenge can identify unsupported assumptions, extrapolations, missing evidence, and weaknesses in the proposed conclusion.
The Outside runtime does not have a reachable path to live registry queries, retrieval tools, web access, or agent callbacks.
HUMAN AUTHORITY
Decide what the disagreement justifies.
A human review must exist for the specific adjudication before the system permits resolution.
The AI roles may reason, challenge, and disclose uncertainty. They do not get to bypass the human decision point.
The design principle: disagreement is evidence to preserve, not friction to hide.
Rules the software actually enforces
Governance that cannot be bypassed by persuasive wording.
The most important engineering decision in Sentinel was to move requirements out of policy documents and into enforceable mechanisms.
Tenant boundaries are structural.
Composite database foreign keys prevent records from referencing another tenant’s governed objects. Explicit engagement scope is required for actor operations.
AI context is bounded and inspectable.
Context packages are locked and hashed, preserving evidence of what information a model was given for a particular task.
Review stages cannot be skipped.
The adversarial-review state machine enforces procedural ordering. A model cannot simply jump to a completed adjudication.
Assumptions must be disclosed.
The Outside role must declare introduced assumptions and extrapolations. These disclosures are included in the hashed record.
Human synthesis is required.
A six-question synthesis review governs the transition from analysis to accepted judgment. The adjudication service checks for completed human review.
Accepted beliefs can become stale.
A requires_reaudit mechanism represents the obligation to revisit conclusions when their evidentiary basis may no longer be current.
Evidence import is constrained.
The manual import path is tested against creating an ungoverned persistent import object.
These controls are implemented in schema, service logic, and tests. They are not evidence that the system has passed a production security audit or operated successfully with real clients.
The intelligence loop
The most useful finding may be that the institution is asking the wrong question.
Sentinel’s broader design connects several kinds of institutional intelligence.
A Trust Finding may show that a frequently used source is unreliable.
A Workflow Finding may reveal that a process repeatedly introduces errors or loses context.
A Receipt may document a failure that needs remediation.
An Evidence Gap may show that the institution cannot answer an important question with its current information.
A Candidate Source may identify a possible way to reduce that uncertainty.
An adversarial challenge may expose a missing assumption that changes the research direction.
The purpose of connecting these records is to help future investigations begin with better context and fewer repeated mistakes.
The ambition is institutional learning: a later study should benefit from what earlier studies established, challenged, or failed to resolve.
The underlying objects and several connecting workflows are implemented. Long-term compounding performance and cross-client methodological learning have not been demonstrated.
Built to reveal its own weaknesses
Implementation was followed by audits, corrections, and bounded rehearsals.
Sentinel was developed through a milestone sequence with explicit scope and governance constraints.
The repository contains numbered correction work following implementation reviews, including fixes to governance behavior and research workflows.
Rather than treating a passing design review as sufficient, the process repeatedly returned to schema behavior, service logic, state transitions, and test assertions.
The implementation includes partial end-to-end rehearsal slices covering research and review behavior, along with a real Anthropic provider adapter.
This is meaningful technical evidence, but it has limits.
The rehearsals do not establish operational reliability at institutional scale. The system has not been deployed to a customer, tested against real institutional data, or subjected to external production validation.
Technical evidence
A substantial application, with clear boundaries.
Persistent model
19 ORM tables and four Alembic migrations.
Application structure
42 Python source modules, including 17 service modules, with database, service, LLM, and operator layers.
Test surface
1,082 test functions across the verified implementation. The test suite emphasizes governance properties, constraints, and workflow behavior.
AI runtime
Inside and Outside model roles, bounded context packages, procedural adversarial review, and required epistemic disclosure.
Human governance
Synthesis review, adjudication requirements, routing records, and decision-state constraints.
Operational interface
Operator CLI and implemented service workflows. No production web UI or HTTP API.
Rehearsal coverage
Five partial end-to-end slices, M10A—M10E, including a real model-provider adapter.
Scope discipline
No generic ontology platform, broad data catalog, universal orchestration layer, or unearned enterprise integration framework.
What was deliberately not claimed
An implemented research system is not the same thing as a validated institutional product.
Sentinel has no production deployment, paying customers, real institutional-data evaluation, or demonstrated long-term operational reliability.
It does not yet provide a deployed web interface, HTTP API, production authentication, or CI/CD deployment pipeline.
The two AI roles are separated by runtime and context restrictions, but independent model providers and credential isolation are not enforced. GAIP credential isolation remains deferred.
Cross-client learning and the final real-pilot release gate remain future work.
Those limitations matter because Sentinel’s strongest contribution is not a claim that institutional intelligence has been solved.
It is the implemented demonstration that important governance requirements can be represented as persistent objects, bounded processes, and mechanically enforced decision constraints.
What Sentinel demonstrated
Sentinel made several important institutional-intelligence principles concrete.
Research questions and evidence can be represented as persistent, related objects.
AI collaborators can operate within bounded context rather than unrestricted access to institutional records.
Disagreement can be preserved and reviewed instead of being silently reconciled.
Human authority can be made a required part of the workflow.
And governance requirements can be expressed as database constraints, service rules, and testable properties—not just instructions to an AI model.
Current maturity
Implemented experimental system · Not institutionally deployed
Sentinel demonstrates substantial application and governance infrastructure. Its next meaningful proof would require a bounded real-world pilot, with actual institutional questions, data permissions, operator workflows, and measurable outcomes.
The project also established technical and methodological foundations for subsequent work on independent evaluation.
Explore Market Weather →
Explore Cairn / SIA →