An owner name is not enough to route work

An agency can know who owns a client and still fail to deliver a task to that person. The directory may be stale. The destination identity may belong to a different system. A configuration can say “ready” while the access proof has expired. Those are different failures, and the routing system needs to keep them separate.

My Atlas record includes the DRI Matrix, versioned owner configuration, routing projections, notification metadata and readiness evidence. DRI means directly responsible individual. The matrix connects that operational responsibility to the identities and capabilities required by downstream tools.

Configuration, projection and access are separate records

The matrix stores client ownership and role information. An assignment projection resolves that configuration into the shape consumers such as intake routing need. The projection carries source identity and freshness information rather than behaving as an unversioned copy of names.

The inspected rebuild path reads the matrix, routing users and role registry, computes the configuration hash, builds the projection and commits it with the rebuild's source generation.

That makes a consumer's question precise: does this projection still represent the current source configuration?

Delivery readiness adds another layer. The access-evidence validator checks its schema, generation and expiry, policy/configuration/projection/identity bindings, runtime environment and provider-site binding where relevant. Missing, malformed, expired and mismatched evidence remain distinct states. The platform-readiness report evaluates individual events and consumers rather than using a single green configuration flag.

The final enablement predicate requires assignment readiness, a ready projection, ready access evidence, no routing or consumer blockers, and direct readiness across the evaluated events and consumers. A configured fallback can be useful without satisfying that stricter direct-routing gate.

Inspect the system diagram

Open full-size SVG →Horizontal version →

Full-size vertical SVG · Horizontal SVG. Static source model generated with Carl Illustration Engine; readiness does not establish activation.

Two decisions worth defending

**Keep responsibility separate from provider identity.** A person's display name is useful to an operator. A downstream assignment needs a stable provider identity and evidence that the intended action is available in the intended runtime.

My DRI contributions connect these facts while keeping them inspectable. That is more work than looking up a name and sending a message, but it makes a failure diagnosable before delivery.

**Bind proof to the configuration it verified.** Access evidence is not a permanent badge. It expires and is compared against the configuration, projection, routing identity, policy and environment. A changed owner or runtime can invalidate old evidence even when the provider credential still exists.

The tradeoff is operational friction: someone must refresh or repair proof after meaningful changes.

The alternative of treating historical success as current readiness could route work using the wrong owner or stale capability. This is an analysis of the implemented contract, not an invented account of a design meeting.

Retry before delivery differs from retry after uncertainty

For this story, I trace the supporting delivery-state module through claims, pre-delivery failures, started delivery, delivered/fallback outcomes and uncertain states. Claims use bounded leases and tokens. Where a producer envelope exists, a repeat must match its intent; the original decision time remains anchored to the first claim.

The provider boundary is where the retry policy changes.

The important boundary comes when delivery starts. A started, delivered, fallback-delivered, unresolved, uncertain or unknown record is non-replayable in the claim path. An expired pre-delivery claim can be eligible again, but the caller must still pass the stored-state and intent checks.

That avoids treating every timeout as permission to send again. It also accepts a real cost: uncertainty may need operator reconciliation. The state machine does not establish exactly-once delivery across Firestore and an external provider. This description covers the inspected module, not an assertion that every notification producer uses identical semantics.

A proof must not become newer by being retained

My the authored change addresses a subtle failure boundary: retaining access evidence during taxonomy activation must preserve its original generation and expiry. Otherwise, existing proof could acquire a fresh lifetime without a fresh verification.

The contribution is merged, but it is newer than the local source snapshot used for the main description. Its PR record supports the bounded fix; it does not establish a current production activation or close the broader routing requirements.

At census time, the authored change, which refreshes routing evidence after supported owner saves, remained open. Its description explicitly leaves original requirements and production acceptance open. It belongs in the contribution history as ongoing work, not in the implemented-results section.

Synthetic walkthrough

I use invented identifiers and events here. The walkthrough describes source contracts rather than a recorded production incident.

1. Client client-example has an owner projection tied to configuration config-A and access proof proof-A.
2. An owner edit produces config-B. The old proof's configuration binding no longer matches, so readiness reports a blocker.
3. A projection rebuild aligns the assignment data. Access readiness still needs valid proof for the new binding; rebuilding data alone is insufficient.
4. With matching proof, a delivery producer claims its work item. A second caller sees active ownership and does not duplicate the claim.
5. The first caller marks delivery started, then loses confirmation from the provider. The record remains uncertain or otherwise non-replayable until its producer resolves the outcome.
6. The operator checks the provider and reconciles the record. The case study does not invent an automatic resend or guarantee that a message arrived.

What I can claim

I can claim authored contributions to a versioned ownership and routing system, inspectable readiness decisions, and explicit recovery boundaries. The history does not support saying that every agency task is autonomously assigned, that every notification reaches its owner, or that routing saved a measured amount of time.

Several supporting PRs are expressly passive or shadow work.

The readiness and delivery-intent additions in authored changes do not themselves activate Slack sends or new Teamwork mutations. A readiness preview is a different contribution from a live transport.

This is relevant to operational AI engineering because a model's recommendation eventually needs an owner, a permitted action and a traceable delivery outcome. The DRI work supplies those system boundaries. It should be presented through the actual configuration and recovery contract, rather than a broad claim that an agent “runs the agency.”