OPERATING SYSTEMS
Systems that turn scattered information into clear, human-controlled execution.
I design operating systems for complex, fast-moving work. They connect evidence, decisions, people and actions so that teams can understand what is true, what changed and what should move next.
The applications vary across GTM, product research, hiring, relationships and launch operations. The underlying pattern remains consistent:
OBSERVE
Gather relevant evidence from the places where work is actually happening.
CLASSIFY
Distinguish signals, decisions, dependencies, risks, waiting states and open questions.
STRUCTURE
Translate fragmented information into a visible and usable operating state.
DECIDE
Keep strategic judgment, sensitive interpretation and consequential authority with humans.
EXECUTE
Turn the approved state into a precise next movement.
PRESERVE
Retain provenance, decisions and learning so the organisation does not have to reconstruct its context repeatedly.
The work shown here includes systems I operated, systems I tested and systems I designed to implementation-ready stage.
ATTUNED
Launch-stage operating infrastructure for an early-stage nervous-system regulation platform.
Founding Operations Associate
Berlin, August to September 2026
During a short and highly compressed launch-stage engagement, I built and documented operational systems across launch coordination, external relationships, audience management, product feedback and volunteer intake.
LAUNCH OPERATIONS CONTROL SYSTEM
The launch state was distributed across multiple tools and conversations, with no individual source containing the complete operational truth. I designed a three-layer control system to reconcile that evidence while preserving human decision authority.
EVENT HQ
A Notion-based operational record connecting workstreams, tasks, owners, decisions, risks, dependencies, partner state, audience work and reusable launch learning.
AI OPERATIONS ARCHITECTURE
A source-aware reasoning layer configured to distinguish confirmed facts, working concepts, recommendations and unresolved conflicts. It could retrieve, classify and prepare updates, but was instructed not to make commitments or consequential decisions without explicit approval.
LIVE DELTA RECONCILIATION
A recurring maintenance protocol that translated new messages, meetings and operational developments into proposed Event HQ updates.
The movement was controlled through five stages:
READ AND RECONCILE
Review the current record and compare it with new evidence.
PREVIEW
Show the existing state, proposed change, source and unresolved ambiguity.
APPROVE
Wait for explicit human authorisation before changing the operational record.
WRITE
Update the correct record while preserving schema, provenance and history.
VERIFY
Reopen every changed record and report what succeeded, failed or remained uncertain.
The system was operated through consecutive reconciliations during launch preparation and established a validated operating model.
The reusable value was the architecture for source authority, state classification, conflict preservation, approval-gated action and verified execution.
GUEST, OUTREACH AND PARTNER OPERATIONS
Three connected systems supported the movement from identifying the right people and organisations to managing communication, commitments and delivery.
GUEST-LIST OPERATOR
I designed a reconciliation system connecting the complete Luma guest export with a cumulative Notion review database.
The system:
• validated the incoming data structure • identified new, existing and duplicate registrations • preserved previous classifications and research • separated observed Luma status from proposed recommendations • classified new guests by audience segment, fit and confidence • calculated the composition of the currently approved audience • prepared an analytical workbook, append-ready CSV and status-change report
Research effort was proportional to uncertainty. Clear identities required no additional research, while strategically important or ambiguous profiles received focused review.
The system supported human decisions without approving, declining or waitlisting guests automatically.
OUTREACH MODEL LIBRARY
The launch required several forms of external movement, including financial sponsorship, in-kind partnerships, guest distribution, press outreach, cultural collaborations and food operations. I created a controlled outreach system that selected the appropriate route before generating communication.
Each movement combined:
• current approved company and event information • recipient and relationship context • one researched reason for relevance • a route-specific value proposition • a clear and proportionate ask • authority and feasibility checks • a defined follow-up or closure movement
The library reused stable communication structures without treating historical messages as permanent sources of truth. Facts, positioning, proposed benefits and operational constraints were refreshed for each recipient.
When a relationship developed, the system moved it out of communication and into operational control. When an opportunity closed, it preserved the relationship and recorded a clear future or closure state.
PARTNER COMMITMENTS CONTROL REGISTER
A positive response does not complete a partnership. It creates a set of promises, dependencies and delivery responsibilities.
I built a formula-driven control workbook with four connected views:
CONTROL VIEW
Portfolio-level relationship state, risks, open actions and classification safeguards.
PARTNER COMMITMENTS
The contribution, format, logistics, explicit asks, proposed benefits, owner and evidence associated with each relationship.
ACTION CHECKLIST
One executable record for every promise or operational safeguard, including timing, dependency, status and proof of completion.
FOOD AND ACTIVATIONS
Commercial vendors and programme collaborators tracked separately from sponsors to prevent inaccurate public language or inappropriate benefits.
The register distinguished alignment, confirmation and completion as separate states. Direct partner communication remained the primary evidence, while internal status fields acted only as navigation signals.
This turned external interest into a traceable operating contract: what was agreed, what remained conditional, what needed to happen, who owned the movement and what would prove completion.
PRODUCT RESEARCH AND PEOPLE OPERATIONS
MUTED CO-REGULATION FEEDBACK SYSTEM
Early users had signed up to test Attuned’s muted co-regulation feature, but limited engagement made silence difficult to interpret. A lack of activity could represent access problems, unclear value, discomfort, failed matching, poor timing or no meaningful benefit.
I designed a branched form diagnostic around the user’s actual journey stage:
• did not install or access the experience • accessed the product but did not request a session • requested a session but was not connected • completed at least one session • uncertain where they stopped
Each branch investigated a different type of friction rather than asking every respondent the same generic questions.
For completed sessions, the system compared self-reported activation before and after the experience, comfort with silent video presence, perceived effect, possible future use and intention to return.
For incomplete journeys, it investigated access, comprehension, trust, privacy, timing, emotional readiness and matching barriers
The form welcomed criticism, uncertainty, discomfort and reports of no benefit. Responses could remain anonymous, while people who wanted a follow-up conversation could voluntarily provide contact details.
The workflow transformed limited engagement into structured product evidence and supported launch-stage decisions.
VOLUNTEER ANCHOR INTAKE SYSTEM
Volunteer applications were distributed across inboxes and informal conversations, while founder time was being consumed before candidates had passed consistent documentary or behavioural review.
I designed a controlled intake funnel from application to Ready for onboarding.
ONE INTAKE
All future candidates enter through one structured application form. Raw submissions remain immutable.
ONE VISIBLE PIPELINE
The current candidate state, latest human decision, next action, operating context and unresolved evidence remain visible in one record.
ONE ASSESSMENT HISTORY
Small-group and individual assessments create separate evidence records rather than overwriting the candidate’s previous state.
The funnel progressively narrows the candidate pool:
1. Structured application and CV
2. AI-assisted documentary review
3. Human approval for a small-group assessment
4. Observation of presence, listening and role boundaries
5. Human approval for an individual screening
6. Safety and unresolved-concern assessment
7. Human approval for onboarding
The design allowed AI to organise evidence, identify missing information, prepare recommendations and execute an approved consequence. It could not select a candidate or advance them without an exact human authorisation.
Every approved movement required the same controlled sequence:
EVIDENCE ENTERS • AI DRAFTS THE RECORD • HUMAN REVIEWS AND DECIDES • THE RECORD IS RECONCILED • THE APPROVED MESSAGE OR STATE CHANGE IS EXECUTED • THE RESULT IS VERIFIED
The implementation specification included canonical data fields, candidate states, assessment records, approval phrases, exception handling, privacy dependencies, verification rules and three possible technical architectures.
BLORE
AI-assisted GTM classification and personalised outreach for an early-stage developer platform.
Founder’s Associate
Freelance, February to August 2026
Blore was building a guidance and architectural-safety layer for people using AI to move quickly from experimentation towards stable, production-ready systems.
The immediate GTM objective was to identify and engage a small number of highly relevant early users, feedback sources and ecosystem partners without relying on generic mass outreach.
SCAN AND ACT GTM SYSTEMS
I designed a two-stage workflow that separated strategic qualification from message generation.
SCAN
The first layer analysed LinkedIn profile information and converted observable evidence into a structured prospect record.
It classified each person according to:
• builder maturity • current or emerging operational pain • production exposure • technical depth • ecosystem and distribution value • strategic priority • appropriate communication tone • relevant future movement
The classification model distinguished:
EARLY BUILDERS
People experimenting with AI-assisted development whose operational problems were beginning to emerge.
ACTIVE BUILDERS
People already encountering deployment, reliability, maintainability, security or scaling problems.
SPECIAL NODES
Community leaders, educators, investors, advisors and other people able to connect Blore with relevant builders.
NON-FIT PROFILES
People whose relevance depended on assumptions rather than observable evidence.
TECHNICALLY ADVANCED PROFILES
Builders whose infrastructure maturity placed them beyond Blore’s current product layer, unless they retained meaningful ecosystem value.
Every signal was connected to a visible source such as the profile headline, current role, experience or published activity. The system was instructed not to convert generic AI interest, founder identity or weak hypothetical relevance into a positive classification.
SCAN produced a structured JSON record containing the classification, evidence, pain hypotheses, priority, tone, message angle and future CTA.
ACT
The second layer used the structured SCAN output to generate a highly specific first message.
It prioritised the strongest available evidence, mirrored the recipient’s language and translated relevant operational problems into a concise conversation opener.
A specificity check tested whether the message could be sent to somebody else without meaningful changes. If it could, the message had to be rewritten.
LOCAL CRM
The classification and outreach output were stored together in a local CRM, creating a cumulative record of:
• prospect identity and current context • ICP classification • observable signals and evidence • operational pain hypotheses • strategic priority • recommended tone and message angle • generated outreach
The final message remained subject to human review.
The complete movement was:
PROFILE EVIDENCE • SCAN AND CLASSIFY • CREATE STRUCTURED STATE • GENERATE PERSONALISED OUTREACH • PRESERVE THE RUN IN THE CRM • HUMAN REVIEW AND SEND
The system reduced the cognitive work required for repeated prospect research while maintaining specificity, evidence discipline and human control over external communication.
OPERATING PRINCIPLES
Different organisational problems require different systems. The principles behind them remain consistent.
SOURCE BEFORE CONCLUSION
Every consequential state should remain connected to the evidence that supports it.
STATE BEFORE ACTION
Before generating more work, establish what is true, what changed, what is blocked and what is already complete.
STRUCTURE BEFORE AUTOMATION
Define the workflow, authority, data contract and exception logic before selecting the technical implementation.
AI PROPOSES, HUMANS DECIDE
AI can retrieve, classify, connect, draft and execute approved movements. Strategic judgment and consequential authority remain human.
WAITING IS A VALID STATE
A system should make dependencies visible without manufacturing activity or unnecessary follow-ups.
PRESERVE HISTORY
Corrections and new evidence should update the current state without destroying previous decisions, context or learning.
VERIFY THE CONSEQUENCE
A write, message or state change is not complete until the resulting system has been checked.
BUILD FOR REUSE
The lasting value is not only the immediate output. It is the operating logic that can be transferred, adapted and improved across future contexts.
Across GTM, product research, hiring and launch operations, my work follows the same underlying movement:
TURN FRAGMENTED INFORMATION INTO VISIBLE STATE
TURN VISIBLE STATE INTO PRECISE ACTION
PRESERVE THE LEARNING SO THE SYSTEM BECOMES STRONGER OVER TIME