AEGISRestrictions follow derivation
Queries, summaries, model inputs, events, receipts and exported evidence need provenance-aware disclosure. Combining protected sources or using them in a decision does not erase their restrictions.
Architecture vision · CTO / SVP briefing
Inside the
governed foundation.
The application defines its purpose.
The kernel enforces the terms under which it may act.
AEGIS is a governed application platform, not an AI wrapper or a database proxy. Its architectural unit is an authorized operation over institution-owned state, with explicit consequences, evidence and recovery.
01 / The system boundary
One authority plane.
Replaceable infrastructure.
AEGIS owns and operates the authoritative application data plane. Consumer applications bring their domain models, workflows and experience—not a second authoritative database or privileged access to the kernel’s stores.
APPLICATIONS
Domain meaning & product experience
Models · relationships · proposed policies · operation intent · user interfaces
Versioned application packages ↓ Named commands, queries & subscriptions ↕
AEGIS KERNEL
The governing authority
Identity & policyPackage admissionData & transactionsInformation protectionAudit & recoveryEffects & exchange
Private, confined provider interfaces ↕
INFRASTRUCTURE ADAPTERS
Persistence, bytes, execution & delivery
Relational / graph stores · object storage · durable workflows · model providers · transports
Local and remote application profiles share the same governing semantics. Network placement changes latency, failure and deployment behavior; it does not transfer authority to the caller or make remote work atomic.
The load-bearing rule
Authorization reaches the data boundary. A forgotten application-side filter must not become a broader read. Every admitted path—including files, retained results and background work—owes an enforceable scope.
02 / How applications define themselves
Propose meaning.
Invoke admitted operations.
An application submits a deterministic, versioned definition of its models, relationships, constraints, policies and named operations. The kernel reviews that package against a supported dialect and the installer’s authority, then owns installation and evolution.
- Propose.Bind package identity, version, intended resources and required capabilities. Domain vocabulary belongs to the application; no sector’s “teacher” or “patient” becomes a kernel primitive.
- Admit.Validate semantics, authority, dependencies, confinement and compatibility. Review exact artifacts; a successful parser is not permission to install.
- Install.AEGIS performs governed schema and policy transitions. Applications do not execute raw migrations with administrator credentials.
- Invoke.Typed clients call installed commands and queries with bounded inputs. They cannot submit arbitrary SQL, graph queries or general-purpose transaction callbacks.
A local extension point must be a confined transaction participant, not a way to smuggle unrestricted application code into the kernel. Remote clients invoke the same named intent through a separately admitted transport profile.
A platform contract, not a storage dialect
Application meaning and compatibility should survive provider changes. Selecting a database, schema language or RPC framework does not by itself define the application contract.
03 / Authority, state and truth
A credential opens a conversation.
It does not decide the outcome.
The kernel resolves a canonical identity and trusted context, then checks the operation, tenant, workspace, subject, resource and relevant versions against current authority. Caller-supplied identifiers are requests to resolve—not self-attested permissions.
Authenticate
Who is asking?Authorize & bind
Which exact operation?Governed commit
What became true?Deliver & reconcile
What happened outside?
Who is asking?Authorize & bind
Which exact operation?Governed commit
What became true?Deliver & reconcile
What happened outside?
One governing transaction
Application changes, their decision evidence and the admission of downstream work must agree at the commit boundary. Approval of an old version cannot authorize a changed one. Relevant policy changes must participate in the currentness mechanism, not race an earlier “allowed” check.
External consequences are a separate boundary
Committing an outbound work item is not the same as completing a model call, transfer or notification. Durable dispatch rechecks the authority required by its contract and records the actual outcome. Idempotency and receipts identify the operation; they do not manufacture exactly-once delivery.
Ambiguity stays explicit
A connection failure during commit can leave the outcome unknown. The caller needs bounded reconciliation against durable truth, not an automatic “failed, therefore safe to repeat.” Receipt lookup itself remains a governed disclosure, including after retirement.
04 / Information protection
Permissions govern action.
Handling rules govern information.
Admitted protection profiles express sensitivity, categories or compartments, and handling restrictions. They are additional constraints on ordinary authorization—not a fixed military ranking and not permissions the application can award itself.
Release has separate authority
Relabeling and less-restricted release require independently governed authority. The administrator constrained by a stricter institutional policy cannot simply disable that policy.
Whole-resource first. Field-level is an explicit destination.
The architecture must preserve a credible path to field-level classification and authorized partial results: stable field identity, schema/content versions, mixed-label composition, derivation and retained-history decoding. “Add a label column later” is not that argument.
Hidden-field existence, errors, metadata and indirect dependencies also matter. Unknown required profiles must not become unrestricted access. Organization-specific obligations and deployment accreditation require their own validated controls; a generic label mechanism cannot stand in for them.
05 / AI, durable work and real-time delivery
An agent is a participant.
Never a new source of authority.
Governed execution separates permission to prepare a proposal, permission to run a model, permission to approve a result and permission to publish or act. Each is scoped to its purpose, sources and destination.
- Durable orchestration
- Outer workflow execution coordinates retries, waiting and recovery. Hatchet is the orchestration direction; its tasks remain subordinate to kernel authority and durable outcomes.
- Agent and model execution
- Agent graphs and typed model operations fit behind confined adapters. Model choice is replaceable; prompts, provider responses and tool requests do not become trusted commands.
- Human decisions
- A review targets the exact saved proposal and source versions. Human approval and its authorized application change belong in one governing outcome, not two loosely synchronized systems.
- Events and subscriptions
- Durable event identity, replay and current disclosure are the contract. A live connection is a delivery mechanism, not perpetual permission. Visibility changes may require refresh or refusal, rather than replaying now-forbidden history.
Notifications, WebSockets, machine subscriptions and other delivery channels extend this model; none is a shortcut around it. Sensitive operational information and analytics remain separated by an explicit disclosure boundary.
06 / Files and governed information exchange
A file store holds bytes.
AEGIS governs their use.
Documents, attachments and evidence need canonical identity and version, integrity binding, protection metadata, authorized access and a managed lifecycle. Storage credentials stay behind the kernel; an object key or storage URL is not a public permission.
The byte lifecycle is not a database transaction
Upload, integrity verification, resource admission and availability must survive partial failures. A construction must account for staged or orphaned bytes, retry, retention, erasure and recovery. A separate object store does not silently join the governing database commit.
The exchange contract: meaning before wire format
These are design obligations, not frozen request fields or endpoint names:
| Bind explicitly | Required meaning |
|---|---|
| Source & projection | Exact resource/content versions and permitted fields or files, with protection and provenance. |
| Recipient & purpose | Authenticated destination, admitted trust relationship, permitted use and separate release authority. |
| Validity & budget | Expiry, revocation and a defined unit of counted access, including concurrency and retries. |
| Handling obligations | Supported policy profiles, restrictive composition and explicit rejection of unsupported requirements. |
| Evidence & recovery | Which facts an acknowledgement proves, partial/unknown outcomes and bounded reconciliation. |
AEGIS → AEGIS
Independent installations establish recipient trust and compatible handling profiles. Source permission to release is not destination permission to disclose. Receiving governance must not silently drop source restrictions.
Federated exchange is not clustering, a global transaction, or proof that every recipient obeyed every obligation.
AEGIS → conventional systems
A documented, versioned boundary should support familiar client tooling. HTTPS with tightly scoped minted credentials is a candidate; a confined SFTP adapter may suit some partners.
Both must enforce the admitted grant. A command-line HTTP client is only a client; token possession alone is not the complete trust model.
A “view limit” needs a real definition.
Does it count an attempt, an admitted redemption, or completed delivery? Parallel requests, byte ranges, retries, caching and interrupted transfers affect the answer. Expiry during delivery and uncertain outcomes also need explicit rules.
Once plaintext has left controlled delivery, AEGIS cannot recall delivered bytes or meter independent offline reading. Stronger downstream duties require an explicit recipient trust, contractual and evidence model.
Storage candidate: SeaweedFS offers object/file interfaces worth evaluating behind the byte-provider boundary. That does not select it, endorse a deployment configuration or make its native sharing semantics an AEGIS exchange contract. See the primary references.
07 / Operating model and extensibility
Start with a coherent kernel.
Keep the future open.
Evidence chooses the storage and execution mechanisms. The acceptance bar is a reachable operation working across its real boundary, with allowed controls alongside denial, concurrency and recovery falsifiers—not a collection of adapters that compile.
08 / Design notes and primary references
Stand on known foundations.
Be precise about the contract.
This briefing describes the intended platform. It is not an implementation inventory, a frozen wire schema, an official national standard or an accreditation claim. Its purpose is to make the governing architecture and institutional opportunity legible.
- Attribute-based access control
Actor, object, operation and environment attributes inform policy decisions. A useful foundation—not a complete information-flow or compliance proof.
- OAuth resource indicators · RFC 8707
Resource targeting is a candidate building block for scoped delivery credentials. It does not implement application authorization or access budgets.
- Sender-constrained tokens · RFC 9449
DPoP binds use of a token to proof of possession of a key. Candidate input to a future profile, not a selected authentication scheme.
- Rights-policy representation · ODRL 2.2
A model for expressing permissions, prohibitions and duties. Exchanging such a policy does not prove the recipient enforced it.
- Object/file infrastructure · SeaweedFS
A storage candidate exposing object and file interfaces. Provider admission, operational proof and the exchange contract remain separate work.
The institutional proposition
Back to the executive briefing
Adopt a common reference foundation and require projects to build on it or demonstrate conformity. Keep procurement, conformance governance and official designation explicit—none follows merely from publishing this architecture.