Requests and ownership · Taxonomy authoring, tracking URLs and hygiene
Keeping campaign names, owners and tracking evidence connected
Source-reviewed technical draft. Diagrams and walkthroughs use abstract or invented inputs. Implementation, reported use and measured outcomes remain separate.
My Taxonomy contributions span typed authoring, lookup and import fixes, tracking links, request routing and data-health tooling. These workflows meet at the same operational problem: a name can look valid while its owner or its downstream tracking evidence is missing.
I want the case study to show those connections without treating every related module as solely mine.
Authoring gives the rest of the system an identity
The contribution history includes the TypeScript migration, parameter and lookup repairs, hook and admin-panel decomposition, import persistence and advertiser-directory fixes. The inspected name generator preserves ordered key/value pairs, normalizes whitespace, omits empty values and validates configured level-length limits. That is the builder contract used as context here, not proof that I authored every line of the original generator.
Tracking outputs have another identity boundary.
The inspected QR route can generate an asset-based short link or custom text supplied by an authenticated user. Asset QR output uses a stable asset ID; custom output is generated from the supplied content. QR generation establishes an encoded payload, not that its destination resolves correctly or that tracking was observed. Related proof-to-QR validation belongs in the proofing chapter; the tracking-link history remains mapped here as supporting work.
Route a request through a verified owner
The authored change adds the Taxonomy consumer for shared DRI routing. It resolves the advertiser's canonical client link, considers routing controls and consumes owner, identity, access, freshness and capability evidence. Conflicting canonical client links produce a blocker rather than choosing an arbitrary owner.
My routing work separates a planned recipient from a permitted delivery.
The rollout control distinguishes legacy, shadow, allowlisted and active states. An unavailable control read returns a disabled legacy result. The later activation endpoints in the authored change add a guarded operational path with dry-run default, readiness and confirmation controls. Merged activation code is not proof that the feature was activated for a client.
One subtle defect had a specific fix. The authored change changes request-time identity hashing to use the normalized routing-user source used by projection and activation. A raw-versus-normalized mismatch could reject otherwise fresh evidence. I keep that repair attached to the identity contract rather than presenting it as a new routing system.
Inspect the system diagram
A resolved request can have unresolved delivery
The inspected resolution-notification service stores an immutable payload and destination plan with a fingerprint. Its outbox tracks requester and channel checkpoints separately. A worker claims a five-minute lease and uses a claim token for checkpoint changes. Completed destinations are skipped on later work.
An expired lease is not permission to replay everything.
If a destination was marked delivery-started before the process stopped, the next claim marks uncertainty and requires manual reconciliation. The service rechecks requester evidence and channel destination before sending. An explicit definitely-unsent response can be retried; an ambiguous response or failed completion checkpoint stops automatic replay.
I would explain why this preserves partial success. If the requester was notified but channel delivery failed, recovery should not casually send the requester another copy. This is a recorded-state design around separate provider operations, not exactly-once Slack delivery or a shared provider/database transaction.
Hygiene signals need their own evidence limits
The direct authored the authored change connects Taxonomy Intelligence to this history. In the inspected engine, usage scores normalize thirty-day spend against the highest value in the supplied activity map. A zero score does not prove that a tag is useless.
The ghost detector is narrower than a generic missing-tracking alarm: a recent lookup must appear in a generated name, and that exact name must exist in the warehouse activity set with zero spend.
An absent warehouse campaign is not detected by this branch.
I also distinguish archive candidates from confirmed inactivity. The reaper checks activity-map membership, creation age, seasonal text and remaining options. Its age comparison uses creation time, not a verified last-active timestamp. Default configuration enables dry run and disables Slack, but live configuration and actual execution were not checked here. The cron route counts candidates and computed scores before individual writes; those counts are not confirmed successful mutations.
The separate closed Taxonomy Intelligence recovery proposal in authored changes remains unmerged evidence. It does not establish a live DRI alert rollout.
Invented operator walkthrough
- Create fictional campaign Harbor Summer using an ordered taxonomy template. Review name length and tracking output separately.
- Give its advertiser two conflicting canonical client links. Show a routing blocker and correct the configuration before delivery.
- Reconstruct a resolution notification where requester delivery completed but the channel's final checkpoint failed. Show partial completion and manual reconciliation.
- Supply an invented warehouse row with the exact campaign name and zero spend. Contrast that ghost signal with a campaign absent from the warehouse.
- Show reaper candidates under dry-run configuration. Explain why candidate counts do not prove tags were archived.
This contains invented records and reconstructed branches, with no live notification or taxonomy mutation.
Contribution and results
My authored history supports sustained builder maintenance, a merged request-routing consumer, guarded activation code, an identity-source repair and data-health implementation. It does not establish current routing activation, notification success rates, tracking accuracy or a measured reduction in taxonomy errors.
Discussion notes
Three-minute outline. connect a generated campaign name to its owner and downstream data; show canonical-link blocking; walk through partial notification delivery; finish with hygiene signals and their limits.
Questions to prepare. Which identity must remain stable across authoring and routing? When is replay safe? What does zero spend establish? How should a cleanup candidate become an approved archival decision?
Application summary. I contributed to connected taxonomy workflows covering authoring, request ownership and tracking-data hygiene. I added routing that consumes explicit readiness evidence and can preserve partial notification outcomes. I can also explain why a generated name, a ghost signal and an archive candidate need different operational decisions.
This contribution narrative is supported by privately held source and authorship records. It contains original explanations and abstract diagrams, without employer code, customer records or runtime telemetry. Missing outcome evidence stays explicit.