Observability platform work
Splunk, Logstash, Kafka ingestion paths, RCA, remediation, and platform health analysis.
Systems Notebook
Make the machine admit what it is doing.
Systems should tell on themselves.
I work around systems that hide too much state, rely on too much tribal knowledge, and fail in ways that make tired people guess. Most of my work sits near observability, automation, platform operations, and small tools that make messy systems easier to inspect.
Signal
What I am working near right now.
A fast map of current focus areas. This is the public signal layer, not a full autobiography.
Salt and infrastructure automation
Repeatable rollout paths, validation, drift control, and Linux operational support.
Agent-safe tool boundaries
Explicit contracts, visible diffs, schema validation, and tools that do not require folklore.
learning-os research
Markdown-first knowledge systems, durable notes, diagrams, and reusable thinking artifacts.
resume-builder web demo
Structured resume data in, inspectable rendered output out. No formatter babysitting.
tea-style doctrine
A scaffold for principles, patterns, rules, and engineering habits that need shape.
Work
Recent platform work.
Netbuilder / JPMC LogA Platform Contractor
Associate Observability Engineer - Plano, TX - Aug 2024 - Present
- Automated search-filter updates across 3,000+ Splunk roles.
- Supported Salt-based Splunk automation across 100+ search heads.
- Worked around Kafka, Logstash, Splunk ingestion paths, stale topic cleanup, and remediation.
- Investigated DR readiness gaps around cluster-manager and deployer workflows.
- Completed a 40-host reboot remediation target and tracked follow-up RCA work.
Operational problems I have worked near
Cluster readiness, farm-break remediation, SELinux context drift, repave failure analysis, stale ingestion state, and release-oriented support.
AI code evaluation
Professional review of generated Python, JavaScript, and SQL for correctness, maintainability, edge cases, and instruction following.
AWS solutions architecture
Enterprise guidance across availability, security, scalability, performance, migration cost estimation, and cloud-native prototype work.
Systems Notebook
A public working surface.
The notebook is where I keep the stuff that feels too alive to leave in a resume: doctrine, field notes, project labs, diagrams, experiments, and whatever I am currently trying to understand.
01
Doctrine
Rules, standards, and engineering habits that make systems easier to reason about.
02Field Notes
Operational observations and fragments worth preserving before they turn into folklore.
03Project Labs
Unfinished repos made useful by showing what is real, fragile, and next.
04Experiments
Small sandboxes and tests that are not ready to pretend they are systems.
Recent Notes
What the notebook opens with.
diagram
experiment
Structured input, rendered output
A small diagram for treating personal documents like source-controlled artifacts.
diagrams
resume-builder
documents
validation
doctrine
living
Do not build tools that require folklore
A tool that requires tribal knowledge is just undocumented risk with an interface.
automation
interfaces
observability
black-box-design
doctrine
living
Do not confuse a demo with a system
A demo proves movement. A system proves endurance.
reliability
testing
operations
evidence
doctrine
living
Keep config as intent, not hidden business logic
Config should expose operational intent, not become a second programming language with worse tooling.
config
logging
standards
maintainability
doctrine
living
Make mutations atomic and visible
If a tool changes something, the result should be clear enough that the operator does not reverse-engineer reality.
automation
mutation
operations
evidence
doctrine
living
Make state visible before humans start guessing
A system that cannot describe its own state makes operators hallucinate one.
observability
splunk
state
operations
Contact