
Interactive Sound Design: Feedback, Timing, and Narrative

Software Maintenance: Testing, Observability, Safe Change

The Real Problem Behind AI Search Visibility
AI search visibility has become a convenient label for a difficult question: how does a publication earn discovery when an answer interface can satisfy part of a reader’s need before that reader visits a website? The concern is legitimate. The proposed shortcuts are often less convincing. A special file, a larger schema graph, or a collection of artificial question-and-answer passages cannot substitute for content that search systems can access, evaluate, and use responsibly.
I would start with a distinction that is frequently missing from discussions of generative engine optimization. In an AI search visibility assessment, being technically accessible, being eligible to appear, being selected as supporting material, being cited in a visible answer, and receiving a qualified visit are five different outcomes. They happen at different points, are controlled by different actors, and cannot all be measured with the same instrument. Treating them as one metric makes a weak growth strategy appear more precise than it is.
This distinction matters to anyone assessing AI search visibility, from independent publishers to established companies. A website can have clean metadata and still fail to answer a useful professional question. An exceptionally useful page can be blocked from crawling. A page can be indexed and never cited. A cited page may generate no click, while a comparatively small number of relevant visits may lead to worthwhile professional relationships. I do not consider any one of those observations a complete measure of success.
My position is that AI search visibility should be approached as an evidence problem before it becomes an optimization project. We need to know what a platform says it supports, what we can directly inspect, what the published content genuinely contributes, and which outcome remains outside our control. That approach is slower than buying a universal GEO checklist. It is also more defensible.
A Five-Gate Framework for AI Search Visibility
I use a conceptual model I call the Five-Gate Search Visibility Framework. It is an editorial and measurement aid for AI search visibility, not an official search-engine model, a measured ranking formula, or a claim about the internal architecture of every AI provider. The value of this distinction is practical: when an outcome is weak, we can investigate the relevant gate instead of prescribing a sitewide technical change without evidence.
| Gate | Question | Observable evidence | Important limitation |
|---|---|---|---|
| Discovery | Can the relevant crawler find and access this URL? | Internal links, crawl rules, server responses, verified logs where available | A successful fetch is not an indexing promise |
| Eligibility | Does the page meet a platform’s applicable search and preview conditions? | Index status, canonical selection, snippet controls, published platform documentation | Eligibility does not require selection |
| Selection | Is the page used as supporting material for a particular answer? | Platform-specific reporting when offered; carefully controlled observations | Selection logic and coverage are not fully observable |
| Citation | Is the page visibly referenced as a source? | Supported citation reports or documented observations | A citation is not necessarily a click or endorsement |
| Qualified outcome | Did this exposure contribute to a meaningful reader action? | Consent-respecting analytics, relevant engagement, inquiries or conversions | Attribution across answer interfaces is incomplete |
The framework intentionally resists reducing AI search visibility to a single score. Such a score would require coverage, denominator, sampling, and causal assumptions that the available tools rarely justify. A page-level citation report and an ordinary search performance chart can both be useful, but neither one proves that a particular editorial change caused the outcome. I would rather maintain five imperfect but honest observations than combine them into one impressive-looking number.

Platform Rules Are Not Interchangeable
For Google Search, the official AI features and your website guidance explains that existing SEO practices continue to apply to AI Overviews and AI Mode. It says there is no separate AI-specific technical requirement or special schema.org markup needed to appear in those features. A page generally needs to be indexed and eligible to appear in Google Search with a snippet to be eligible as a supporting link. Even then, Google does not guarantee crawling, indexing, or display.
That statement about AI search visibility should not be expanded into a claim about every generative search service. OpenAI documents different crawler controls for ChatGPT search and model training. Microsoft describes AI citation reporting in Bing Webmaster Tools. Platform policies, access mechanisms, product surfaces, and reporting coverage are not identical. AI search visibility is therefore a cross-platform editorial question, but its operational answers must remain platform-specific.
Start With Crawlability and Indexability, Not a GEO Plugin
The most basic AI search visibility barrier is also one of the easiest to overlook: a document can be excellent and unavailable to the system we hope will discover it. Before discussing answer formatting, I would examine the live URL, the response it serves, the paths leading to it, and the access policy that applies to a relevant crawler. The difference between crawlability and indexability is important. A server allowing access does not mean a search engine will select the page for its index.
Crawlability Is a Real Technical Constraint
When investigating AI search visibility, inspect the actual page rather than a screenshot from an editor. Does it return an appropriate successful response? Is the essential information present in readable HTML? Can ordinary internal links lead to it? Are relevant bots permitted by robots.txt and by any access controls applied at the edge or origin? Google specifically names crawling access, internal discoverability, text availability, and page experience among the foundational practices relevant to its AI features.
A subtle failure occurs when a protective layer treats a legitimate crawler as hostile, or when a dynamically rendered section is meaningful to human users but difficult for a crawler to access reliably. The solution is not to weaken all security controls indiscriminately. It is to identify the affected client, validate the documented identity and access requirements, then make a narrowly scoped correction if appropriate. The page should remain useful without relying on hidden text created only for bots.
Indexability and Canonicalization Are Separate Checks
AI search visibility also depends on understanding indexability, which requires an additional investigation. An accidental noindex directive, a competing canonical, an unintended duplicate, or a site configuration error can interfere with the preferred URL’s search presence. Google’s canonicalization guidance describes redirects and canonical annotations as signals, not absolute commands. A sitemap can help discovery and indicate preferred URLs, but placing a page in one does not establish that Google indexed it.
If an article exists under a category-based permalink, I would make the visible page, internal links, canonical declaration, structured data identifiers, and sitemap agree on the intended address. I would then inspect what the search system has actually selected. Correcting a canonical disagreement is a meaningful technical repair. Repeatedly modifying a valid URL because a scorecard claims a shorter slug is inherently more AI-friendly is not.
Preview Controls Can Affect Eligibility
Google’s robots meta specifications describe nosnippet, max-snippet, and data-nosnippet controls, including implications for its AI features. A publisher may have legitimate reasons to limit previews, but the same control can reduce what Google may show or use as direct input for an AI-generated search response. That is a governance trade-off, not a generic SEO defect.
For AI search visibility, my recommendation is to define a deliberate content-access policy before changing these directives. A site concerned with licensing and reuse may reasonably prioritize restrictions over exposure. Another publication may want full search discoverability. The correct configuration follows that business and rights decision; it should not be sold as a secret setting that guarantees AI citations.
Search Intent and Original Evidence Matter More Than Answer-Shaped Filler
Technical accessibility makes a page possible to evaluate for AI search visibility. It does not create a reason to select it. For a professional audience, I would design content around decisions that readers genuinely need to make: what assumptions matter, what evidence exists, how alternatives compare, what could fail, and what would change the recommendation. Search intent is not merely a phrase to repeat. It is the unresolved work the reader brings to a page.
The Difference Between Information and Contribution
Consider two articles about structured data. One lists familiar schema properties and repeats that markup helps search engines understand pages. The other distinguishes visible content from machine-readable description, identifies when duplicate schema nodes cause confusion, and shows an audit method for keeping canonical URLs, author identities, dates, and images consistent. Both can be readable. Only the second offers a clear professional decision process beyond a definition.
I would evaluate content quality by whether a knowledgeable reader gains an explanation, a testable method, a justified comparison, or an important limitation that ordinary summaries leave out. Google’s people-first content guidance emphasizes useful original work, accurate information, clear authorship, and the purpose of publication. It does not establish a fixed writing length, a mandatory density percentage, or a formula for being cited by an answer engine.
Original evidence matters to AI search visibility, and it has more than one form. A repeatable technical experiment is one. An accurately documented methodology, a traceable comparison of published standards, and a transparent decision framework can also be useful. But each must be labeled correctly. I cannot call a conceptual diagram a laboratory result, or claim a framework is validated because it looks credible. Content provenance begins with the distinction between what was observed, what a primary source states, and what the author infers.
Make Important Answers Easy to Locate in the Actual Page
Good headings reduce ambiguity for people first, whether the reader arrives directly or through an AI-assisted search result. Use a section title that communicates the specific question, and place the actual answer in visible prose before introducing secondary caveats or supporting details. Tables are helpful when dimensions genuinely need comparison. Descriptive links help readers verify sources. Neither an artificially short paragraph nor a rigid FAQ on every page is a proven requirement for AI search visibility.
For example, a section about whether a crawler can reach a page should say how to check the access path, not begin with three paragraphs of generic marketing. A section about citation measurement should distinguish visible references from referral sessions. When content is structured this way, people can inspect the reasoning and systems that parse textual content have a clearer object to work with. That is an information-design benefit, not evidence of an automatic ranking lift.
Internal Links Should Express Real Knowledge Relationships
Internal linking is valuable when it helps a reader move from an overview to a deeper related decision. An article about AI search visibility might connect to a discussion of owned media strategy when examining long-term independence from discovery platforms, or to digital brand credibility when explaining why recognition is not the same as trust. Those pages contribute different arguments; copying them into this article would weaken all three.
I prefer that relationship to fabricated topic clusters in which dozens of near-duplicate pages point at one another. A coherent publication architecture is a map of distinct reader needs, not a mechanical internal-link quota. Links should lead to real, published material and use anchor text that honestly describes the destination.
The GEO Myths I Would Reject
In debates about AI search visibility, the term generative engine optimization can be useful shorthand for work on discoverability in AI-assisted answers. It becomes misleading when it suggests that a universal technical standard, hidden ranking formula, or guaranteed citation method exists. I would separate hypotheses worth testing from claims that the available primary documentation does not support.
Myth 1: An llms.txt File Is Required for AI Overviews
Google explicitly says publishers do not need new AI text files or specialized machine-readable markup for AI Overviews and AI Mode. A project may independently choose to publish an llms.txt resource for a particular integration, but that is different from claiming that Google requires the file or rewards it as a special AI search ranking signal. The relevant platform must document the behavior before I would treat the file as a dependency.
Myth 2: More Structured Data Automatically Creates More Citations
Structured data can support technical clarity in AI search visibility by communicating supported facts about a page. It is not a citation purchase. Google’s structured data policies require accuracy and alignment with what users can see. Creating an elaborate graph that describes non-existent experiments, fabricated author credentials, imaginary awards, or invisible content makes the markup less trustworthy. A well-formed graph is a semantic description, not proof that a search system will cite the page.
Myth 3: Keyword Density Has a Universal AI Search Target
No official source consulted for this article establishes a percentage of focus phrase repetition for AI search visibility that guarantees inclusion in AI-generated answers. Keyword repetition may be tracked by an editorial tool, but the tool’s preferred score should not override the readability and completeness of the answer. I would use a primary phrase to maintain topical clarity and then evaluate whether the page meaningfully addresses the reader’s related questions.
Myth 4: Every Heading Must Be a Question
Question headings are appropriate when the reader is asking a question. They are less useful when a comparison, process, or technical explanation needs a different structure. Rewriting an entire professional analysis into dozens of shallow questions can make evidence harder to follow. The right information architecture follows the reasoning task rather than a presumed answer-engine preference.
Myth 5: Declaring Expertise Replaces Showing Evidence
An author biography and consistent identity can support accountability in work on AI search visibility. They cannot validate unsupported claims. Content provenance is stronger when sources, methods, dates, and the boundaries of an experiment are visible. I would rather publish a clearly limited technical finding than call an untested idea a proven framework. That is not a rejection of professional judgment; it is a way to make judgment inspectable.
Myth 6: A Citation Is the Same as Traffic or Business Value
In AI search visibility reporting, a source citation means that a system visibly referenced a page in a supported answer context. It does not imply a user opened the page, read the article, trusted the author, or took a valuable action. Microsoft explicitly distinguishes citation activity from clicks and rankings in its AI Performance documentation. A responsible dashboard should make the same distinction even when a growing citation chart looks promising.
Myth 7: One Crawler Setting Controls All AI Products
For AI search visibility, the terms search, model training, and user-initiated retrieval refer to different operations. A crawler setting may affect one and not another. Google’s Google-Extended token is not a Google Search ranking control. OpenAI differentiates OAI-SearchBot and GPTBot. Publishers need a provider-specific access policy rather than a universal allow-or-block instruction copied from a GEO checklist.
What Structured Data Can Actually Do
Structured data deserves care in AI search visibility work because it makes some kinds of page meaning explicit. For a long-form article, a coherent identity graph can describe a WebPage, its BlogPosting, the author, the publication, a genuine image, and breadcrumb navigation. It should reflect the visible content and the real canonical URL. Google provides Article structured data guidance and an introduction to markup that distinguish machine-readable representation from guaranteed search treatment.
I would audit the final rendered page, not merely the JSON source pasted into an editor. Multiple systems can generate overlapping WebPage, Article, author, and breadcrumb objects. When they use inconsistent IDs, dates, or URLs, the result may be syntactically valid but semantically confusing. The useful question is not how many schema types we can add. It is whether the description identifies the actual page without contradiction.
A practical article schema review checks whether the page has a single intended canonical, the headline describes the visible title, the actual publication date is used, author and publisher references are stable, and image URLs refer to images that are genuinely published and accessible. If a diagram is only planned, it should not be described as a published image. If an FAQ appears in the article, that does not automatically justify a separate FAQ rich-result strategy. Search eligibility is governed by a platform’s current feature requirements, not by the existence of a schema property alone.
Crawler Access, AI Training, and Publisher Control
AI search visibility also raises a governance question: being discoverable is not identical to consenting to every possible downstream use. Publishers can have different positions on search inclusion, training, redistribution, and licensing. The technical controls available for those purposes should be evaluated separately, using the documentation of the provider involved.
OpenAI Search and Training Controls
OpenAI’s crawler documentation distinguishes OAI-SearchBot, which supports website inclusion in ChatGPT search features, from GPTBot, which is associated with crawling that may be used for model training. It also documents ChatGPT-User for certain user-triggered requests, which should not be treated as the same operation as automated search crawling. Access rules can express different preferences for these functions.
This distinction prevents two opposite mistakes. Blocking a training crawler is not automatically the same as opting out of search, while allowing a search crawler is not a guarantee that every page will be surfaced as a cited answer. A publishing team should document its intended rights policy, confirm the correct robot identity, and assess whether infrastructure-level filtering prevents the chosen policy from working as designed.
Google Search and Google-Extended
Google describes Google-Extended as a control for certain uses of crawled content in Gemini-related products and grounding scenarios outside ordinary Google Search inclusion. Its crawler reference states that Google-Extended does not change a site’s Google Search inclusion or act as a Google Search ranking signal. For AI Overviews and AI Mode within Search, Google points site owners to its ordinary Search crawling and preview controls instead.
That is why I would not label the presence or absence of a Google-Extended rule as a universal SEO problem. It is a policy decision with a defined product scope. The same caution applies to unsupported claims that a robot rule by itself proves how an AI answer was generated or what content contributed to its response.
Write the Policy Before Editing the File
A responsible AI search visibility policy can ask which experiences the organization wants to participate in, which uses are restricted, which crawler directives express those preferences, and who is responsible for reviewing platform documentation when it changes. Security teams should be involved where access controls are managed by a CDN or firewall, and editorial teams should be involved when snippet restrictions would remove useful discovery context. No single setting solves that cross-functional decision.
Measuring AI Search Visibility Without Inventing Precision
A serious AI search visibility measurement plan begins by defining what a tool actually reports. Traditional search impressions, referrals, visible citations, and qualified reader actions are not interchangeable. Even when two reports use the same page URL and time window, their coverage and sampling may differ. Before comparing them, I would examine the definitions and exclusions published by each provider.
Google Search Console: Useful, but Aggregated
Google says that its AI Overviews and AI Mode activity is included in the overall Search Console Performance report under the Web search type. This makes Search Console valuable for understanding broader search exposure and traffic changes, but that aggregate does not establish a separate, comprehensive page-level AI citation count. I would not manufacture one by relabeling organic impressions as AI impressions. Citation tracking also needs its own platform-level definition of supported surfaces, visible references, sampling, and exclusions.
Bing AI Performance: Citation Reporting Has Defined Limits
For AI search visibility analysis, Microsoft’s AI Performance report provides aggregated citation-related measures for supported AI experiences, including pages cited, citation activity, and grouped grounding queries. Its documentation cautions that the report is not an exhaustive log of every AI answer, may use sampling, and does not equate citations with clicks, rankings, or authority. These are meaningful distinctions, not inconveniences to be hidden from a dashboard.
Referral Sessions and Qualified Outcomes Need Their Own Definitions
Website analytics can complement AI search visibility reporting by measuring relevant sessions, engagement, and conversions, subject to consent, browser restrictions, attribution gaps, and implementation quality. A visit may lack a recognizable AI referral source even when an AI system influenced the reader’s decision. The reverse problem also exists: an attributed session does not establish which specific answer persuaded the visitor. I would report observed referral traffic as observed traffic, not as a complete inventory of AI influence.
| Evidence source | Useful observation | Do not conclude |
|---|---|---|
| Google Search Console | Search impressions, clicks, queries, pages and broad performance trends | Every impression came from an AI answer |
| Bing AI Performance | Reported visible citations and grouped grounding-query activity in supported experiences | Each citation caused a visit or proves ranking quality |
| Web analytics | Observed sessions, engagement and defined conversion events | All AI-mediated influence is attributed correctly |
| Server or edge logs | Requests and responses from identifiable clients, subject to log availability | A crawler fetch means the page was cited |
| Manual query observations | A documented answer and its visible sources at a particular time | One answer represents stable platform-wide behavior |
To compare AI search visibility across time periods responsibly, I would also record when pages were published, substantially revised, made indexable, or linked from relevant sections. Without those dates, even descriptive trend analysis becomes difficult. A later increase in citations might coincide with an article update, but coincidence alone cannot isolate its effect from changing queries, product behavior, seasonal interest, or measurement coverage.
A Reproducible Audit Instead of a GEO Scorecard
Here is a practical AI search visibility evaluation method I would propose for a publication. It is a research design, not a report of experiments already conducted. Its purpose is to expose false assumptions and document changes without promising that a technical edit will produce citations.
Step 1: Define an Evidence-Based Baseline
Select a small set of already published pages with clearly different search intents. Record the intended canonical URL, current index observations, article date, relevant sources, and the exact reader decision the page supports. Choose pages because they are representative, not because they already show favorable metrics. If any page is unpublished, label it separately rather than slipping it into the baseline.
Step 2: Check Access and Representation
Inspect response status, crawler permissions, indexability signals, canonical declarations, sitemap membership, meaningful internal links, visible headings, and the final rendered schema. Record what was verified, what could not be checked, and which test tool was used. A correct local HTML parser result is not the same as confirmation that a search engine has indexed the page.
Step 3: Build a Stable Reader-Question Set
Construct a small set of questions corresponding to authentic reader tasks. Include factual lookup, comparison, uncertainty-sensitive decision, and implementation-oriented prompts when appropriate. Record the exact wording, language, region or account conditions that may affect results, the date of observation, and the tested experience. Do not represent a handful of manually observed answers as a population-level ranking measurement.
Step 4: Separate Citation, Referral, and Business Signals
Capture available provider reports and any controlled manual observations, then track relevant site analytics separately. Record whether a URL was visibly cited, whether the report’s coverage is known, and whether the site received identifiable sessions or qualified inquiries. Preserve missing values as missing. Avoid converting an absent citation into proof that the content was never considered, or a citation into evidence that an inquiry resulted.
Step 5: Change One Meaningful Issue and Reassess
If AI search visibility work reveals a genuine access defect, fix it. If its evidence is outdated, update it and document the source. If readers cannot find the conclusion, improve the content organization. Make the rationale and timing explicit and compare observations across the available reporting windows. Because platform selection is not fully observable, describe the outcome as an association unless a stronger experimental design supports a causal claim.
The result is an audit trail that can accommodate an uncomfortable but useful finding: the page may become technically better and show no measurable AI citation change. That is not necessarily a failed technical fix. It may mean the original visibility hypothesis was too strong, the metric lacked coverage, the question was not represented, or the content still did not deserve selection for the observed task.
Decision Brief: Where I Would Spend the Next Editorial Hour
When editorial time for AI search visibility is limited, the right action depends on the evidence available. I would start with a verified obstacle or a valuable unanswered reader need, not a generic GEO recommendation. The table below gives examples of decisions rather than universal rules or calculated priorities.
| Observed condition | Reasonable next action | What remains uncertain |
|---|---|---|
| Page blocked from intended search crawling | Review the access policy and correct only an unintended restriction | Whether the page will be selected later |
| Inconsistent canonical or duplicate article identities | Align URL signals and verify the chosen canonical | When a provider will recrawl and reflect the change |
| Indexable page without a useful original answer | Improve reasoning, evidence, comparison and reader usefulness | Whether the changes affect citations or qualified traffic |
| Valid schema but unsupported claims | Remove misleading claims and align markup with visible facts | Any effect on downstream answer selection |
| Citation activity but no measured qualified outcome | Review landing-page relevance and measurement coverage | Whether visitors were influenced without identifiable attribution |
| No observable citation data | Document the reporting gap and maintain other useful quality measures | Whether the page was considered by systems without reporting |
This is how I would distinguish optimization from theater. If the obstacle is real, repair it. If the evidence is incomplete, improve the measurement design. If the content lacks substance, fix the content. Do not revise the definition of success merely because the original hypothesis failed to produce the desired chart.
Limits, Trade-Offs, and the Cost of Chasing Visibility
Search systems change, reporting scopes evolve, and different interfaces may answer the same question differently. A publisher can influence clarity, accuracy, accessibility, crawl policy, information architecture, and the usefulness of a document. The publisher does not control the exact sources an answer engine selects on a particular request. Treating these as equivalent decision rights is a category error.
There is also an opportunity cost to AI search visibility work. Time spent producing artificial FAQ variations is time not spent verifying a claim, building a better example, improving accessibility, or updating a broken reference. Time spent checking a platform’s changing citation output can be valuable for research, but repeated manual checks without a stable method can generate a lot of observations and very little knowledge. I would budget for evidence quality before investing in tracking sophistication.
The relationship to long-term distribution matters as well. An owned publication creates a durable place where complete methods, caveats, and professional context can be maintained. Search and AI interfaces can help readers discover that material, but they are external distribution channels. The distinction is explored further in my article on owned media as a durable publication. I do not see AI search visibility as a substitute for the value of the underlying work.
Finally, a page can be technically correct, clearly attributed, and still unsuitable for a specific answer. Another source may be more relevant, current, or directly useful for that question. I would not interpret every absence from an answer as suppression, a penalty, or evidence that another publisher possesses a secret optimization technique.
Frequently Asked Questions
Is generative engine optimization different from SEO?
It can describe a different observation target: whether content is used or cited in AI-assisted answers rather than only how it performs as a traditional search result. But the term does not establish a universal new technical standard. For Google’s AI search features, Google’s published guidance explicitly keeps standard SEO fundamentals in scope. Other providers have their own crawler and measurement rules.
Do I need an llms.txt file?
Not to satisfy a Google requirement for AI Overviews or AI Mode. Google says no new AI-specific text file is required for those features. A separate integration may have its own documented expectations, which should be evaluated on their merits rather than generalized across the search ecosystem.
Does valid JSON-LD guarantee a citation?
No. Valid structured data can communicate page meaning and support eligibility for applicable search features, but it does not guarantee indexing, rich results, answer selection, or a citation. The markup must describe real visible content and work with the provider’s current requirements.
Can I allow ChatGPT search while restricting model-training crawling?
OpenAI documents separate controls for OAI-SearchBot and GPTBot, so a publisher can express different preferences for search inclusion and training-related crawling. That control distinction should not be mistaken for a guarantee that a page will appear in a particular answer. Relevant site and security configuration still matter.
How should I measure whether AI search visibility improved?
Define the AI search visibility metric first. Review Google Search Console’s broader Web search reporting, any available platform-specific citation data such as Bing AI Performance, observable referral sessions, and qualified site outcomes as distinct evidence streams. Document date ranges, page changes, sampling and reporting gaps. Do not merge them into a single causal claim without sufficient evidence.
Why can an indexed article remain uncited?
In AI search visibility, indexing is not the same as selection. The page may not match the observed question, other material may serve the answer better, the provider may use different sources, or available reporting may not cover the event. Without access to the system’s full selection process, an absence should be described as an observation with limits, not diagnosed with certainty.
The Goal Is a Better Publication, Not a Secret Signal
I would judge an AI search visibility strategy by how well it connects meaningful reader problems, trustworthy evidence, technical accessibility, and honest measurement. That is a more demanding standard than adding a file or repeating a keyword. It also has benefits even when the expected AI citation never appears: the publication becomes easier to inspect, more useful to readers, and less dependent on unsupported technical claims.
The practical sequence is straightforward. Establish access and indexability where they are intended. Publish an original and verifiable contribution. Describe the content accurately, including in structured data. Respect platform-specific crawler and preview controls. Measure citations, visits, and qualified outcomes separately. When results disappoint, revise the underlying hypothesis rather than inventing a new success metric. For me, that is what responsible search visibility work should look like.
Follow My Work
I share research and practical work on software engineering, artificial intelligence, user experience, product strategy, and digital publishing. You can follow my work on LinkedIn, X, Threads, GitHub, and Behance.
Explore other related research in the Digital Media Articles collection.




