PortfolioAmanuensis
Views

Amanuensis / Technical deep dive

Boundaries before intelligence

The system is split into narrow stages so collection, inference, and delivery can be inspected independently. Deterministic policy gates decide where sensitive data may go; a stable item ID explains what happened from receipt to final outcome.

Start here for architecture and rationale. Use the example walkthrough to inspect one item sampled and reconstructed from the live system for presentation, including its records and failure paths.

Open the example walkthrough

Inside this view

  1. 01 Architecture and kits
  2. 02 Privacy and traceability
  3. 03 Correction loop
  4. 04 Decisions and limits
01

Architecture and kits

Separation of concerns, local reasoning, transparency

Amanuensis separates source handling, judgment, and delivery into three narrow kits. Records move in one direction; private context and policy enter at explicit boundaries, while a stable item ID connects every decision. This keeps adapters replaceable, model routing auditable, and delivery gates deterministic.

POLICY - private context enters at explicit boundariesINGEST - gatherTRIAGE - judgePUSH - deliverinbound policy gateinbound policy gateselects the allowed model routeoutbound audience gateoutbound audience gateaudience and sensitivity, fail closedingest-kitingest-kitmake unlike sources comparabletriage-kittriage-kitturn a record into a decisionpush-kitpush-kitspend attention deliberatelynormalizenormalizeone record shape for every sourcededupededupecontent hashing drops repeatsidentifyidentifyassigns the stable item IDroute by sensitivityroute by sensitivitysensitive items go local-onlyone model callone model callconstrained decoding, no invalid prioritystructured verdictstructured verdictpriority, audience, summary, action requiredpriority ladderpriority laddermust, should, fyi, ambient, dropdelivery gatesdelivery gatesread persisted values, fail closeddelivery timingdelivery timingdeferred items age upwardrecord storeENTITYrecord storecontent-hashedverdict storeENTITYverdict storeversioned by routedelivery ledgerENTITYdelivery ledgereach delivery and its outcomestable item IDENTITYstable item IDone trace connects every decision
Ingest-kit, triage-kit, and push-kit in sequence, each writing to its own store; policy gates sit before inference and delivery, and a stable item ID joins the stores into one trace. Drill into a stage for its internal steps
Layer detail
View

Double-click a layer to show detail. Use Fit to focus the active detail.

High-level view

Stage 01 · Gather

ingest-kit

Make unlike sources comparable

Adapters turn mail, tasks, feeds, and notes into one record shape, remove repeats, and assign a stable item ID. Collection follows each source's shape - polled, pushed, or subscribed - and every record lands in a content-hashed store.

opaque cursor
Each adapter owns a resume cursor the pipeline stores and never interprets, so a new source is an adapter plus config rather than a schema migration.
content hashing
Repeats are dropped on the way in, before anything downstream pays for them.
run audit
Every run carries an ID with an explicit pending-to-terminal lifecycle, so an interrupted run stays diagnosable rather than silently skipped.
normalizenormalizeone record shape for every sourcededupededupecontent hashing drops repeatsidentifyidentifyassigns the stable item IDrecord storeENTITYrecord storecontent-hashed

Stage 02 · Judge

triage-kit

Turn a record into a decision

Sensitivity is marked at the source before any call is made. One policy-routed model call per item then returns priority, audience, a summary, key entities, and whether action is required, judged against the reader's current plan.

sensitivity-gated routes
Ordinary items may take a cloud-capable route; sensitive items only an approved local one.
constrained decoding
The output schema makes an invalid priority impossible to sample, so bad structure cannot enter the store.
versioned verdicts
A verdict records which model actually served it and is stored per route version; a re-triage writes a new row instead of overwriting history.
route by sensitivityroute by sensitivitysensitive items go local-onlyone model callone model callconstrained decoding, no invalid prioritystructured verdictstructured verdictpriority, audience, summary, action requiredverdict storeENTITYverdict storeversioned by route

Stage 03 · Deliver

push-kit

Spend attention deliberately

The assigned priority is one of five tiers - must, should, fyi, ambient, drop - and the tier picks the route: immediate delivery, the next digest window, or a quiet do-not-disturb hold, while drop is suppressed and only recorded. Shared and public destinations must also clear the outbound gate.

the five tiers
must interrupts immediately; should and fyi fold into the next digest window; ambient is held quiet - do not disturb, but browsable; drop is suppressed and kept only as a record.
delivery timing
A deferred item ages upward each window it is skipped, so a low-priority item cannot starve behind louder ones.
idempotent ledger
Every attempt lands in a ledger keyed by source, item, and channel - a retry updates the same row instead of adding a duplicate - with terminal states that distinguish sent from deliberately not sent.
priority ladderpriority laddermust, should, fyi, ambient, dropdelivery gatesdelivery gatesread persisted values, fail closeddelivery timingdelivery timingdeferred items age upwarddelivery ledgerENTITYdelivery ledgereach delivery and its outcome

Digests leave on their own window schedule rather than on arrival, and an ambient item remains available for reconsideration when later context makes it relevant.

02

Privacy and traceability

Two gates control the route. One trace explains the outcome

Inbound policy gate

Source and message sensitivity select the allowed triage path. Sensitive content can only reach an approved local model; if the endpoint reports back a cloud-looking model on that path, the verdict is discarded as a leak rather than recorded as ok.

Outbound audience gate

Before a message leaves a private, personal channel, audience and sensitivity are checked. Public Discord servers, shared Slack bots, and similar destinations require an explicitly allowed route. The gate reads values persisted with the item rather than live configuration, so a later config edit cannot widen what was allowed when the item was judged.

End-to-end traceability

One item ID links receipt, policy checks, model route, ranking, and the final outcome - delivery, quiet hold, or refusal. Every consequential step remains inspectable.

03

The feedback loop

Human-in-the-loop (HITL) review turns corrections into rules

Triage that cannot be corrected slowly drifts away from its reader. Delivery is not the end of the pipeline: every eligible verdict can be scored in a private review channel, including items that were suppressed. A quality correction returns as data - captured, condensed, reviewed by a person, and applied - rather than as a prompt tweak the model is trusted to honor. Human judgment remains authoritative over the model.

04

Decisions, trade-offs, and limits

Determinism and control

Design decisions

Code replaces prompt constraints

A prompt is a request with limited binding force: a model can misread it, drift from it, or be talked out of it. So none of the core safety rules - route selection, the two gates, the override rules, the fail-closed branches - depend on a model understanding intent; each is an ordinary deterministic branch that runs the same way every time.

Independent testing and traceability

The stable item ID follows a record across every kit and stage, from receipt to verdict to delivery. Any single link can be pulled out of the chain, fed a known input, and replayed on its own, and any delivery can be walked backwards to the judgment that produced it.

What the choices cost

Trade-offs

Privacycapability

Keeping sensitive inference local means running small local models where a frontier cloud model would judge more accurately and write a smoother digest. That cost is accepted: the privacy of the material is worth more than the polish of its summary.

Attentionimmediacy

Digest-first delivery deliberately delays everything that is not urgent; information that could have arrived now arrives at the next window instead. The delay is the price paid for fewer interruptions.

Auditabilityoverhead

Every send clears explicit gates, and every consequential step writes a durable trace row. Gates add latency, traces add storage, and both add operational work - accepted, because a delivery that cannot be explained is the more expensive failure.

What remains outside

Limitations

Advanced capabilities are stripped away on purpose

Conversation, long-term memory, and privileged action are excluded from Amanuensis: each belongs to a different kind of system with its own safety story, and bolting them onto a triage layer would blur the boundary this design depends on.

A sorting router and a breakwater

Amanuensis delivers the right information at the right granularity to the reader or to an external system, and stops there; complex operations happen on the other side of that boundary, done by whoever received the item.

Continue with evidence

Follow one item through every record and failure path.

Back to the conceptOpen the example walkthrough