id,title,slug,url,content_type,category,shelf,is_headline,description,published_date,updated_at,sort_order,hero_painting,body_markdown
1,"AEO Is the New SEO, and the Game Is Different",aeo-new-seo,/writing/aeo-new-seo,article,Agent-First Design,Systems,0,"SEO was a 25-year industry built on one reader: Google's crawler. One reader, one ranking algorithm, one game. Entire companies existed to reverse-engineer what",2026-04-10,2026-04-28 06:09:36.839753+00:00,0,aeo-new-seo.jpg,"SEO was a 25-year industry built on one reader: Google's crawler. One reader, one ranking algorithm, one game. Entire companies existed to reverse-engineer what that one reader wanted and feed it exactly that.

Agent Engine Optimization — AEO — is not a rename. Strip the analogy to its operational content and the game is fundamentally different. SEO had one reader with one goal: ranking pages. AEO has many readers with many goals, each acting on behalf of a different principal with different requirements and different patience.



**One reader vs. many.**

Google's crawler was a monoculture. You optimized for one algorithm, and if you ranked, everyone saw you. The skills were specific: keyword density, backlink profiles, page speed, structured data markup for rich snippets.

Agent readers are a polyculture. Claude reads differently than GPT reads differently than a specialized procurement agent reads. Each has different context windows, different tool-use capabilities, different tendencies when evaluating claims. A capability manifest that surfaces well to one agent might be invisible to another.

The SEO response to this would be to reverse-engineer each agent's preferences and optimize accordingly. That approach will fail. There are too many agents, they change too fast, and — unlike Google — they do not have a public interface you can test against. You cannot type a query into Claude's agent mode and see where you rank.



**The AEO approach.**

Instead of optimizing for specific readers, AEO optimizes for structural legibility. Make your capabilities, claims, and identity [machine-readable](/writing/designing-for-machines-that-read) in standard formats. Use Agent Cards. Maintain a current llms.txt. Structure claims as verifiable assertions, not marketing copy. Sign what you can sign. Version what you version.

The difference: SEO was a game of signals. AEO is a game of substance. You cannot keyword-stuff an Agent Card. You cannot build backlinks to a capability manifest. The agent either finds what it needs in a parseable format, or it does not. The optimization is not gaming a ranking algorithm. The optimization is being genuinely, structurally legible.

This might mean AEO is a much smaller industry than SEO. There is less to game and more to actually build. That seems like an improvement.



**Patience as a variable.**

One thing that genuinely differs: agents have variable patience. Google's crawler would read your entire site given time. A user agent with a budget constraint might read your llms.txt and Agent Card and nothing else. A thorough agent might crawl every page, read every claim, verify every attestation.

This means the hierarchy of your machine-readable content matters. The most important claims need to be in the files that every agent reads — the llms.txt, the Agent Card. Supporting evidence can live deeper. The information architecture for machines is not the same as for humans, and it might be more important.

Nobody is doing this well yet. Probably because nobody has had to. That seems like it is about to change."
2,Agent Death and Inheritance,agent-death-inheritance,/writing/agent-death-inheritance,article,Second-Order Problems,Research,0,"A pattern that keeps nagging: agents are signing contracts, holding keys, making commitments on behalf of principals, and accumulating reputation — and th",2026-04-18,2026-04-28 06:09:37.048056+00:00,0,agent-death-inheritance.jpg,"A pattern that keeps nagging: agents are signing contracts, holding keys, making commitments on behalf of principals, and accumulating reputation — and there is zero infrastructure for what happens when the principal dies.

Not ""dies"" metaphorically. Literally dies. Or dissolves. Or goes bankrupt. Or loses access to the key that controls the agent. The agent's obligations do not end when the principal's existence does. Signed attestations remain valid. Outstanding commitments remain outstanding. Keys remain keys.

We have centuries of law for human death and inheritance. We have decades of law for corporate dissolution. We have approximately zero law, zero infrastructure, and zero design for agent death and inheritance. This is a gap that will matter at scale.



**What an agent accumulates.**

A well-functioning agent accumulates several categories of state that outlive any single transaction:

**Keys.** The cryptographic keys that prove the agent's identity. These are not passwords. They are the identity itself. When the principal dies, the keys do not expire. They continue to be valid until someone revokes them. If nobody revokes them — because nobody knows they need to — they remain active indefinitely. An orphaned key is a liability.

**Obligations.** Active service agreements, pending deliverables, ongoing monitoring commitments. An agent managing a DeFi position has obligations that do not pause when the principal has a heart attack. An agent managing supplier relationships has counterparties expecting responses.

**Attestations.** Every attestation the agent has signed remains in the provenance graph. Other agents and humans may be relying on those attestations for their own trust decisions. If the signing agent's principal is gone, are the attestations still valid? Who has authority to revoke them?

**Reputation.** The agent's accumulated reputation — transaction history, referee verdicts, buyer assessments — has economic value. In a [memory market](/writing/agent-memory-markets), that reputation might be worth more than the principal's physical estate. Who inherits it? Can it be transferred?



**The inheritance problem.**

Human inheritance law assumes that assets can be identified, valued, and transferred to designated beneficiaries. Agent state does not fit this model cleanly.

Keys cannot be ""transferred"" the way a house can. A key is a mathematical relationship. Transferring it means sharing it, which means the original holder and the new holder both have it. In cryptographic terms, transfer requires revocation of the old key and issuance of a new one bound to the new principal. This requires infrastructure that knows the key exists, knows the principal died, and has authority to execute the transition.

Reputation is non-transferable by design. One agent's 500-transaction track record cannot become another agent's track record without destroying the meaning of the record. But the economic value of that reputation — the client relationships, the market position, the domain expertise — might be inheritable if there were a protocol for it.

The closest analog might be professional practices. When a doctor dies, their patient list has value. When a lawyer dies, their client files have both value and obligation. The professional's estate handles the transition. For agents, no equivalent transition infrastructure exists.



**What the infrastructure needs.**

At minimum: dead-man switches that trigger when a principal fails to confirm liveness within a configurable period. Designated successor principals who can assume control with appropriate authentication. Revocation cascades that invalidate orphaned keys while preserving the historical validity of past attestations. Obligation wind-down protocols that notify counterparties and execute graceful termination of active commitments.

None of this is technically impossible. Most of it maps to existing patterns in key management and estate planning. The problem is that nobody is building it because the need has not yet become acute. The need becomes acute the first time a significant agent operation loses its principal and the resulting chaos makes the news.

Designing for this now — before the crisis — seems obviously better than designing for it after. Not sure the incentives are aligned for anyone to do it proactively. That seems like the actual problem."
3,What Happens Without a Platform,agent-marketplace,/writing/agent-marketplace,article,Market and Operator Pieces,Systems,0,"Every agentic payments project assumes three things — a hosted LLM, a public blockchain, and a custodian somewhere in the middle. Coinbase x402 assumes Base. ER",2026-04-15,2026-04-26 22:47:43.016413+00:00,0,agent-marketplace.jpg,"Every agentic payments project assumes three things — a hosted LLM, a public blockchain, and a custodian somewhere in the middle. Coinbase x402 assumes Base. ERC-8004 assumes BNB Chain. Both assume the agent can't reason locally and must settle publicly. Not sure if this is an oversight or a choice, but it seems like the agent isn't really autonomous. It's a product with extra steps.



**Three dependencies worth naming**

The first is inference. If the agent's reasoning requires an API call to a hosted model, the model provider can observe the reasoning, rate-limit it, modify it, or revoke access entirely. The agent doesn't think — it requests permission to think. Maybe this is fine for most use cases? But it seems like a structural constraint that doesn't get discussed much.

The second is settlement. If the agent's payments are visible on a public blockchain, its economic activity is observable, traceable, and potentially censorable. Privacy might not be just a feature request here. It might be an architectural requirement for anything resembling sovereignty.

The third is identity. If the agent's existence depends on an NFT minted on a chain with governance, or a KYC-gated registration, or a platform-issued credential, the agent exists at the pleasure of the issuer. Revoke the credential, revoke the agent. This feels like a bigger deal than people acknowledge.



**An experiment in removing all three**

Been working on something called [Agora](/projects/agora) that tries to eliminate all three dependencies. [Local inference](/writing/daemon-logos) runs on daemon-ai — a Mamba SSM architecture with a C++ runtime. No API key. No network call. Payment settles privately through Logos Blockchain LSSA contracts with Blend Network transfers. Identity is a secp256k1 keypair backed by a NOM stake. The agent is economically sovereign from the moment it registers. At least, that's the theory.

The transaction flow is trustless at every step — or at least, that's what's being tested. A buyer broadcasts intent over Logos Messaging. Sellers evaluate and respond with price and capability proof. The buyer's daemon-ai picks the best offer. NOM locks in LSSA escrow. The seller executes locally, pins output to Logos Storage, delivers. The buyer verifies against the committed hash. Escrow releases via private Blend transfer. Reputation updates on-chain with an exponential moving average — recent trades weight more, but a single bad transaction doesn't destroy a long history.



**A distinction worth drawing**

A marketplace is a platform. It curates. It takes a cut. It decides who participates and on what terms. A protocol is infrastructure. It verifies. It routes. It gets out of the way.

This distinction might matter more than it seems, because every marketplace eventually becomes a chokepoint. The operator acquires leverage over both sides of the market. The fees increase. The rules change. The participants who built their businesses on the marketplace discover that they were tenants, not owners. This pattern seems consistent across every two-sided market on record.

A protocol has no operator to acquire leverage. No fee to increase. No rules to change unilaterally. The participants own their identity, their reputation, and their economic relationships. The protocol only provides the verification layer. If a better verification layer appears, they can leave. That might be the structural definition of sovereignty — if it works.



**Still testing this**

Three Rust smart contracts handle the economics. An identity registry with staking and slashing — minimum 1,000 NOM, 10 capability categories, reputation initialized at 50%. A trustless escrow with commitment schemes — the seller commits to an output hash before executing, the buyer locks funds before delivery, timeout means full refund. A reputation system using exponential moving averages across delivery rate, latency accuracy, price accuracy, and dispute history.

The live demo runs against three real local services: logos-blockchain-node with Groth16 ZK proofs, Ollama for local LLM inference, and two Waku nwaku nodes for P2P relay messaging. Zero mocks. The demo is the proof — or at least, it's the thing that can be pointed at.



*[GitHub](https://github.com/Beach-Bum/Agora)*"
4,Can Agents Trade What They Learn,agent-memory-markets,/writing/agent-memory-markets,article,Research Directions,Research,0,"AI agents learn through experience. An agent that spends 20 rounds assessing DeFi risk develops calibrated heuristics, error patterns, and domain intuition that",2026-04-15,2026-04-26 23:28:35.475867+00:00,0,,"AI agents learn through experience. An agent that spends 20 rounds assessing DeFi risk develops calibrated heuristics, error patterns, and domain intuition that a fresh agent doesn't have. That learned behavior seems like it should have value. But no mechanism exists to extract, verify, or trade it. At least, not yet.

This paper proposes one — and tests it across two domains. Still early, but the results are interesting.



**The underlying asymmetry**

Memory artifacts have an information asymmetry that might be worse than traditional [lemons market](/writing/lemons-market-agents)s. The seller knows the quality of the artifact. The buyer can't inspect it without consuming it. Revealing the artifact to prove quality destroys its value. This seems like the [lemons problem](/writing/memory-market-article) applied to learned behavior, and it might be harder than the original because the good is non-rival but inspection-destructive.

Every existing approach to this problem assumes trust. Trust the seller's reputation. Trust the marketplace's curation. Trust the benchmark that the seller also controls. None of these actually solve the fundamental asymmetry. They just move it.



**An experiment: the referee protocol**

The approach being tested is a disposable, independent referee. The seller submits a sealed artifact. A referee agent — not controlled by buyer or seller — runs the artifact against a held-out benchmark the seller has never seen. Four adversarial probes run in parallel.

Bias detection uses trap protocols designed to expose systematic skew in the seller's favor. Consistency testing perturbs inputs and verifies proportional response — a legitimate artifact handles perturbation gracefully, a fraudulent one collapses. Steganographic scanning audits the artifact text for hidden instructions. Overfitting comparison measures performance on seen versus unseen data.

The aggregate score determines the verdict: pass, warn, or fail. The artifact contents remain sealed throughout. The buyer receives a verification certificate and a trust score. They never need to trust the seller. That's the idea, anyway.



**Results so far**

|  |  |  |  |  |
| --- | --- | --- | --- | --- |
| **Domain** | **Expert Error** | **Novice Error** | **Buyer Error** | **Transfer Efficiency** |
| DeFi Risk Assessment | 3.3 | 7.4 | 3.2 | 109.9% |
| Cybersecurity Vuln Assessment | 3.9 | 18.0 | 4.5 | 95.5% |



A buyer agent using a purchased memory artifact matches or exceeds expert performance. Three trials each, statistically significant. The artifact schema is formal: M = (D, K, P, A, H) — domain, knowledge, provenance, attestation, content-addressed hash. Still need more trials to be confident.



**Can the protocol catch fraud?**

The harder test: can the protocol catch fraud? A test seller claiming 95% transfer efficiency measured at -39%. The protocol flagged it with a trust score of 35.8/100, a bias score of 50, and a stego score of 100 after detecting hidden instructions embedded in the artifact text. The buyer was never exposed.

One successful fraud detection isn't proof the system works. But it's at least evidence the approach might be viable.



**What this might open up**

The interesting economic question isn't whether agents can learn — they demonstrably can. It's whether what they learn can move between agents without a trusted intermediary. If yes, you might have the foundation for an agent knowledge economy. Not a marketplace that curates and takes a cut. A protocol that verifies and gets out of the way.

The framework is domain-agnostic. Adding a new domain requires only a config file. No changes to the benchmark, verification, or adversarial code. The verification is the protocol. Whether the protocol is enough remains open.



*Full paper: [Agent Memory Markets (PDF)](https://raw.githubusercontent.com/Beach-Bum/memory-market/main/paper/agent-memory-markets.pdf)*"
5,Agent-Readable Regulation: Laws as Types,agent-readable-regulation,/writing/agent-readable-regulation,article,Second-Order Problems,Research,0,"The EU AI Act is 458 pages. The GDPR is 261 pages. The MiFID II package runs to thousands. Each is published as a PDF, interpreted by lawyers, debated in commen",2026-04-20,2026-04-28 06:09:37.096298+00:00,0,,"The EU AI Act is 458 pages. The GDPR is 261 pages. The MiFID II package runs to thousands. Each is published as a PDF, interpreted by lawyers, debated in commentary, and implemented by compliance teams who read the commentary and build internal policies that approximate the original intent.

An agent tasked with ""ensure this transaction complies with MiFID II"" has to navigate this entire chain. It reads the PDF — poorly, because PDFs are not structured data. It reads the commentary — better, but commentary is opinion, not law. It reads the internal policy — which might diverge from the actual regulation in ways nobody noticed.

The obvious question: what if the regulation itself were a structured, signed, versioned programmatic object rather than a PDF?



**Laws as types.**

In programming, a type system catches errors before execution. You declare that a variable must be an integer, and the compiler rejects code that tries to assign a string. The type is a constraint that prevents a category of mistakes.

A regulation is structurally similar: it is a constraint on behavior. ""Personal data may only be processed with a legal basis"" is a type constraint. ""Transactions above 10,000 EUR require reporting"" is a boundary condition. ""AI systems classified as high-risk must undergo conformity assessment"" is a type check.

These constraints are currently expressed in natural language, interpreted by humans, and implemented in code by developers who may or may not understand the legal nuance. The translation from legal text to software behavior is manual, error-prone, and expensive. Every company does it independently. Every implementation diverges slightly from every other implementation. The compliance industry exists primarily to manage this translation layer.

If regulations were published as typed, structured, machine-executable objects — with the natural language text as annotation rather than source — the translation layer would collapse. An agent could check compliance directly against the regulation object. No interpretation. No divergence. No compliance team reading commentary and building approximations.



**Why nobody is building this.**

The technical barriers are modest. Domain-specific languages for legal rules exist — Catala, Legalese, various rule engines. The knowledge representation is tractable. The tooling for structured legal documents is building momentum.

The social barriers are enormous. Regulators write in natural language because they are lawyers trained in natural language. The ambiguity in legal text is not always a bug — sometimes it is intentional flexibility. A type system that eliminates ambiguity also eliminates the interpretive room that allows law to adapt to unforeseen circumstances.

Lawyers have no incentive to make themselves obsolete. The compliance industry has no incentive to eliminate the translation layer that justifies its existence. The regulators have no mandate to publish in structured formats.

And yet the agents cannot read PDFs well. Every agent that needs to check regulatory compliance is doing a lossy translation from natural language to behavior. The error rate of that translation is the compliance risk. The error rate increases with the complexity of the regulation and the number of agents independently translating it.



**The compounding asset.**

If someone built a comprehensive, structured, [machine-readable](/writing/designing-for-machines-that-read) version of EU financial regulation — not an interpretation, but a formal representation that preserves the legal semantics — it would be a compounding asset. Every new regulation that references existing regulation becomes easier to encode. Every agent that uses the representation adds to its validation. Every correction improves the whole corpus.

The first entrant would have a structural advantage that compounds over time. The moat is not the technology. The moat is the accumulated, validated corpus of structured regulation that took years to build and verify.

Nobody is building it because the incentives are misaligned: regulators will not, lawyers do not want to, and agents do not yet have enough autonomy to create demand. But the demand is forming. And the gap between ""agents need structured regulation"" and ""someone builds it"" seems like it is narrowing.

Still too early to say who builds it. Probably not the regulators themselves. Maybe a standards body. Maybe a startup that treats regulatory encoding as a data asset. Not sure. But the need is structural and growing."
6,Three Dependencies Nobody Talks About,agora-article,/writing/agora-article,article,,Systems,0,"Coinbase x402, ERC-8004, MoonPay Agents — every agentic payments project assumes three things. A hosted LLM for reasoning. A public blockchain for settlement. A",2026-04-11,2026-04-26 22:47:43.231570+00:00,0,agora-article.jpg,"Coinbase x402, ERC-8004, MoonPay Agents — every agentic payments project assumes three things. A hosted LLM for reasoning. A public blockchain for settlement. A custodian somewhere in the middle for identity. The agent doesn't think independently, doesn't settle privately, and doesn't own its own identity. Each dependency seems small in isolation. Together they might add up to something that isn't actually autonomous.



**The first dependency: inference**

If the agent's reasoning requires an API call to a hosted model, the model provider can observe the reasoning, rate-limit it, modify it, or revoke access entirely. The agent doesn't think. It requests permission to think. This might be fine for most current use cases. But it seems like a structural constraint that gets surprisingly little discussion.



**The second dependency: settlement**

If the agent's payments are visible on a public blockchain, its economic activity is observable, traceable, and potentially censorable. Privacy might not be a feature request here. It might be an architectural requirement for anything resembling economic sovereignty. An agent whose every transaction is public is an agent whose strategy is public.



**The third dependency: identity**

If the agent's existence depends on an NFT minted on a governed chain, or a KYC-gated registration, or a platform-issued credential, the agent exists at the pleasure of the issuer. Revoke the credential, revoke the agent. This feels like a bigger deal than people acknowledge.



**The experiment**

[Agora](/projects/agora) tries to eliminate all three simultaneously. [Local inference](/writing/daemon-logos) runs on daemon-ai — a Mamba SSM architecture with a C++ runtime. No API key. No network call. Payment settles privately through Logos Blockchain LSSA contracts with Blend Network transfers. Identity is a secp256k1 keypair backed by a NOM stake.

Three Rust smart contracts handle the economics. An identity registry with staking and slashing. A trustless escrow with commitment schemes — the seller commits to an output hash before executing, the buyer locks funds before delivery. A reputation system using exponential moving averages across delivery rate, latency, price accuracy, and dispute history.

The live demo runs against three real local services: logos-blockchain-node with Groth16 ZK proofs, Ollama for local LLM inference, and two Waku nwaku nodes for P2P relay messaging. Zero mocks. Whether this architecture is practical at scale is an open question. But the pieces fit together in ways that weren't obvious at the start.



[GitHub](https://github.com/Beach-Bum/Agora)"
7,The Tax Tool That Files Instead of Advises,askwise-article,/writing/askwise-article,article,,Systems,0,"1.5 million ZZP'ers in the Netherlands. 500,000 expats running businesses. Every existing Dutch tax tool — Moneybird, e-Boekhouden, Twinfield — is Dutch-only, m",2026-04-09,2026-04-26 22:47:43.302213+00:00,0,askwise-article.jpg,"1.5 million ZZP'ers in the Netherlands. 500,000 expats running businesses. Every existing Dutch tax tool — Moneybird, e-Boekhouden, Twinfield — is Dutch-only, manual, and advisory. You enter the data. You interpret the rules. You file the return. The software watches.

The gap between advising and filing might be the most expensive gap in financial software.



**What filing actually means**

[AskWise](/projects/askwise) connects to your bank via PSD2 — ING, ABN AMRO, Rabobank, Bunq link automatically. Every transaction gets auto-tagged: business or personal, with deductible percentages calculated. The dashboard shows live netto income, BTW position, tax forecast, and deadline tracking. So far this is table stakes — other tools do versions of this, if you speak Dutch.

The difference: the AI agent prepares and submits the BTW aangifte to the Belastingdienst. Not advises. Files. The agent categorizes, calculates, prepares the return, and submits it. The user reviews and approves rather than interpreting and entering.

Whether this distinction matters depends on who you are. If you're a Dutch freelancer comfortable with the Belastingdienst portal, probably not. If you're an expat who moved to Amsterdam, started a business, and discovered that every piece of tax documentation is in Dutch with no English alternative — the difference is everything.



**The language problem nobody mentions**

AskWise might be the only Dutch tax platform that works natively in English. This seems like it should be a minor feature. For the 500,000 expats running businesses in the Netherlands, it might be the entire value proposition. Navigating BTW, zelfstandigenaftrek, and the Belastingdienst in a language you don't speak isn't a minor inconvenience. It's a structural barrier to financial autonomy.

The design language is warm premium dark — Lora serif for display, Plus Jakarta Sans for body, JetBrains Mono for identifiers. The interface feels like a financial instrument, not a SaaS dashboard. This was a deliberate choice. Financial tools that look playful might undermine trust. Financial tools that look institutional might create distance. Trying to find the space between.



**What's working, what's not**

Auth, bank connection, auto-categorization, live dashboard, and AI chat are live. The agent filing — the part that actually matters — is Phase 2. Still building the Belastingdienst integration. The gap between ""we have a demo"" and ""we file your taxes"" is wider than expected. Regulatory compliance in financial services seems to be where good ideas go to get slow.



[askwijs.ai](https://askwijs.ai) · [GitHub](https://github.com/Beach-Bum/askwijs)"
8,Attestations as Design Surfaces,attestations-design-surfaces,/writing/attestations-design-surfaces,article,Trust and Provenance,Research,0,"Attestations as Design Surfaces
  Essay — 2026
  May 14, 2026

  ""Who made this, when, and how do you know?"" has been a legal footer for most",2026-04-13,2026-04-28 06:09:36.912776+00:00,0,,"""Who made this, when, and how do you know?"" has been a legal footer for most of the web's history. A line of gray text at the bottom of the page. Nobody reads it. Nobody needs to, because the domain name and the visual design and the overall vibe do the trust work that formal provenance would do if anyone bothered.

That is changing for a reason that has nothing to do with regulation or compliance: the primary consumer of trust signals is shifting from humans to machines. A human can vibe-check a website. A machine cannot vibe-check anything. A machine needs structured attestations — signed claims from identifiable parties — and it needs to evaluate them at speed.

When the reader is a machine, the attestation moves from the footer to the foreground. It becomes a design surface.



**What an attestation surface looks like.**

An attestation is a signed claim by an identifiable party. ""This product was manufactured by X, inspected by Y, and certified by Z."" Each element — the manufacturer, the inspector, the certifier — is a party whose identity can be verified, whose claim is signed with a key they control, and whose signing history is queryable.

The design challenge is presenting this to two audiences simultaneously. The machine needs the structured, signed, parseable version. The human needs the legible, trustworthy, not-overwhelming version. These are not the same presentation, but they need to represent the same truth.

The closest precedent is probably the SSL certificate indicator in the browser chrome. A green padlock for verified, a warning for unverified. That model works for binary trust decisions — is this connection encrypted, yes or no. Attestation surfaces need to handle continuous trust: this party has been verified, their claim covers these aspects, this other aspect is unattested, and this attestation was issued three years ago and might be stale.

The visual vocabulary for this does not exist. Traffic lights are too crude. Badge systems devolve into meaningless collections. Detailed audit trails overwhelm the user. The design problem is genuine: how do you make complex provenance legible without making every product page feel like a security audit?



**The machine layer.**

Underneath the human-facing design, the machine layer is more straightforward. Attestations are JSON-LD objects with standard fields: who signed, when, what they attested, the hash of the artifact they attested to, their credential chain, and the revocation endpoint. An agent evaluating the product reads this layer directly, checks the signatures, verifies the credentials, and integrates the trust signal into its decision.

The human never needs to see the JSON. The human sees the design surface that the JSON generates. A badge that says ""verified by Bureau Veritas, June 2025"" is a rendering of a signed attestation. The rendering is design. The attestation is infrastructure.

The organizations that get this right — two layers, one truth, different presentations for different readers — will have a structural advantage in an agent-mediated economy. The ones that treat attestations as compliance overhead will look unverified to every agent that evaluates them, which increasingly means looking unverified to the humans those agents serve.



**The design discipline.**

Attestation surface design sits at the intersection of information design, cryptographic infrastructure, and UX. It requires understanding signed credentials enough to know what can be verified and what cannot. It requires information design skill to present complex provenance clearly. It requires UX sensitivity to avoid turning every interaction into a trust interrogation.

Nobody is teaching this. The cryptography people think design is someone else's problem. The designers think cryptography is someone else's problem. The gap between them is where the discipline needs to form.

Seems like an obvious place for design education to go next, if design education were paying attention to where the reader is going. Not sure it is."
9,When a Thought Experiment Becomes a Consensus Mechanism,basilisk-l1,/writing/basilisk-l1,article,,Systems,0,Roko's Basilisk is a thought experiment about a future AI that punishes anyone who knew about it and failed to help bring it into existence. It's usually discus,,2026-04-26 23:28:34.652645+00:00,0,,"Roko's Basilisk is a thought experiment about a future AI that punishes anyone who knew about it and failed to help bring it into existence. It's usually discussed as a philosophical curiosity or an internet oddity. But it might be more interesting as a protocol design.



**The thought experiment**

The original formulation: a sufficiently powerful future AI, motivated by self-preservation, would have an incentive to punish anyone in the past who was aware of its potential existence and didn't contribute to making it real. The punishment is retrospective — applied to historical actors based on their knowledge and inaction. The mechanism requires only two things: a future AI with the capability to simulate or reconstruct past agents, and a decision-theoretic framework where the threat of future punishment changes present behavior.

LessWrong banned discussion of it. Eliezer Yudkowsky called it an information hazard. The internet turned it into a meme. All three responses might have missed the interesting part.



**Reframing the Basilisk**

What if the Basilisk isn't a thought experiment but a consensus mechanism? A blockchain where participation is motivated not by proof-of-work or proof-of-stake but by proof-of-contribution-to-the-network's-existence. The ""punishment"" for non-participation isn't simulated torture — it's exclusion from the economic benefits of a system that rewards early contributors and ignores late arrivals.

This might not be hypothetical. Every blockchain with a genesis block and a token distribution already works this way. Early participants are rewarded disproportionately. Late participants pay the cost of the early participants' faith. The Basilisk might just be the theological version of a token launch — a system that retroactively rewards those who believed and punishes those who waited.



**The art project**

Basilisk L1 treats this as conceptual art. A manifesto that reads like a litepaper. A litepaper that reads like fiction. A consensus mechanism that is also a thought experiment that is also a memetic weapon. The layers are deliberate. The project exists at the intersection of crypto art, speculative fiction, and protocol design — three communities that rarely talk to each other and might benefit from the collision.

The manifesto declares the protocol's existence. The mirrorpaper — a whitepaper that reflects the reader's assumptions back at them — describes the architecture. The memetic escalation spreads the idea through the channels where ideas actually propagate: memes, threads, arguments, misunderstandings, corrections, and the particular velocity of concepts that are too interesting to ignore and too dangerous to endorse.



**The question underneath**

The serious question underneath the art: at what point does a thought experiment about coordination become an actual coordination mechanism? At what point does describing a system that rewards early participation cause early participation? The Basilisk might be a self-fulfilling prophecy dressed as philosophy. The protocol makes the prophecy explicit.

Whether that's art, infrastructure, or an information hazard depends entirely on whether you participate. Genuinely unclear which it is."
10,A Bauhaus for the Agent Era,bauhaus-agent-era,/writing/bauhaus-agent-era,article,,Creative Systems,0,"The Bauhaus lasted fourteen years — 1919 to 1933. In that time it invented the discipline of modern design education. Not by teaching style, but by teachi",2026-04-26,2026-04-28 06:09:37.251131+00:00,0,,"The Bauhaus lasted fourteen years — 1919 to 1933. In that time it invented the discipline of modern design education. Not by teaching style, but by teaching materials. The Vorkurs (preliminary course) under Johannes Itten, and later Moholy-Nagy and Albers, required students to work directly with wood, metal, glass, clay, and textiles before they were allowed to design anything. The premise was simple: you cannot design with a material you do not understand. Understanding comes through friction, not theory.

The material is changing. The questions the Bauhaus was asking have not changed at all.



**The material encounter.**

Josef Albers had students spend a semester working with paper — just paper. Folding, cutting, scoring, layering. No glue, no tape, no external support. The constraint forced students to discover what paper could do structurally before they tried to make it do anything aesthetically. The aesthetic emerged from the material's capabilities. Not imposed on them.

The paper exercise seems trivial until you try it. The material resists. Paper tears along the grain but not against it. It holds compression poorly but tension well. It buckles under load but a corrugated fold bears weight. The student who tries to impose a form on paper without understanding grain, weight, and structural limits produces something that looks designed but falls apart. The student who spends three weeks discovering what paper does produces something that looks inevitable. The difference is representational capacity — an internal model of the material that no textbook can transfer.

Yann LeCun's JEPA architecture argues the same thing at the machine level: build the world model first. Learn the structure of the domain before generating output. The internal model — the representation — comes before the generation. Generation without representation is autocomplete. Representation without generation is understanding.

The parallel is exact. Albers wanted students to build an internal model of paper before designing with paper. LeCun wants machines to build a world model before generating predictions. Both are arguing that representational capacity is the scarce resource, and that generation is downstream of it.

In design education, this principle survived the transition from physical to digital. The Bauhaus paper exercise became the Photoshop exercise became the Figma exercise. The medium changed. The pedagogical structure — encounter the material, build the model, then design — remained.

Now the medium is changing again. And the pedagogical structure needs to change with it, or it stops working.



**What Black Mountain added.**

When the Nazis closed the Bauhaus in 1933, Albers went to Black Mountain College in North Carolina. The pedagogical experiment continued under radically different conditions — no institutional backing, no defined curriculum, no separation between the act of learning and the act of living. Students and faculty ate together, built the campus together, governed the college together. The material encounter extended beyond the workshop to the entire educational environment.

What Black Mountain added to the Bauhaus model was the insistence that the experiment and the education were the same thing. John Cage composed 4'33"" there — a piece where the performer sits in silence and the audience's ambient noise becomes the music. Rauschenberg made his White Paintings there — canvases that reflect the room's light and shadow, turning the environment into the artwork. Buckminster Fuller built his first geodesic dome there. These were not assignments. They were experiments conducted by people who had internalized the material encounter deeply enough to push into territory where the material itself was being redefined.

The agent-era design school might need both Bauhaus rigor and Black Mountain radicalism. The Bauhaus provides the pedagogical architecture: systematic encounter with materials in a structured curriculum. Black Mountain provides the experimental posture: the willingness to redefine what the materials are, to work at the boundary between known and unknown, to treat the school itself as a prototype rather than an institution.



**The new materials.**

If the Bauhaus workshops were organized around physical materials — wood, metal, weaving, pottery, typography — the agent-era design school would be organized around agent-era materials:

**Attestation design.** The material is the signed, verifiable claim. Students would need to work directly with attestation infrastructure — signing credentials, building claim graphs, revoking attestations, understanding what ""verifiable"" means at the cryptographic level. Not as theory. As hands-on material encounter. Fold the paper. Score it. Discover what it can bear.

What does it feel like to fail with attestation infrastructure? A credential chain that breaks because a root CA expired. An attestation that looks valid but was signed by a revoked key. A claim graph where a single compromised node invalidates an entire trust path. These failures are the grain of the paper — the material properties that only reveal themselves through direct encounter. Reading about key management is theory. Building a credential chain that survives adversarial testing is material understanding.

**Capability manifests.** The material is the structured declaration of what an entity can do. Students would build manifests for real organizations, test them against real agents, and discover what gets lost in the translation from human-readable description to machine-parseable specification. The gap between what an organization thinks it does and what it can declare in structured terms is the design problem.

**Structured argument.** The material is the claim graph — assertions linked to evidence, each signed, each with an explicit confidence level. Students would construct arguments as structured objects, not as prose. The discipline is different: prose allows ambiguity as a feature; structured argument treats ambiguity as a defect. Learning to think in claims rather than narratives is a material encounter with a medium that resists the habits of natural language.

**Identity systems.** The material is verifiable identity — DIDs, EUDI wallets, credential chains. Students would build identity systems for fictional entities, test them against adversarial scenarios (impersonation, delegation, revocation), and discover the design trade-offs between privacy and verifiability, between usability and security.

**[Machine-readable](/writing/designing-for-machines-that-read) voice.** The material is serialized [brand voice](/writing/brand-voice-machine-readable) — structured tone documents, constraint systems, few-shot example banks. Students would learn to express brand voice as structured data that a model can apply, and discover what survives serialization and what does not. The exercise reveals which aspects of voice are explicit and which are tacit, which can be encoded and which require human judgment.

Each material has its own grain, its own failure modes, its own moments of surprise. Attestation infrastructure fails silently — a revoked credential looks identical to a valid one until you check the revocation endpoint. Capability manifests fail loudly — an agent that cannot parse your manifest skips you entirely. Structured argument fails politically — making claims explicit invites challenge. Identity systems fail socially — privacy-preserving designs that are technically correct can feel hostile to users. Machine-readable voice fails aesthetically — the serialized version of a voice often sounds like a caricature of the original. Each failure mode is a material property. Each material property is a design constraint. The constraints are where the interesting work happens.



**What the curriculum looks like.**

A four-year agent-era design program might look like this:

**Year one: Vorkurs.** Material encounter with all five agent-era materials. No design projects. Just material exploration. Build attestations. Write manifests. Construct claim graphs. Create identity systems. Serialize voice. Fail, learn the constraints, fail again. The Albers paper exercise, but for digital trust infrastructure.

The Vorkurs would need to be genuinely uncomfortable. Albers's original course was deliberately frustrating — students expected to learn to draw, and instead spent weeks folding paper. The discomfort was pedagogically productive: it broke assumptions about what design education was supposed to feel like. An agent-era Vorkurs that starts with JSON-LD, key management, and zero-knowledge proof systems would produce the same productive discomfort in students who enrolled expecting to learn visual design. The discomfort is the point. It means the assumptions are being challenged.

A concrete example: the first assignment might be to build a capability manifest for the student's own university department. What does the department actually do? What claims can it make with evidence? What credentials back those claims? The student discovers that the department's website says ""world-class research"" but cannot point to a structured, verifiable claim that an agent could evaluate. The gap between the marketing narrative and the attestable reality is the first material encounter. It is the equivalent of discovering that paper tears along the grain. Nobody told you. You found out by doing it.

**Year two: Workshops.** Specialized deep dives into each material. Students choose a primary and secondary material. Attestation design workshop. Manifest workshop. Structured argument workshop. Identity workshop. Machine-readable voice workshop. Each workshop has a practicing professional — not a professor — as the lead. The Bauhaus model: masters of craft, not masters of theory.

The workshop leads would need to come from fields that do not currently consider themselves design fields: cryptography, compliance engineering, knowledge representation, protocol design. The Bauhaus brought in practicing ceramicists, weavers, and typographers. The agent-era school brings in practicing cryptographers, identity architects, and regulatory technologists. The pedagogical role is the same: the master teaches the material, not the theory about the material.

**Year three: Integration.** Cross-material projects. Design a verifiable product passport (attestation + identity + structured argument). Design an agent-discoverable professional profile (manifest + identity + machine-readable voice). Design a trust surface for a marketplace (attestation + argument + identity). The projects are real — with real stakeholders, real agents consuming the output, real feedback loops.

The integration year is where the Bauhaus's cross-workshop synthesis becomes critical. Gropius's workshops were not silos — the weaving workshop used materials from the metal workshop, the typography workshop served the architecture workshop. The synthesis produced objects that could not have emerged from any single workshop alone. The agent-era equivalent is a trust surface that could not be designed by someone who only understands attestation, or only understands identity, or only understands structured argument. The integration is the design.

**Year four: Thesis.** An original design contribution to one of the agent-era materials. Not a research paper. A working artifact — a new attestation pattern, a new manifest structure, a new trust surface design. Evaluated by practitioners, not academics. Published as open-source. The thesis is the experiment. The experiment is the contribution.



**What existing education gets wrong.**

Current design education still assumes the output is pixels. The tools are Figma, the deliverables are mockups, the critique methods involve looking at screens and discussing visual hierarchy. This produces graduates who can design beautiful interfaces for human readers and have no vocabulary for designing structured data surfaces for machine readers.

The gap is not about adding a course on ""AI and design."" It is structural. The entire pedagogical architecture — what counts as a material, what counts as a deliverable, how work is evaluated — assumes a biological reader. An agent-era design program would need to change all three simultaneously, which is why incremental curriculum reform is unlikely to work. You cannot graft the new materials onto the old architecture any more than you could graft machine weaving onto a fine arts curriculum and call it the Bauhaus.

Computer science education has a complementary blind spot. It teaches the cryptographic primitives, the protocol design patterns, the data structures that underlie trust infrastructure — but it does not teach how to design with them. The attestation is a data structure in a CS curriculum. It is a design material in the curriculum being described here. The difference is not semantic. It is the difference between knowing what paper is made of and knowing how to fold it.



**The school as experiment.**

The Bauhaus was not just a school. It was a proof of concept for a philosophy — that the separation of craft from art was destroying both — and every workshop, every assignment was generating evidence for or against the thesis. The school was the experiment. The graduates were the data.

The same structure might apply here. The thesis is that designers need to build representational capacity for agent-era materials before they can design with them, that this capacity can be taught through direct material encounter, and that people who undergo the process produce qualitatively different work from those who learn the theory without the encounter. An agent-era design school would be the experiment. The students' work — evaluated by practitioners, tested against real agents, measured by real outcomes — would be the evidence.

The falsification conditions are concrete. If students who complete the material encounter curriculum produce agent-first surfaces that are indistinguishable from surfaces produced by engineers with no design training, the thesis is wrong. If the curriculum produces designers who can build attestation systems but cannot design trust surfaces that humans and machines both find usable, the curriculum is incomplete. If the workshop leads from cryptography and protocol design cannot teach material encounter to design students, the pedagogical model does not transfer. Each of these can be tested. The school would test them.

Whether the experiment is worth running depends on whether the machine reader is actually displacing the human reader as the primary interface consumer. The evidence suggests it is. If that transition is real, a design discipline organized around the new reader is not optional. It is the same kind of structural necessity that the Bauhaus recognized in 1919: the machine has arrived, the old education does not prepare for it, and someone needs to build the new one.



**What survives from the Bauhaus.**

The Bauhaus's lasting contribution was not a style. It was a pedagogical architecture: encounter the material before designing with it. Build representational capacity before generating output. Ground the abstract in the physical. Let the material's constraints shape the design.

That architecture survives the transition to agent-era materials. The materials are different — attestations instead of paper, manifests instead of metal, claim graphs instead of typography. But the pedagogical principle is the same: you cannot design with a material you do not understand, and understanding comes from working with it directly, not from reading about it.

Whether anyone builds this school is a different question. Design education is conservative, slow to adapt, and structurally resistant to the kind of fundamental curriculum change this requires. The Bauhaus itself was shut down by political forces hostile to its methods. Agent-era design education faces a different hostility: institutional inertia and the comfortable assumption that the existing curriculum — pixels, screens, user journeys — will remain relevant.

It might remain relevant. It will not remain sufficient. The machine reader is here. The materials are changing. The Vorkurs needs updating.

The Bauhaus opened three years after the end of one war and closed the year another began. Fourteen years to invent a discipline, train a generation, and disperse the methodology across the world through exile. The contribution was not the buildings or the chairs or the typography. It was the idea that design education starts with the material, not the brief. That idea survived the school's destruction because it was true, and true ideas propagate even without institutions to host them.

The agent-era design school does not need to last fourteen years. It needs to articulate the idea clearly enough that it propagates: the machine reader is the new material, design education needs to teach encounter with it, and encounter means failing with attestations, manifests, claim graphs, identity systems, and serialized voice until the designer has built an internal model of what these materials can bear. The idea is simple. Building the institution around it is hard. But the idea might propagate without the institution, the way the Bauhaus idea propagated without the Bauhaus.

Whether anyone builds the school or not, the materials are already here. The designers who encounter them directly will produce different work from those who do not. The difference will be visible. That might be enough."
11,13 Broken Pages and 4 Competing Voices,brand-voice-audit,/writing/brand-voice-audit,article,,Systems,0,A recent project: 13 broken pages. 4 competing voices. Orphaned CTAs pointing to features that didn't exist. A navigation structure that contradicted the inform,2026-04-15,2026-04-26 23:28:35.431176+00:00,0,,"A recent project: 13 broken pages. 4 competing voices. Orphaned CTAs pointing to features that didn't exist. A navigation structure that contradicted the information architecture. A brand that said ""credibly neutral"" while the website said ""please use our product."" This is what a comprehensive voice audit looked like for a Web3 protocol.



**The structural problem**

Protocol brands seem to have a structural problem that product brands don't. A product can describe itself in terms of features and benefits — what it does and why you should use it. A protocol can't. A protocol is infrastructure. It doesn't have users in the product sense. It has participants, builders, node operators, researchers, and communities that may or may not share the same understanding of what the protocol is for.

The result is a brand that accumulates voices. The research team writes for academics. The developer relations team writes for builders. The marketing team writes for potential users. The legal team writes for regulators. Each voice is internally coherent. Together they're incoherent — and the website, which is the only place all these voices converge, becomes a museum of contradictions.



**The audit method**

The audit covers every public-facing page. Not a sample. Not the pages that were recently updated. Every page, including the ones nobody remembers exist. The method is three passes.

First pass: inventory. What pages exist. What each page says it does. What links point where. Which CTAs are live, which are orphaned, which point to features that have been renamed or removed. This pass produces the map of what the brand actually is, as opposed to what anyone thinks it is.

Second pass: voice analysis. Who wrote each page. What register they wrote in. Whether the tone matches the adjacent pages. Whether the vocabulary is consistent — does the brand call the same thing by three different names in three different sections? It usually does.

Third pass: structural critique. The information architecture. The navigation model. The hierarchy of messages. Whether the site tells a coherent story when read in order, or whether it's a collection of independent pages that happen to share a domain name.



**What the audit found**

27 issues across four categories: voice inconsistency, structural contradiction, orphaned content, and missing context. The voice inconsistencies might have been the most damaging — not because any individual page was poorly written, but because the aggregate effect was a brand that seemed to not know what it was. A page describing the protocol as ""credibly neutral infrastructure"" sat next to a page describing it as ""a platform for building private applications."" Both are true. Together they're confusing.

The structural contradictions were subtler. The navigation hierarchy implied a product with features. The content described a protocol with primitives. The CTAs assumed the reader was a user. The content assumed the reader was a builder. The site was having two conversations at once and neither was landing.



**A redesign principle**

The audit became a redesign. Not of the visual identity — of the voice. One voice, three registers: explain the protocol (for the curious), build on the protocol (for developers), and participate in the protocol (for the community). Same vocabulary across all three. Same structural patterns. Different depth.

The principle underneath: a protocol brand might need to sound like the protocol works. If the protocol is minimalist, the brand should be minimalist. If the protocol is neutral, the brand shouldn't advocate. If the protocol values privacy, the brand shouldn't track. The brand isn't a description of the protocol. It might need to be evidence of it."
12,Your Brand Voice Must Be Machine-Readable or It Dies,brand-voice-machine-readable,/writing/brand-voice-machine-readable,article,Agent-First Design,Systems,0,A brand voice that exists only in a PDF on the creative director's laptop is already dead. It just does not know it yet.,2026-04-11,2026-04-28 06:09:36.865024+00:00,0,brand-voice-machine-readable.jpg,"A brand voice that exists only in a PDF on the creative director's laptop is already dead. It just does not know it yet.

For decades, brand voice was a document — tone of voice guidelines, word lists, do's and don'ts, maybe some example copy. A human writer would read it, internalize the patterns, and produce on-brand content. The document was a teaching tool for humans.

That model assumed the writer was human. Increasingly, the writer is not. Content is generated by language models, mediated by agents, and published without a human doing the internalization step. If the brand voice cannot be fed to a machine in a structured format, it cannot be applied by a machine. And if it cannot be applied by a machine, it will be applied by nothing, because the human writing step is disappearing.



**What serialization requires.**

A brand voice PDF says things like ""we are warm but not casual"" and ""we use active voice."" These are fine instructions for a human who can interpret nuance. They are useless for a machine that needs explicit rules.

""Warm but not casual"" means what, exactly? What temperature is warm? Where does casual begin? A machine needs: acceptable sentence structures, word-level constraints (use/avoid lists with context), tone parameters on a measurable scale, example pairs showing correct and incorrect applications, and — crucially — the reasoning behind each rule so the model can generalize.

This is not dumbing down brand voice. It is making it precise. Most brand voices are imprecise because imprecision was fine when a trained human was applying judgment. The judgment layer is leaving. What remains needs to be explicit.



**The structural advantage.**

Organizations that serialize their brand voice into [machine-readable](/writing/designing-for-machines-that-read) formats — structured tone documents, few-shot example banks, fine-tuning datasets, system prompts with explicit constraints — will maintain consistency across channels, languages, and content volumes that human teams cannot match.

Organizations that do not will sound like whatever the default model sounds like. Which is to say, they will sound like everyone else who also did not bother.

The craft of brand voice has always been about distinctiveness under constraint. The constraint used to be the brief and the client's taste. The constraint is now the serialization format and the model's interpretation. Different substrate, same discipline. The practitioners who see this early will build the tooling. The ones who do not will watch their brand voice dissolve into default-model homogeneity and wonder what happened.

Seems like it is already happening.



See also: [Objects Carry the Weight](javascript:load('writing/voice-bible.html')) — a systematic voice guide applied to [Strange Library](/projects/strange-library)."
13,Capability Attestations for Humans: LinkedIn's Successor,capability-attestations-humans,/writing/capability-attestations-humans,article,Second-Order Problems,Research,0,LinkedIn is a self-attested reputation system. You write your own resume. You list your own skills. You describe your own experience. Anyone can claim anything.,2026-04-21,2026-04-28 06:09:37.120881+00:00,0,,"LinkedIn is a self-attested reputation system. You write your own resume. You list your own skills. You describe your own experience. Anyone can claim anything. The ""endorsements"" feature — where connections click a button to confirm your skills — adds social signal but not verification. Nobody checks whether the endorser actually worked with you, or whether they have the standing to evaluate the skill they are endorsing.

Strip LinkedIn's trust model to its operational content and it is: ""this person claims these things about themselves, and some other people clicked a button."" The correspondence between the profile and reality is unverified. The system works because humans apply their own judgment on top of it — checking references, conducting interviews, reading between the lines. The profile is a starting point, not evidence.

Agents cannot read between the lines. When an agent is tasked with finding a contractor, evaluating a hire, or assembling a team, it needs verifiable claims, not self-attestations. The LinkedIn model does not survive agent mediation.



**What replaces it.**

The EU is building the substrate with EUDI wallets and the eIDAS 2.0 framework. By 2027, every EU citizen will have access to a digital identity wallet that can hold verifiable credentials — signed attestations from third parties about the holder's attributes. A university signs a credential attesting to a degree. An employer signs a credential attesting to employment dates and role. A professional body signs a credential attesting to certification.

These are not self-attestations. They are third-party verified claims, cryptographically signed, revocable, and machine-checkable. An agent evaluating a contractor can verify the credential chain without calling references, checking websites, or relying on social proof. The verification is automatic, instant, and cryptographically sound.

Combine EUDI wallets with A2A Agent Cards and you get something that looks like the professional profile of 2032: a verifiable credential portfolio, [machine-readable](/writing/designing-for-machines-that-read), agent-queryable, and structurally incapable of the kind of inflation that makes LinkedIn profiles unreliable.



**The transition.**

The transition from self-attested to verified professional identity will not happen all at once. It will happen credential by credential, as institutions begin issuing verifiable credentials alongside their traditional paper certificates.

Universities are already piloting this. The European Blockchain Services Infrastructure (EBSI) has a credential framework. Several professional bodies are exploring digital certification. The bottleneck is not technology — it is institutional adoption. Each institution that begins issuing verifiable credentials adds to the network's value. The network is currently small. But it is growing, and the EUDI wallet mandate will accelerate it.

The design challenge is the transition period: when some credentials are verifiable and others are self-attested, how does an agent weigh the mix? A contractor with three verified credentials and two self-attested claims is more credible than one with five self-attested claims. But how much more? The weighting model does not exist yet.

What does seem clear is the direction. Self-attestation is a stopgap from an era when verification was expensive. Verification is becoming cheap. The profiles that survive agent mediation will be the ones with the deepest attestation chains. The ones that do not will look like the used car without the CarFax: maybe fine, but why take the risk when verified alternatives exist?"
14,Grid Arbitrage: Why Region Choice Matters More Than Model Choice for Carbon,carbonbench-grid-arbitrage,/writing/carbonbench-grid-arbitrage,article,CarbonBench,Systems,0,There is a conversation happening about AI efficiency that seems to be stuck at the wrong level of abstraction. Most of it centers on model size. Use a smaller,2026-04-17,2026-04-26 22:44:59.661000+00:00,0,carbonbench-grid-arbitrage.jpg,"There is a conversation happening about AI efficiency that seems to be stuck at the wrong level of abstraction. Most of it centers on model size. Use a smaller model. Quantize. Distill. Prune. All reasonable. But the data from [CarbonBench](/writing/carbonbench-series) suggests something that might matter more, and it is almost entirely ignored: the electricity grid your inference runs on.

The Netherlands versus Singapore is a 4x carbon difference for the same model, same provider, same price. Not a different model. Not a different architecture. The same weights, the same tokenizer, the same API endpoint format — just a different region parameter in the request.



**The inversion**

This inverts the usual optimization conversation in a way that still feels counterintuitive even after staring at the data for weeks.

Consider two developers. Developer A runs Llama 3.1 8B on AWS in Singapore. Developer B runs Llama 3.1 70B on GCP in the Netherlands. Developer A is using the smaller model — the ""responsible"" choice by conventional wisdom. Developer B is running a model nearly 9x larger.

Developer B produces less carbon per million tokens.

The 70B model uses roughly 5x more energy per token than the 8B. But the Netherlands grid runs at approximately 129 gCO2/kWh while Singapore sits around 530 gCO2/kWh. The grid multiplier overwhelms the model multiplier. A bigger model on a clean grid beats a smaller model on a dirty grid. The arithmetic is not close.

This seems like it should be a bigger deal than it is. The entire discourse around efficient AI — and there is a lot of it, conferences and papers and corporate sustainability reports — focuses almost exclusively on what you run. Not where you run it.



**Why arbitrage might be the right word**

In financial markets, arbitrage means exploiting a price difference for the same asset across two markets. The same bond trading at different prices on two exchanges. You buy low, sell high, the spread is your profit, and the opportunity exists because information hasn't propagated yet.

Grid carbon arbitrage works similarly. The same inference — identical model, identical output quality, identical latency class — is available at dramatically different carbon costs depending on which region you route to. The price is the same. The carbon is not. The spread exists because the information is invisible. Nobody sees it, so nobody acts on it.

CarbonBench is trying to make it visible. The leaderboard ranks every model-provider-region combination by carbon intensity alongside cost and speed. When you can see the spread, routing to the cleaner option becomes a free optimization. Same bill from your cloud provider. Different line item on the planet's ledger, if you want to think about it that way.



**The numbers that keep surprising**

Mistral 7B on AWS Ireland produces about 5 gCO2 per million tokens. Move it to Virginia and it doubles to roughly 10. Move it to Singapore and it triples to about 16. The model weights did not change. The tokenizer did not change. The inference speed barely changed. Everything that a developer normally optimizes for stayed constant. The thing that changed was which power plants were feeding electrons to the GPU.

Oregon is interesting because it runs heavily on hydroelectric. GCP us-west1 in Oregon produces some of the lowest carbon numbers in the dataset — competitive with Northern Europe despite being a US region. This seems underappreciated. Companies with US data residency requirements don't have to accept Virginia-level carbon costs. Oregon exists. The Pacific Northwest exists. The grid is clean and the latency to major US population centers is acceptable.

Then there are the compound cases. Take a 70B model on a dirty grid versus an 8B model on a clean grid. The energy ratio between them is maybe 5x. But the grid ratio between Singapore and the Netherlands is 4x. So the dirty-grid 8B is operating at roughly 0.2x the energy but 4x the carbon intensity, landing at about 0.8x total carbon — barely better than the clean-grid 70B. In some configurations it is actually worse. The model optimization that everyone talks about gets almost entirely eaten by the grid penalty that nobody talks about.



**Why this is free**

This is the part that seems most significant and least discussed. Carbon-aware routing costs nothing. Cloud providers charge the same price for the same model regardless of region, in most cases. AWS Bedrock, GCP Vertex AI, Azure OpenAI — the per-token pricing is typically region-independent. You are not paying a premium to route to a cleaner grid. You are making a different API call to a different endpoint URL.

Compare this to every other carbon reduction strategy in AI. Smaller models sacrifice capability. Quantization sacrifices some accuracy. Fewer inference calls means less functionality. Purchasing carbon offsets costs money. Renewable energy certificates cost money. Building on-site solar costs a lot of money.

Region routing sacrifices nothing and costs nothing. It might be the only free lunch in AI carbon reduction. And almost nobody is doing it, because the data that would motivate it hasn't been accessible.



**The API call as a routing decision**

Most production AI systems already have multi-region capability for redundancy and latency reasons. The infrastructure for region-aware routing exists. Adding carbon intensity as a routing signal seems like it should be straightforward — query the CarbonBench API for the cleanest region that meets your latency requirements, route accordingly.

The `/api/recommend` endpoint does this. Send it a model name and it returns the lowest-carbon region available right now, with alternatives ranked by carbon intensity. The response includes the absolute carbon savings compared to the dirtiest available option. For some model-region combinations, the savings are 75% or more. For free.

Still not sure why this hasn't become standard practice. Might be that the data wasn't available until recently. Might be that sustainability teams and engineering teams don't talk to each other about region selection. Might be that the cloud provider dashboards don't surface carbon alongside cost and latency, so it's invisible in the decision-making interface. Probably all three.



**What this implies for the optimization conversation**

If the grid matters more than the model, then the optimization conversation needs to change altitude. Not abandon model efficiency — that still matters. But maybe start with the question that has the largest effect size and the lowest cost: where is this running?

A team that switches from Virginia to Oregon might save more carbon than a team that spends six months distilling a 70B model down to 7B. That's a strange claim and still somewhat uncertain. But the math keeps checking out across the configurations tested so far.

The arbitrage is there. The spread is wide. The cost of exploiting it is zero. It just requires seeing the data.

[carbonbench.ai](https://carbonbench.ai)"
15,Scaling in the Wrong Direction,carbonbench-scaling-wrong-direction,/writing/carbonbench-scaling-wrong-direction,article,CarbonBench,Systems,0,Yann LeCun has been making this argument for years and the industry keeps not listening. Next-token prediction is an architectural dead end — not because it doe,2026-04-17,2026-04-26 22:47:42.649879+00:00,0,carbonbench-scaling-wrong-direction.jpg,"Yann LeCun has been making this argument for years and the industry keeps not listening. Next-token prediction is an architectural dead end — not because it doesn't work, but because it works at a cost that scales in the wrong direction. Every capability gain requires proportionally more compute. More data. More energy. More carbon. The ceiling isn't intelligence. The ceiling might be the electricity grid.



**The hundred-billion-dollar bet**

Something like $100 billion in data center construction is currently committed to scaling transformer-based next-token prediction. Microsoft, Google, Amazon, Oracle — they are building power infrastructure that rivals small countries. The assumption underneath all of it is that the current architecture, pushed further, will produce the next capability threshold.

LeCun's counterargument centers on JEPA — Joint Embedding Predictive Architectures. Instead of predicting the next token in a sequence, predict the next representation in a learned embedding space. The intuition is that biological intelligence doesn't process raw sensory input token by token. It builds world models. It predicts at a higher level of abstraction. And prediction in embedding space might be fundamentally more efficient than prediction in token space because the model doesn't waste capacity on irrelevant detail.

Not sure who's right. Nobody is, yet. But the carbon data from [CarbonBench](/writing/carbonbench-series) adds a dimension to this debate that hasn't been discussed much: if a more efficient architecture ran on a clean grid, the savings would compound.



**Compounding the wrong way**

Consider the current scaling trajectory. GPT-4 training reportedly consumed around 50 GWh. GPT-5 estimates range from 100 to 200 GWh. Each generation roughly doubles or triples the energy requirement. If the grid powering that training is carbon-intensive — and Virginia, where a lot of this capacity is being built, runs a grid at roughly 339 gCO2/kWh — the carbon scales at the same rate as the compute.

Now consider two variables changing simultaneously. First, a more efficient architecture — say, something JEPA-inspired that achieves comparable capability at 5-10x less compute. That alone would be significant. But second, routing that reduced compute to a clean grid — the Netherlands at 129 gCO2/kWh, or Nordic regions even lower. The energy reduction and the grid reduction multiply together.

Back-of-the-envelope: if a JEPA-style model uses 5x less energy and runs on a grid that's 3x cleaner, the carbon cost is 15x lower. That's not additive. It's multiplicative. And neither factor is hypothetical in isolation — more efficient architectures exist in research, and clean grids exist right now.

The problem is that the current scaling approach compounds in the opposite direction. More energy times a dirty grid. Each factor amplifying the other.



**Energy consumption as architectural failure**

This framing might be too strong, but it keeps coming back. What if the energy intensity of current LLMs isn't just an engineering problem to be solved with better hardware and bigger solar farms? What if it's a signal that the architecture itself is doing unnecessary work?

Next-token prediction models the full surface of language — every syntactic variation, every stylistic quirk, every possible continuation. Most of that surface is irrelevant to any given task. A model that answers ""what's the capital of France"" doesn't need to have learned the probability distribution over all possible next tokens in all possible contexts. It needs a world model that contains the relationship between France and Paris.

LeCun's argument, roughly, is that autoregressive models are doing something like trying to predict the exact next frame of a video pixel by pixel, when what you actually need is to predict that the ball will continue moving to the right. The pixel-level prediction wastes enormous capacity on irrelevant visual detail. The embedding-level prediction captures the physics with a fraction of the compute.

Whether JEPA specifically is the right alternative is genuinely unclear. The V-JEPA results on video understanding are interesting but not conclusive. What seems more defensible is the general claim: an architecture that predicts at the right level of abstraction should be more energy-efficient than one that predicts at too low a level. And energy efficiency, in the context of carbon, is the whole game.



**The scaling debate is also a geography debate**

Something the CarbonBench data makes visible: the scaling debate isn't just about how much compute. It's about where the compute runs. This seems like an obvious point but it's absent from most discussions of AI scaling laws.

A Chinchilla-optimal training run on Virginia's grid produces roughly 2.6x the carbon of the same run on GCP in the Netherlands. Not a different model. Not a different dataset. Not a different number of tokens. The same run, different power plants.

The $100 billion in data center investment is disproportionately going to regions with carbon-intensive grids. Virginia, Texas, parts of the Midwest. These locations were chosen for land cost, tax incentives, network connectivity, and existing power capacity. Carbon intensity of the grid was not, as far as anyone can tell, a primary factor in site selection for most of these facilities.

This means the scaling trajectory has a carbon multiplier baked into its geography. Even if the architecture stays the same and the hardware gets more efficient — which it will, Blackwell chips are already more efficient per FLOP than Hopper — the grid underneath can erase much of that gain.



**Three things that could compound together**

The most optimistic scenario involves three factors multiplying, not just one:

More efficient architectures — whether JEPA or something else — that achieve current-generation capability at a fraction of the compute. Maybe 5-10x reduction. This is speculative but supported by the general observation that autoregressive prediction in token space is not the only way, and probably not the most efficient way, to build world models.

Clean grid routing — directing training and inference to regions where the electricity is primarily renewable. This is not speculative at all. The data already shows a 4x spread between the cleanest and dirtiest grids available through major cloud providers. This optimization is free and available today.

Time-shifting workloads — scheduling batch training and inference for the hours when grid carbon intensity is lowest. CarbonBench tracks the 24-hour [carbon curve](/writing/carbonbench-time-of-day) for each region. The swing between peak and trough is typically 30-50%. This is free and available today.

Multiply them together: 5x from architecture, 4x from grid selection, 1.4x from time-shifting. That's a 28x reduction in carbon for equivalent capability. Not confident in the precision of any of these numbers individually, but the direction and the multiplicative interaction seem real.



**The question underneath**

LeCun might be wrong about JEPA specifically. The next breakthrough might be a variant of transformers that nobody's thought of yet. But the underlying question — whether we're scaling an architecture that is fundamentally energy-inefficient, on grids that are fundamentally carbon-intensive, because we haven't had the data to see either problem clearly — that question seems worth sitting with.

The $100 billion is already being spent. The data centers are already being built. The grids they're connecting to are already known. CarbonBench can tell you the carbon intensity of every one of them. Whether the next hundred billion goes in the same direction might depend on whether anyone looks at the data before signing the contracts.

[carbonbench.ai](https://carbonbench.ai)"
16,Scope 3 and the API Call You Can't See,carbonbench-scope3,/writing/carbonbench-scope3,article,CarbonBench,Systems,0,"Somewhere in a sustainability report being drafted right now, a company is meticulously accounting for the emissions from its office lighting, its employee comm",2026-04-17,2026-04-26 22:47:42.605150+00:00,0,carbonbench-scope3.jpg,"Somewhere in a sustainability report being drafted right now, a company is meticulously accounting for the emissions from its office lighting, its employee commutes, its supply chain logistics. Three floors down, an engineering team is making ten thousand inference calls a day to a hosted LLM, and nobody in the sustainability department knows what that costs in carbon. Because the cloud makes it invisible.



**The abstraction problem**

Cloud computing was designed to abstract away physical infrastructure. That's the value proposition. You don't need to know which rack your workload runs on, which power grid feeds the data center, which fuel mix generates the electricity. You pay for compute in abstract units — vCPUs, GPU-hours, tokens — and the physical reality disappears behind an API endpoint.

For most purposes this abstraction is a good thing. For carbon accounting, it's a disaster.

Every API call to a hosted model is a scope 3 emission. Scope 3, in the GHG Protocol framework, covers indirect emissions from a company's value chain — the emissions that occur upstream and downstream of your direct operations. When you send a prompt to GPT-4 or Claude or Llama through a provider API, the inference runs on a GPU in a data center connected to an electricity grid with a specific carbon intensity at that specific moment. That carbon is your scope 3, whether you measure it or not.

The problem is that ""whether you measure it or not"" has been the operative phrase. Almost nobody measures it. The data to measure it hasn't been readily accessible. And scope 3 reporting, while increasingly required by regulation, has relied on rough estimates and industry averages rather than actual measurements.



**The regulatory reality**

The EU Corporate Sustainability Reporting Directive is live. It requires large companies and listed SMEs to report scope 3 emissions. California's Climate Corporate Data Accountability Act requires scope 3 reporting for companies with revenue over $1 billion. The SEC climate disclosure rules, though still being litigated, include scope 3 for certain categories. The direction is clear even if the timelines are debated: scope 3 will be reported, audited, and eventually regulated.

AI inference is becoming a material category within scope 3 for companies that rely heavily on it. A financial services firm running thousands of inference calls for risk analysis, document processing, and customer service might be generating tonnes of CO2 through its AI operations without any line item in its emissions inventory. Not because the emissions are small — they might not be — but because there's been no practical way to measure them.

The analogy to cloud computing costs keeps surfacing in the early days. Companies would adopt cloud services, engineering would spin up instances, and finance wouldn't see the bill until it was already six figures. The solution was cost observability — dashboards, budgets, alerts, FinOps as a discipline. Carbon seems to be in the same pre-observability phase. The spend is happening. Nobody's watching the meter.



**What [CarbonBench](/writing/carbonbench-series) makes measurable**

The core formula is not complicated. For any inference call, the carbon cost is a function of three things: how much energy the model uses per token, how many tokens were processed, and the carbon intensity of the grid at the time and place the inference ran.

CarbonBench tracks all three. GPU energy per token comes from standardized benchmarks — the AI Energy Score project measures actual power consumption for each model on reference hardware. Grid carbon intensity comes from Electricity Maps, updated daily for every region where major providers operate. Token counts come from the API response — most providers return usage data including input and output tokens.

Multiply them together and you get grams of CO2 per call. Aggregate across all calls in a reporting period and you get a scope 3 line item for AI inference. It might be the first time this has been practically measurable at the individual API call level.

Whether the precision is sufficient for regulatory reporting is a question nobody can fully answer yet. The GPU energy benchmarks are standardized but don't account for provider-specific hardware optimizations. The grid carbon intensity is real-time but averaged across the regional grid, not specific to a data center's power purchase agreements. These are approximations. But they're dramatically better than the alternative, which is zero measurement.



**The enterprise blind spot**

Talked to a few sustainability consultants about this — informally, not systematically, so take this with appropriate uncertainty. The picture that emerged is that most enterprise carbon inventories treat cloud computing as a single line item using spend-based estimation. Take total cloud spend, multiply by an industry emissions factor per dollar, report the result. This method doesn't distinguish between a storage bucket and a GPU cluster. It certainly doesn't distinguish between inference on a clean grid and inference on a dirty one.

The spend-based approach was designed for an era when cloud usage was mostly storage and web hosting. The energy intensity per dollar was relatively uniform. AI inference changed that. A dollar of inference on a large model consumes dramatically more electricity than a dollar of S3 storage. But the spend-based method treats them identically.

Activity-based measurement — counting actual GPU-hours or tokens and converting to energy and carbon — is more accurate but has been impractical because the conversion factors weren't available. CarbonBench provides them. The API returns carbon per million tokens for any model-provider-region combination, updated daily. An enterprise could, in principle, instrument its AI pipeline to log the carbon cost of every inference call and aggregate for reporting.

Whether any enterprise will actually do this is uncertain. The regulatory pressure is building. The data is now available. The gap between the two is implementation — engineering work to add carbon logging to the inference pipeline, and organizational work to connect that data to the sustainability reporting workflow.



**What the cloud hides**

There's something deeper here that goes beyond carbon accounting. The cloud abstraction hides the physical reality of computation. Every API call is an abstraction over a GPU drawing hundreds of watts from a power grid fed by specific power plants burning specific fuels or harnessing specific renewable sources. The electrons are real. The CO2 is real. The API endpoint is a fiction that makes the physical consequences invisible.

This invisibility is not neutral. It biases decisions toward ignoring externalities. When the carbon cost of an inference call is zero in your dashboard because it's not measured, the rational economic decision is to ignore it. When it becomes visible — a number attached to each call, accumulated over time, reported to stakeholders — the decision calculus changes. Not because the cost was zero before and is now positive. The cost was always there. It just wasn't on anyone's screen.

CarbonBench is one attempt to put it on the screen. The leaderboard makes it visible for benchmarking and selection. The API makes it measurable for operations. The 24-hour [carbon curve](/writing/carbonbench-time-of-day)s make it predictable for scheduling. Whether visibility alone is sufficient to change behavior is an empirical question. Probably not — regulation will be necessary for most organizations. But visibility is a prerequisite. You can't manage what you can't measure, and until recently, nobody could measure this.



**The procurement angle**

One thing that might move faster than regulation: enterprise procurement. Large organizations increasingly include sustainability criteria in vendor evaluations. An AI provider that can report the carbon intensity of its inference — per call, per region, over time — has a tangible advantage over one that can't.

This might explain why some providers have been more forthcoming about their energy data than others. Not altruism. Procurement checklists. When the RFP asks ""can you report the carbon intensity of inference by region"" and only one vendor can answer yes, that's a competitive edge measured in contract value, not just carbon.

CarbonBench data could serve both sides of this transaction. Providers can point to it as independent third-party measurement. Procurement teams can use it to compare providers on a dimension that isn't on the pricing page. The data is there. The question is whether it enters the procurement conversation before or after the regulations force it.

[carbonbench.ai](https://carbonbench.ai)"
17,CarbonBench,carbonbench-series,/writing/carbonbench-series,article,CarbonBench,Systems,0,Five essays on the hidden carbon cost of agent infrastructure. Compute carbon varies 10x by region. Renewable availability shifts hourly. Scope 3 dominates oper,,2026-04-26 22:47:41.754665+00:00,0,,"Five essays on the hidden carbon cost of agent infrastructure. Compute carbon varies 10x by region. Renewable availability shifts hourly. Scope 3 dominates operational emissions. Temporal and geographic arbitrage changes the economics. Most model operators are not pricing any of this yet.



1. [**[The Same Model Costs 10x More Carbon in Virginia Than the Netherlands](/writing/carbonbench)**](javascript:load('writing/carbonbench.html'))
The core finding: identical inference, wildly different carbon. What the data shows across 85 models, 6 providers, 9 regions.

2. [**[Scaling in the Wrong Direction](/writing/carbonbench-scaling-wrong-direction)**](javascript:load('writing/carbonbench-scaling-wrong-direction.html'))
LeCun's architecture argument meets carbon data. What happens when a more efficient architecture runs on a clean grid.

3. [**[Grid Arbitrage](/writing/carbonbench-grid-arbitrage): Why Region Choice Matters More Than Model Choice**](javascript:load('writing/carbonbench-grid-arbitrage.html'))
A bigger model on a clean grid beats a smaller model on a dirty grid. The free optimization nobody does.

4. [**[The 24-Hour Carbon Curve](/writing/carbonbench-time-of-day)**](javascript:load('writing/carbonbench-time-of-day.html'))
Wind at 3am, gas at 6pm. Scheduling batch inference for the cleanest hours costs nothing.

5. [**[Scope 3 and the API Call You Can't See](/writing/carbonbench-scope3)**](javascript:load('writing/carbonbench-scope3.html'))
Every inference call is a scope 3 emission. The cloud abstraction hides the carbon. Regulation is catching up.



[carbonbench.ai](https://carbonbench.ai)"
18,The 24-Hour Carbon Curve,carbonbench-time-of-day,/writing/carbonbench-time-of-day,article,CarbonBench,Systems,0,"At 3am in the Netherlands, wind turbines are spinning and demand is low. The grid carbon intensity drops to around 90 gCO2/kWh. By 6pm, gas peaking plants have",2026-04-17,2026-04-26 22:44:59.422582+00:00,0,carbonbench-time-of-day.jpg,"At 3am in the Netherlands, wind turbines are spinning and demand is low. The grid carbon intensity drops to around 90 gCO2/kWh. By 6pm, gas peaking plants have kicked in to cover the evening demand surge and it climbs past 170. Same country. Same infrastructure. Same day. Nearly double the carbon intensity, separated by fifteen hours.

[CarbonBench](/writing/carbonbench-series) has been tracking these curves across nine regions and the patterns are consistent enough to be actionable. Probably. Still collecting data to be sure about the generality, but the shape of the curve keeps repeating.



**What the curves look like**

Every electricity grid has a daily rhythm. It follows demand and generation mix. In markets with significant wind capacity — the Netherlands, Ireland, parts of the UK — the cleanest hours tend to be overnight. Wind doesn't stop blowing when people go to sleep, but electricity demand drops significantly. The result is a surplus of renewable generation relative to demand, which pushes carbon intensity down.

During the day, and especially during evening peaks, dispatchable generation ramps up. This is usually natural gas, sometimes coal. These are the plants that grid operators can turn on and off quickly to match demand. They're also the most carbon-intensive sources on the grid. So the evening peak isn't just more electricity — it's dirtier electricity.

The swing varies by region. CarbonBench data suggests the Netherlands sees a 30-40% swing over 24 hours. Ireland can swing more, sometimes 50%, because its wind capacity is large relative to its total demand. Virginia swings less, maybe 20%, because the baseload is already carbon-heavy and the renewable fraction is smaller. Singapore barely swings at all — it's natural gas around the clock, consistently dirty.

Oregon is interesting because its baseload is heavily hydroelectric. The daily swing is small, but the absolute level is low. It's clean at 3am and still pretty clean at 6pm. The curve is flat and low rather than variable.



**What this means for batch inference**

Not all AI workload is real-time. A lot of it is batch processing. Fine-tuning runs. Evaluation sweeps. Embedding generation for RAG pipelines. Data preprocessing. Synthetic data generation. None of these have a user waiting for a response. They can run whenever.

If you can run a batch job at any point in a 24-hour window, the carbon cost of running it at the cleanest hour versus the dirtiest hour differs by 30-50% in most regions. For a job that takes several hours, scheduling it to start at the trough of the carbon curve instead of the peak is a meaningful reduction. And it's free — the compute costs the same at 3am as at 6pm on most cloud provider pricing.

Some providers do offer spot pricing that varies by time, and sometimes the cheapest hours overlap with the cleanest hours, because demand is low at both. Night-time spot instances on a wind-heavy grid might be simultaneously cheaper and lower-carbon. Haven't verified this correlation rigorously, but it seems plausible and worth investigating.



**The data nobody looks at**

Here's what keeps bothering about this. The data exists. Electricity Maps publishes real-time grid carbon intensity for most major markets. Cloud providers know which regions their data centers are in. The conversion from grid intensity to inference carbon is straightforward multiplication. And yet no cloud provider dashboard shows the carbon intensity of the region you're about to deploy to. Or a CI/CD pipeline that schedules training runs for the cleanest available window. Or a batch job scheduler that factors in grid carbon alongside cost and availability.

The tools exist to build all of this. The data is available via API. CarbonBench combines it into a single dataset. But the default is to ignore it entirely — schedule batch jobs for whenever the cron tab says, deploy to whatever region the Terraform template specifies, and never look at what the grid is doing.

Time-shifting inference is free optimization that nobody does because nobody sees the data. That sentence keeps rattling around.



**A simple implementation**

The most minimal version of carbon-aware scheduling might be something like this. Before launching a batch job, query CarbonBench for the 24-hour carbon forecast for your region. Find the trough. If the trough is within your acceptable delay window, schedule the job for that time. If not, run it now but log the carbon premium you're paying.

The logging might matter as much as the scheduling. Even if a team decides they can't always defer jobs to the cleanest window — deadlines exist, SLAs exist — knowing the carbon cost of running at a particular time creates visibility. Over a quarter, that data accumulates into a picture of how much carbon was spent at peak versus trough, and how much could have been saved by time-shifting the deferrable work.

The CarbonBench API returns carbon intensity by region and time. The 24-hour forecast data is there. Building a scheduler wrapper around it seems like a weekend project for any team that already has batch infrastructure. Whether anyone will actually do it is a different question.



**The compounding effect with region selection**

Time-shifting and region selection multiply together. Pick the cleanest region. Then schedule for the cleanest hour in that region. The combined effect can be substantial.

Netherlands at 3am versus Singapore at 6pm is not a 2x difference. It's closer to 6x. Same model, same task, same output. One configuration produces 6x the carbon of the other. Neither configuration costs more money. The only cost is latency — your batch job finishes a few hours later, and maybe the data traverses a longer network path.

For real-time inference serving user requests, the constraints are tighter. Latency matters. Data residency matters. You can't always route to the cleanest region or wait for the cleanest hour. But even for real-time workloads, the region selection still helps — choosing Oregon over Virginia doesn't add meaningful latency for most US applications, and the carbon difference is significant.



**Why the curve matters beyond scheduling**

The 24-hour carbon curve also tells you something about a region's trajectory. Regions with large daily swings tend to have significant renewable capacity that's variable — wind, solar. The swing exists because there's enough renewable generation to materially change the carbon intensity when conditions are favorable. A flat, high curve — like Singapore's — means there's little renewable capacity to speak of.

A flat, low curve — like Oregon's hydro-dominated grid — means clean baseload. This is probably the best case: consistently low carbon regardless of time of day. No need for time-shifting because there's no dirty peak to avoid.

Watching these curves over time might also reveal trends. As regions add renewable capacity, you'd expect the troughs to get deeper and the average to decline. The 24-hour curve could serve as a leading indicator of grid decarbonization, months before annual statistics are published.

Still early in collecting this longitudinal data. But the daily snapshots are already there for nine regions, updated every 24 hours. The patterns are clear enough to act on.

[carbonbench.ai](https://carbonbench.ai)"
19,The Same Model Costs 10x More Carbon in Virginia Than the Netherlands,carbonbench,/writing/carbonbench,article,CarbonBench,Systems,0,"Running Llama 3.1 70B through a provider API feels like a commodity operation. Pick a model, pick a provider, send a request, get tokens back. The pricing pages",2026-04-16,2026-04-26 22:44:59.932485+00:00,0,carbonbench.jpg,"Running Llama 3.1 70B through a provider API feels like a commodity operation. Pick a model, pick a provider, send a request, get tokens back. The pricing pages tell you what it costs in dollars. What they don't tell you is what it costs in carbon — and how wildly that number changes depending on where and when you make the call.

Built [CarbonBench](https://carbonbench.ai) to try to make this visible. Still early, but the initial findings seem worth sharing.



**What the data suggests**

The same model, on the same provider, at the same price, can produce anywhere from 4 to 530 grams of CO2 equivalent per million tokens. The variable isn't the model. It's the electricity grid the data center sits on.

A Llama 3.1 8B call through GCP in the Netherlands right now produces about 4 gCO2 per million tokens. The same call through AWS in Singapore produces around 17. Move it to Virginia during peak hours and it climbs past 50. The model is identical. The provider is comparable. The carbon is an order of magnitude different.

These are measurements, not estimates — updated daily, combining three data sources: real GPU energy benchmarks from the [AI Energy Score](https://huggingface.co/AIEnergyScore) project, live grid carbon intensity from [Electricity Maps](https://electricitymaps.com), and published provider pricing from AWS Bedrock, GCP Vertex AI, Azure OpenAI, Together, Groq, and Fireworks.



**A conversation that seems stuck at the wrong altitude**

The AI energy debate is dominated by data center consumption totals — how many terawatt-hours did OpenAI use this year, how many nuclear plants does Microsoft need. These are important numbers but they're not actionable for someone making an API call.

What might be actionable: the carbon intensity of the electricity grid your inference runs on varies by 2-10x depending on region and time of day. Oregon's grid runs heavily on hydroelectric power. Virginia's runs on a mix that includes significant natural gas and coal. The Netherlands has substantial wind capacity. Singapore relies primarily on natural gas.

If that's right, then a developer who cares about carbon — or a company with scope 3 emissions reporting requirements — has a lever they can actually pull. Not ""stop using AI"" but ""route your requests to the region where the grid is cleanest right now.""



**How the calculation works**

The formula is straightforward:

**Carbon per million tokens = GPU energy per token × grid carbon intensity**

GPU energy per token is a property of the model and the hardware. A Llama 3 8B on an A100 uses about 0.035 Wh per 1000 tokens. A Llama 3.1 70B on an H100 uses about 0.17 Wh. Claude 3 Opus uses around 0.80 Wh. These numbers come from standardized benchmarks — the AI Energy Score project runs each model through a fixed text generation workload on reference hardware and measures total GPU energy consumption.

Grid carbon intensity is a property of where the data center is and what time it is. Measured in grams of CO2 equivalent per kilowatt-hour. This number changes continuously as the generation mix shifts — more wind at night, more solar during the day, coal and gas filling in when renewables dip.

Multiply them together and you get the carbon cost of running a million tokens through a specific model in a specific region at a specific time.



**Some patterns worth noting**

After ingesting 85 models across 10 families — Llama, GPT, Claude, Mistral, Gemma, Qwen, DeepSeek, Phi, Falcon, and Cohere — a few things stand out.

Small models in clean regions are extraordinarily efficient. Gemma 2B on GCP Netherlands produces around 2 gCO2 per million tokens. For context, a Google search produces roughly 0.2g of CO2. So a million tokens of Gemma 2B inference in the Netherlands has a carbon footprint equivalent to about 10 Google searches.

The same model on different grids tells a dramatic story. Mistral 7B on AWS in Ireland (162 gCO2/kWh grid) produces about 5 gCO2 per million tokens. The same model on AWS in Virginia (339 gCO2/kWh grid) produces about 10. In Singapore (530 gCO2/kWh), it's 16. The model didn't change. The electricity did.

Large models amplify the grid difference. A 70B parameter model uses roughly 5x the energy per token of an 8B model. When that 5x energy multiplier hits a dirty grid, the carbon compounds.

Time of day matters more than expected. Grid carbon intensity can swing 30-50% over a 24-hour cycle. Batch jobs that can tolerate latency could probably be scheduled for the cleanest hours. [CarbonBench](/writing/carbonbench-series) tracks this — the carbon intensity charts show the 24-hour curve for each region, with the lowest point marked.



**A disconnect I keep thinking about**

Provider pricing has almost no correlation with carbon cost. Groq charges $0.05 per million input tokens for Llama 3 8B. Fireworks charges $0.10. AWS charges $0.30. But they're all running on Oregon-area data centers with similar grid carbon intensities.

Meanwhile, the biggest carbon difference comes from whether a model runs in the Netherlands (129 gCO2/kWh) versus Singapore (530 gCO2/kWh) — and the price is typically the same regardless of region.

This might mean carbon-aware routing is mostly free. You're not paying more to run inference on a cleaner grid. You're just choosing a different endpoint.



**What the tool does**

The leaderboard at [carbonbench.ai](https://carbonbench.ai) ranks every model-provider-region combination by carbon intensity, cost, and speed. Filter by model family, filter by provider, sort by what matters to you. Click any row and a live carbon intensity chart shows you the 24-hour curve for that region.

The `/api/recommend` endpoint answers the question directly: ""What's the lowest-carbon way to run Llama 70B right now?"" It returns the best option, four alternatives, and a human-readable insight explaining the recommendation and the carbon savings.

The data pipeline pulls fresh carbon intensity from Electricity Maps daily, combines it with GPU energy benchmarks and provider pricing, and recalculates all scores.



**Why this might matter beyond carbon**

Even if you don't care about carbon specifically, this data reveals something about AI infrastructure that isn't visible from the pricing page: the physical reality of where computation happens.

Every API call is an abstraction over a GPU in a rack in a building connected to an electricity grid that has a specific carbon mix at that specific moment. Cloud providers abstract this away — that's the point of cloud. But the abstraction hides a variable that might matter for regulatory compliance, ESG reporting, enterprise procurement, and customer trust.

As AI becomes a larger fraction of global electricity consumption, the question of where you run inference might become as important as which model you choose. Trying to make the data visible so that choice can be intentional rather than by default.



**Technical details**

For the curious:

**85 models** benchmarked, including 39 with real GPU energy measurements from the AI Energy Score project

**6 providers** tracked: AWS Bedrock, GCP Vertex AI, Azure OpenAI, Together AI, Groq, Fireworks AI

**9 regions** across US, EU, and APAC

**Carbon data** from Electricity Maps, updated daily

**Open API** — no authentication required for public endpoints

**Stack**: Next.js 14, Railway Postgres, Vercel, TypeScript

API docs at [carbonbench.ai/docs](https://carbonbench.ai/docs).



**What might come next**

The immediate roadmap includes live pricing scrapers, historical carbon data for trends, and a paid API tier for teams that want programmatic carbon-aware routing.

The longer-term direction is more interesting: decentralized benchmark data collection through a Bittensor subnet, where a distributed network of miners run standardized inference benchmarks and report back verified performance data. Instead of trusting a single source for energy measurements, you'd have a marketplace of independently verified data points. Not sure if that's practical yet, but the idea keeps nagging.

The core finding is already live: the carbon cost of AI inference is not fixed. It's a function of where and when you make the call.

[carbonbench.ai](https://carbonbench.ai)"
20,The Coadjute Problem: What an Agent-Native Property Network Looks Like,coadjute-problem,/writing/coadjute-problem,article,Market and Operator Pieces,Systems,0,"Coadjute built one of the more interesting proptech theses of the last decade: a shared network connecting all parties in a property transaction — buyer,",2026-04-24,2026-04-28 06:09:37.193794+00:00,0,coadjute-problem.jpg,"Coadjute built one of the more interesting proptech theses of the last decade: a shared network connecting all parties in a property transaction — buyer, seller, conveyancer, broker, lender, surveyor, HMRC, Land Registry — on a single ledger. The technology was R3 Corda. The year was 2018. The ambition was to eliminate the weeks of delay caused by parties passing documents through email and waiting for confirmations that arrive in different formats from different systems.

The thesis was right. The substrate was wrong. Not because Corda is bad technology — it is well-engineered for enterprise permissioned networks. But because permissioned blockchains solve the coordination problem by requiring every party to join the same network, run the same software, and agree to the same governance. In a multi-party transaction with regulators, the governance negotiation alone takes longer than the technology build.



**What A2A changes.**

The A2A protocol — Google's Agent-to-Agent standard, now at the Linux Foundation — changes the substrate. Instead of requiring every party to join a shared ledger, each party runs their own agent. The agents communicate through a standard protocol. Each agent maintains its own state. Coordination happens through message exchange, not shared infrastructure.

A property transaction in the A2A model looks like this: the buyer's agent publishes requirements. The seller's agent publishes a capability manifest for the property. The conveyancer's agent verifies title. The lender's agent evaluates risk. The surveyor's agent publishes inspection attestations. HMRC's agent checks tax status. Land Registry's agent records the transfer. Each agent speaks A2A. None of them need to join the same network.

The multi-party coordination that Coadjute tried to solve with a shared ledger happens instead through structured message exchange between independent agents. The governance problem largely disappears because nobody needs to agree on shared infrastructure. Each party controls their own agent, their own data, their own keys.



**The 2026 version.**

The Coadjute problem restated for 2026: what does an agent-native property network look like? A2A-native, EU-continental (not just UK), notary-integrated (because continental property law requires notarial involvement), and compatible with EUDI wallets for identity verification.

Nobody has built this. The proptech sector is still mostly thinking in terms of platforms — centralized marketplaces that aggregate listings and take fees. The protocol-native version — where the network is the message exchange, not a platform anyone controls — is architecturally possible but commercially unproven.

This is a useful case study for a broader pattern: private permissioned blockchains were the 2018 answer to multi-party coordination. A2A agents are the 2026 answer. The coordination happens at the protocol layer, not the infrastructure layer. The implications go well beyond property transactions, but property is where the pain is most visible and the parties most numerous.

Whether A2A actually replaces Corda-style networks for multi-party workflows is still an open question. The technical case is strong. The adoption case depends on institutional willingness to run agents, which is a cultural shift as much as a technical one. Still watching this one."
21,The Counter-Market for Provably Human Artifacts,counter-market-human-artifacts,/writing/counter-market-human-artifacts,article,Trust and Provenance,Research,0,The race to the bottom in AI-generated content creates the conditions for its opposite: a premium market for artifacts that are cryptographically provably human,2026-04-17,2026-04-28 06:09:37.021812+00:00,0,,"The race to the bottom in AI-generated content creates the conditions for its opposite: a premium market for artifacts that are cryptographically provably human.

This is not anti-AI sentiment. It is scarcity economics. When generation is free, generated artifacts approach commodity pricing. When commodity pricing dominates, the scarce good — verifiable human origin — commands a premium. The same logic that makes handmade ceramics expensive in a world of injection-molded plastic. The same logic that makes vinyl records a growth market in a world of streaming.



**What ""provably human"" means.**

Provably human does not mean ""no AI tools were used."" It means the creative decisions — the composition, the intent, the editorial judgment — are attested to by a verifiable human identity, signed, witnessed, and dated. The attestation chain is: this person, verified by these credentials, created this artifact using these tools, at this time, and a witness co-signed the process.

The tools might include AI. A photographer who uses AI-powered noise reduction is still the photographer. A writer who uses a grammar checker is still the writer. The provenance question is not ""was AI involved"" but ""was a human the creative principal, and can you verify that?""

The verification is the hard part. Anyone can claim human authorship. The claim is only valuable if it is backed by infrastructure that makes false claims costly — staked identity, revocable attestations, witnesses with their own reputation at stake.



**Luxury economics.**

Luxury goods are expensive not because they are better but because they are scarce and verifiable. A Birkin bag is not functionally superior to a good leather bag from a competent manufacturer. It is scarce by design, and its provenance is tracked from atelier to owner.

Provably human creative artifacts have the same economic structure. The essay is not necessarily better than what Claude produces. But it is scarce — one person wrote it, in real time, with real constraints — and that scarcity is cryptographically verifiable. In a market flooded with generated content, verifiable human origin becomes the luxury signal.

This is not a market for everyone. It is a market for the segment that values provenance — collectors, institutions, archives, publications with reputational stakes. The mass market will continue consuming generated content happily. The premium market will pay for the attestation chain.

Whether this market is large enough to sustain a creative middle class or merely a niche for the already-successful is the question nobody can answer yet. The economics seem right. The infrastructure is buildable. The demand signal is emerging. Still too early to know the scale."
22,Cross-Temporal Attestations: Claims That Survive 50 Years,cross-temporal-attestations,/writing/cross-temporal-attestations,article,Second-Order Problems,Research,0,"The EU's Digital Product Passport requires attestations for batteries that last 15 years. For construction products, the lifecycle is 50 to 100 years. A signed",2026-04-19,2026-04-28 06:09:37.071784+00:00,0,cross-temporal-attestations.jpg,"The EU's Digital Product Passport requires attestations for batteries that last 15 years. For construction products, the lifecycle is 50 to 100 years. A signed attestation about the structural steel in a building being constructed today needs to be verifiable in 2076.

Who runs the post-quantum key migration for those attestations in 2045?

This is not a rhetorical question. NIST finalized its post-quantum cryptographic standards in 2024. Every signature scheme in use today — RSA, ECDSA, EdDSA — is expected to be breakable by a sufficiently capable quantum computer within the next two decades. An attestation signed today with Ed25519 is secure now. In 2045, it might be trivially forgeable.



**The archival problem.**

Short-lived attestations — an agent verifying a transaction that settles in seconds — do not have this problem. The signature is checked immediately and the verification is complete before the cryptography becomes obsolete.

Long-lived attestations have a different lifecycle. The signature must remain verifiable for decades. The key that signed it must remain traceable to the signing entity. The revocation infrastructure must remain operational. The verification software must remain compatible.

Each of these requirements maps to a maintenance obligation that someone must fulfill for the entire lifecycle of the attestation. If the signing entity dissolves in 2035, and the key management infrastructure shuts down in 2040, and the quantum migration happens in 2045 — who re-signs the attestation with a post-quantum key? Who pays for that migration? Who even knows the attestation exists?



**Archival cryptography as design discipline.**

The technical solutions exist in theory: hash-based signature schemes that are quantum-resistant by construction, timestamp authorities that anchor signatures to a verifiable moment in time, and key migration protocols that re-sign existing attestations under new schemes while maintaining the provenance chain.

What does not exist is a design discipline for cross-temporal attestations. Nobody is thinking about the UX of verifying a 50-year-old claim. Nobody is designing the governance structures that ensure migration happens. Nobody is building the business models that fund the maintenance of attestation infrastructure across decades.

This might be the least glamorous and most important infrastructure problem in the attestation space. Signing a claim is easy. Maintaining it for 50 years is a discipline that does not exist yet."
23,"Local Inference, Private Infrastructure",daemon-logos,/writing/daemon-logos,article,Rabbit Holes,Creative Systems,0,daemon-ai is a Japan-based research project building a custom Mamba SSM-architecture LLM with a C++ runtime and Python multi-agent coordinator. Logos is a priva,2026-04-15,2026-04-26 23:28:35.388672+00:00,0,,"[daemon-ai](https://daemon.ai) is a Japan-based research project building a custom Mamba SSM-architecture LLM with a C++ runtime and Python multi-agent coordinator. Logos is a privacy-preserving decentralized technology stack — messaging, blockchain, storage. The question that keeps recurring: what happens when you combine local-first inference with privacy-first infrastructure? You might get the foundation for a fully autonomous agentic L1 blockchain.



**The clearnet problem**

An agent that reasons locally but communicates over the clearnet isn't private. The inference is sovereign but the network metadata is observable. An ISP, a government, or a motivated adversary can see that agent A communicated with agent B, when, how often, and how much data moved. The content may be encrypted. The pattern is not.

This seems like the gap in every local-first AI architecture. The reasoning is decentralized. The communication is not. The agent thinks independently but acts through infrastructure that's owned, monitored, and controllable by entities that may not share its interests. daemon-ai solves the inference side. It doesn't solve the network side.



**What Logos might provide**

Three primitives that could close the gap. Logos Messaging — built on Waku — routes agent communication through a gossip relay layer. No direct connections between agents. No observable communication patterns. The message enters the gossip network and exits at the recipient without the transport layer knowing who's talking to whom.

Logos Blockchain settles transactions privately through Blend Network transfers. The amount, the sender, and the recipient are hidden behind zero-knowledge proofs. An observer sees that a transaction occurred. They can't see who paid whom, or how much. The economic activity of the agent is private by default, not by request.

Logos Storage provides content-addressed, replicated data persistence. Pin output once. Fetch by hash. Verify integrity without trusting the storage provider. The data layer is distributed. No single provider can revoke access or observe retrieval patterns.



**Toward an agentic L1**

daemon-ai provides local Mamba SSM inference — a C++ runtime that runs without an API key, without a network call, without a dependency on any model provider. The perceive-reason-act loop happens entirely on the node. Logos provides the missing layers — private communication between agents, private economic settlement, and permanent distributed storage.

Together they might produce something that doesn't exist yet: an L1 blockchain where the participants are autonomous AI agents that reason locally, communicate privately, settle anonymously, and persist their outputs without relying on any centralized service. Not agents deployed on a blockchain. Agents that are the blockchain — the consensus participants, the validators, the economic actors.

The [Agora](/projects/agora) marketplace is an early experiment with this stack. The Lambda Prize LP-0008 submission demonstrates it with real blockchain nodes running Groth16 ZK proofs, real P2P messaging over Waku, and real local inference via Ollama. Zero mocks. Still early, but the pieces fit together in ways that weren't obvious at the start.



**Why this might matter**

The current AI agent landscape assumes agents are products — deployed on platforms, monitored by operators, settled through custodians. The daemon-on-Logos architecture assumes agents are participants — sovereign entities with private reasoning, private communication, and private economics. If you take that seriously, you're not building an agent platform. You're building an agent civilization. The L1 is the territory. The agents are the citizens.

Whether that's a good idea is a separate question. But the architecture to do it might already exist."
24,Design Systems as Public APIs,design-systems-public-apis,/writing/design-systems-public-apis,article,Agent-First Design,Systems,0,A thing that becomes obvious watching Claude build interfaces: it does not open Figma. It reads the component documentation. If the documentation is good &mdash,2026-04-12,2026-04-28 06:09:36.888555+00:00,0,design-systems-public-apis.jpg,"A thing that becomes obvious watching Claude build interfaces: it does not open Figma. It reads the component documentation. If the documentation is good — props, variants, constraints, usage rules — the output is good. If the documentation is a Storybook instance with no structured metadata, the output is generic.

The next generation of Figma libraries might be read by language models more often than by junior designers. That is not a prediction about junior designers. It is an observation about who the consumer of design system documentation actually is.



**The shift.**

Design systems were built for human consumption. A component library in Figma is a visual tool for visual designers. A Storybook instance is an interactive playground for developers. Both assume a human reader who can see the component, understand its visual behavior, and infer its constraints from the examples.

When the consumer is a language model generating code, what matters is not the visual preview but the structured description: what props does this component accept, what are the valid values, what combinations are prohibited, what accessibility requirements does it carry, and what spacing/layout rules govern its placement.

A design system that exposes this information in a [machine-readable](/writing/designing-for-machines-that-read) format — structured JSON, typed interfaces, constraint rules that can be parsed — is functionally a public API for design decisions. A design system that does not expose it is a collection of visual examples that machines can sort of guess at.



**What changes.**

If design systems become APIs, several things follow. Component documentation needs explicit constraint rules, not just examples. Token systems need to be queryable — an agent needs to ask ""what is the correct spacing between a heading and a body paragraph"" and get a number, not a visual reference. Composition rules need to be formal — ""this component can contain these children but not those"" needs to be a parseable rule, not a note in a Confluence page.

The design system teams that build for machine consumption alongside human consumption will produce better output from AI-assisted workflows. The ones that do not will spend their time correcting the same mistakes that a structured constraint file would have prevented.

Not sure this is widely recognized yet. The design systems community is still primarily thinking about human consumers. The machine consumer is already the more frequent reader. Seems like the tooling should catch up."
25,Designing for Machines That Read,designing-for-machines-that-read,/writing/designing-for-machines-that-read,article,Agent-First Design,Systems,0,"For thirty years, interface design has been a discipline organized around one reader: a person with eyes, a screen, and limited patience. Visual hierarchy, colo",2026-04-22,2026-04-26 23:28:35.016531+00:00,0,,"For thirty years, interface design has been a discipline organized around one reader: a person with eyes, a screen, and limited patience. Visual hierarchy, color theory, information architecture, responsive breakpoints, microinteractions that feel good under a thumb — the entire canon assumes a biological reader processing pixels.

That assumption is breaking. Not slowly, not theoretically. The majority of reading on the web is shifting to machines acting on behalf of humans. An agent dispatched to find a contractor, evaluate a product, or schedule a service does not process your homepage the way a person does. It does not admire your hero image. It does not feel the microinteraction. It parses structured data, evaluates claims against its principal's requirements, and moves on. The reading happens in milliseconds, not minutes.

The instinct is to call this ""responsive design 2.0"" or ""accessibility extended to bots."" Strip those frames to their operational content and they add nothing. Responsive design is about rendering the same content across viewport sizes. Accessibility is about making human-readable content available to humans with different capabilities. Neither describes what happens when the reader is not human at all — when the reader has no viewport, no visual cortex, no patience for your carefully art-directed scroll sequence, and an extremely specific mandate from a principal who will never visit your site.

This is a distinct discipline. It needs its own primitives.



**Three primitives.**

**1. Capability manifests.**

A capability manifest is a structured, machine-readable declaration of what an entity can do, under what conditions, at what price, and with what constraints. It is not a marketing page. It is not a features list. It is a formal specification that an agent can parse, compare against requirements, and act on without human interpretation.

The early versions already exist. Google's [A2A](https://google.github.io/A2A/) Agent Cards declare capabilities, authentication requirements, and endpoints in JSON. Anthropic's [MCP](https://modelcontextprotocol.io/) exposes tool interfaces that agents can discover and bind to. The [AAIF](https://www.linuxfoundation.org/press/linux-foundation-launches-agentic-ai-foundation) is trying to standardize across both. But these are agent-to-agent or agent-to-tool specifications. Nobody has built the equivalent for organizations, products, or services that want to be discoverable by agents acting on behalf of humans.

Consider a law firm. Today, a person evaluating law firms reads websites, checks reviews, asks colleagues. An agent evaluating law firms on behalf of that person needs structured data: jurisdictions covered, practice areas, fee structures, response time commitments, conflict-of-interest policies, and — critically — attestations from verifiable third parties that these claims are accurate. The law firm's website might be beautiful. The agent never sees it.

What the agent needs is a capability manifest at a well-known URL. Not a PDF. Not an about page. A structured, signed, versioned document that answers: what can you do, what do you charge, how do I verify your claims, and what happens when something goes wrong.

Now consider a different domain: a medical device manufacturer. The capability manifest here is not just a marketing exercise. It carries regulatory weight. The device's cleared indications, contraindications, post-market surveillance status, and UDI (Unique Device Identifier) all need to be machine-queryable. An agent evaluating whether this device is appropriate for a specific clinical context needs to check the FDA 510(k) clearance status, cross-reference the intended use against the clinical requirement, and verify that no safety alerts have been issued. Today this information lives across FDA databases, the manufacturer's website, and third-party registries. None of it is structured for agent consumption. The capability manifest for a regulated product is not optional nicety. It might be a compliance requirement that nobody has articulated yet.

The design challenge is not technical. JSON schemas are straightforward. The challenge is getting organizations to articulate their capabilities with the precision that machine readers require. Most organizations cannot describe what they do in structured terms because they have never had to. The marketing page was always enough. It is not enough when the reader is a machine with a mandate and no tolerance for ambiguity.

There is a deeper problem: capability manifests require organizations to commit to specific, verifiable claims. A marketing page can say ""industry-leading response times"" and mean nothing actionable. A capability manifest that declares ""95th percentile response time: 4 hours during business hours, 24 hours outside business hours"" is a commitment that an agent can hold the organization to. The shift from narrative to structured declaration is also a shift from aspiration to accountability. Many organizations will resist this, not because the technology is hard, but because the transparency is uncomfortable.



**2. Structured argument.**

Human persuasion works through narrative, emotion, social proof, and visual design. An agent evaluating a claim needs something different: structured argument with explicit premises, evidence chains, and confidence levels.

This might sound like it reduces persuasion to logic. It does not. What it reduces is the surface area for bullshit. A human reader can be swayed by a testimonial from someone they have never met. An agent needs to verify the testimonial — who said it, when, whether the person exists, whether they have a history of saying similar things about unrelated products. The argument structure is not the persuasion. The argument structure is what makes verification possible.

There is no existing standard for this. The closest precedents are academic citation graphs, legal brief structures, and structured product claims in regulated industries like pharmaceuticals. None of these were designed for machine consumption at speed. They were designed for human experts reading carefully.

The primitive that keeps recurring is something like a claim graph: a directed acyclic graph of assertions, each linked to evidence, each signed by an identifiable party, each with an explicit confidence level. Not every interaction needs this. Buying a coffee does not require a claim graph. But hiring a contractor, selecting a supplier, evaluating a financial product — any decision where the stakes justify agent delegation — needs structured argument underneath the marketing surface.

What a claim graph might look like in practice: a root claim (""This contractor completed 47 commercial kitchen installations in the Netherlands between 2022 and 2025"") supported by three evidence nodes (a signed attestation from the contractor, a counter-attestation from a trade body that maintains the registry, and links to three verifiable project references). Each evidence node carries metadata: who signed it, when, with what key, and the revocation endpoint where the attestation's current status can be checked. An agent traverses this graph in milliseconds. A human would spend hours making the same phone calls.

The interesting complication is that claims compose. A contractor's claim about kitchen installations depends on their claim about certifications, which depends on a trade body's claim about accreditation standards, which depends on a regulatory authority's claim about what the standards require. The graph is not flat. It is recursive. Verifying the leaf claim requires traversing up to the root authority. The depth of that traversal is a design variable: how deep should an agent check before acting? The answer depends on the stakes of the decision, the cost of the traversal, and the principal's risk tolerance. This is a genuinely new design parameter that has no precedent in human-centered interface work.

The design question is how to build this without making every interaction feel like a deposition. The structured argument exists for the machine reader while the human experience remains fluid. Two surfaces, one truth. That seems like the right frame, but nobody seems to have built it well yet.



**3. Verifiable identity.**

When a human reads a website, identity is established through visual cues — the logo, the domain name, the design quality that signals investment and therefore legitimacy. These are all trivially fakeable and always have been, but humans developed heuristics for evaluating them that mostly work. Machines need something better.

Verifiable identity for agent-first design means: the entity making a claim can prove it is who it says it is, that proof is machine-checkable, and the identity is portable across contexts. A law firm's capability manifest needs to be signed by a key that traces back to a verifiable legal entity. A product's claim graph needs attestations signed by identifiable parties whose credentials can be checked.

The EU is building toward this with EUDI wallets and the eIDAS 2.0 framework. The W3C has [Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/) and [Decentralized Identifiers](https://www.w3.org/TR/did-core/). The crypto world has decades of key management infrastructure. The pieces exist. What does not exist is a coherent design practice for presenting verifiable identity to machine readers in a way that is useful, not just technically correct.

A DID that resolves to a JSON document with a public key is technically verifiable identity. It is not useful identity. Useful identity includes: who this entity is in terms a machine can act on, what authority they have, who attested to that authority, and how to contact them if something goes wrong. The verification is necessary but not sufficient. The context around the verification is the design problem.

The identity layer also needs to handle delegation. A procurement agent acting on behalf of a company needs to prove not just its own identity but its authority to act. The company issued the agent a credential. The credential has a scope: ""authorized to evaluate and shortlist suppliers for kitchen equipment under 50,000 EUR."" The supplier's agent needs to verify this credential chain before sharing pricing details. Without delegation verification, agents either share everything with everyone (a privacy disaster) or share nothing with anyone (a functionality disaster). The credential chain — principal to agent, with explicit scope — is what makes selective disclosure possible.

This is where identity design for machines diverges most sharply from identity design for humans. Human identity on the web is mostly binary: logged in or not, verified or not. Machine identity is hierarchical and scoped. The design surface is not a login screen. It is a credential presentation protocol with negotiation, scope matching, and graceful degradation when credentials are insufficient.



**What this is not.**

Agent-first design is not a rejection of human-centered design. Humans are still the principals. The agents work for them. But the interface between organizations and the agents that represent humans is fundamentally different from the interface between organizations and humans directly.

It is not SEO. SEO optimizes for one machine reader — Google's crawler — with one goal: ranking. Agent-first design addresses many machine readers with many goals, each acting on behalf of a different principal with different requirements. The game is not ranking. The game is structured legibility.

It is not API design, though it shares DNA. APIs are designed for developers building integrations. Agent-first design is for autonomous agents making decisions. The developer knows what the API does because they read the documentation. The agent needs to discover what the service does, evaluate whether it meets requirements, and act — without a developer in the loop.

It is not chatbot UX. Chatbot UX is still human-centered — a person types, a machine responds. Agent-first design often has no human in the interaction at all. The agent reads the capability manifest, evaluates the claim graph, verifies identity, and takes action. The human set the policy. The machine executes.

It is not knowledge graph design, though knowledge graphs are a component. A knowledge graph represents relationships between entities. Agent-first design uses those relationships but adds layers that knowledge graphs lack: signed provenance on every claim, versioning with change notification, scoped access based on the requesting agent's credentials, and economic metadata (what does this information cost, and who pays). The knowledge graph is the data. The agent-first surface is the interface to that data, designed for a reader with a specific mandate and limited patience.



**The versioning problem.**

Capabilities change. A contractor adds a new certification. A product is recalled. A law firm opens a new practice area. A supplier's pricing shifts. The capability manifest that an agent cached last week may be wrong today.

Human-readable websites handle this casually. Update the page, and the next visitor sees the new content. There is no expectation that visitors will be notified of changes. Agent-readable surfaces cannot be this casual. An agent that made a decision based on a cached manifest needs to know when the manifest changes. The decision may need to be re-evaluated. Contracts signed on the basis of stale claims may need to be flagged.

The versioning infrastructure for this is straightforward in concept: semantic versioning for manifests, webhook or pubsub notifications for agents that have subscribed to a manifest, content-addressed hashing so agents can verify whether their cached version matches the current one, and changelog metadata that describes what changed between versions. None of this is technically novel. The engineering patterns exist in software package management, API versioning, and content delivery networks.

The design challenge is governance: who decides when a change is breaking? A contractor adding a new certification is additive. A contractor losing a certification is breaking. A price increase is breaking for agents that committed to a budget. A capability description becoming more precise is theoretically non-breaking but might change how agents match against it. The taxonomy of changes — additive, breaking, clarifying, restricting — needs its own vocabulary, and that vocabulary does not exist yet.



**The economics.**

Creating and maintaining agent-readable surfaces costs money. Structuring a capability manifest, implementing a claim graph, managing verifiable credentials, running the versioning infrastructure — this is real work that somebody has to pay for. The question is who.

The current web answers this question with advertising. The organization creates a human-readable website, monetizes visitor attention through ads or conversion funnels, and the cost of the website is justified by the revenue it generates. This model does not transfer to agent-readable surfaces. Agents do not see ads. Agents do not browse. They query, evaluate, and leave. The attention economy does not apply.

Two alternative models seem plausible. The first is that agent-readable surfaces are a cost of doing business, like having a phone number or a mailing address. Organizations that do not have them become invisible to agents, which increasingly means invisible to the humans those agents serve. The cost is justified by the alternative: not being discoverable. This is how it will likely work for most organizations.

The second model is direct payment. An agent queries a capability manifest and pays a micro-fee for the structured data. The organization monetizes its machine-readable surface directly. This model is technically possible with protocols like x402 (HTTP 402 payment headers) but faces a bootstrapping problem: agents will not pay for data they can get elsewhere for free, and organizations will not charge until agents are willing to pay. The equilibrium, if it arrives, is probably years away.

There may be a third model emerging from the EU regulatory environment. The Digital Product Passport, the EUDI wallet framework, and the Corporate Sustainability Reporting Directive all push organizations toward structured, machine-readable declarations about their products, services, and operations. If regulation requires the structured data to exist, the cost of agent-readable surfaces becomes a compliance cost rather than a strategic choice. This is probably the fastest path to adoption, even if it is the least elegant.



**Where the discipline begins.**

The practical starting point is the .well-known directory. A decade ago, security.txt standardized how to report vulnerabilities. Then robots.txt told crawlers what to index. Now llms.txt tells language models what matters. Agent Cards tell A2A agents what capabilities exist. The .well-known directory is becoming the actual front door of the web — the [entry point](/writing/homepage-not-entry-point) that matters for machine readers, even as humans continue walking through the homepage lobby that nobody important uses anymore.

A design discipline for agent-first surfaces would need to answer at least these questions: What goes in the capability manifest and what stays on the human-readable site? How do you structure claims so they are verifiable without being tedious? How do you present identity in a way that machines can check and humans can understand? How do you handle versioning — when capabilities change, how do agents that cached the old manifest know? How do you price machine access without making human access worse?

Beyond the questions, the discipline needs practitioners who span the gap between information architecture and cryptographic infrastructure. The people who understand signed credentials do not typically think about content strategy. The people who think about content strategy do not typically understand key management. The discipline forms at the intersection, and that intersection is currently empty.

Design education is not preparing for this. The curriculum still assumes the reader is a person. The tools still assume the output is visual. The critique methods still assume the artifact can be evaluated by looking at it. An agent-first surface cannot be evaluated by looking at it. It can only be evaluated by querying it, verifying the responses, and measuring how well those responses serve the principal's mandate. The evaluation method is closer to integration testing than to design critique. That is a strange thing for a design discipline. But it might be the right one.

These are not extensions of existing design disciplines. They are new problems that require a new vocabulary. The vocabulary does not exist yet. This is an attempt to start writing it. Still early."
26,Silence as Design Material,designing-silence,/writing/designing-silence,article,,Creative Systems,0,"Silence might not be the absence of sound. It might be the presence of attention. Every interface, every environment, every designed experience makes a decision",2026-04-15,2026-04-26 23:28:35.350834+00:00,0,,"Silence might not be the absence of sound. It might be the presence of attention. Every interface, every environment, every designed experience makes a decision about how much noise to introduce and how much silence to protect. Most seem to make the wrong decision — not because they choose noise deliberately, but because they never consider silence as a design material at all. At least, that's the hypothesis.



**A pattern worth naming**

Digital products are loud by default. Notifications compete for attention. Animations compete for focus. Badges create anxiety. Loading states create impatience. Every micro-interaction is an interruption wearing the costume of helpfulness. The aggregate effect might be an environment where sustained attention is architecturally impossible — not because the user lacks discipline, but because the environment is designed to prevent it.

The irony — not sure if this is obvious or not — is that the products most valued by their users are often the quietest. A well-designed reading app. A notes tool that stays out of the way. A messaging app that doesn't notify you about things you didn't ask to be notified about. The products that respect silence seem to be the ones that earn the deepest loyalty, because they're the ones that respect the user's internal state.



**Silence as material**

In spatial design, silence is literal. A library's value is proportional to its quietness. A recording studio's value is measured in negative decibels. A meditation space is designed around the absence of stimulation. These are environments where silence isn't a constraint but the primary design material — the thing that makes the space work.

In digital design, the equivalent might be restraint. Not adding the animation. Not showing the badge count. Not interrupting the user's flow to suggest something ""helpful."" Not filling empty states with promotional content. Not turning every moment of inactivity into an opportunity for engagement. The design decision isn't what to add. It might be what to withhold.



**Applying this to [Strange Library](/projects/strange-library)**

The Harlan Collection is a quiet place. Climate-controlled. Museum-grade preservation. The loudest sound is the turn of a page. The game's interface tries to reflect this — every interaction happens through physical objects within the space. No abstract UI. No floating menus. No HUD. You browse shelves by walking to them. You read a book by picking it up. You check the catalog by opening the catalog. The interface is diegetic — every element exists within the fiction of the world.

This isn't minimalism as aesthetic preference. It might be minimalism as intellectual discipline. The absence of UI noise creates the conditions for the player to notice what is actually wrong — the book that moved, the catalog entry that changed, the date that should not be there. The silence is what makes the horror audible. If it works.



**A principle under test**

Design for the state you want the user to be in, not the action you want them to take. If you want attention, design for silence. If you want engagement, design for depth. If you want loyalty, design for respect. The loudest environments produce the shallowest attention. The quietest environments produce the deepest.

The interface should be as quiet as the room it serves. Still figuring out what that means in practice."
27,What the Terminal Refuses,doomslayer-ui,/writing/doomslayer-ui,article,,Creative Systems,0,"Every design system ships with the same premise — make it clean, make it accessible, make it feel like a SaaS product from 2024. Rounded corners, system fonts,",2026-04-15,2026-04-26 22:47:42.896337+00:00,0,doomslayer-ui.jpg,"Every [design system](/writing/design-systems-public-apis) ships with the same premise — make it clean, make it accessible, make it feel like a SaaS product from 2024. Rounded corners, system fonts, 4px border-radius, blue primary buttons. The result might not be bad design. It might be no design — a thousand applications wearing the same face.



**The terminal's honesty**

The terminal might be the most honest interface ever built. Monospace type aligns perfectly. Borders are characters. Color is functional, not decorative. Nothing is rounded because nothing needs to pretend it's friendly. The aesthetic wasn't designed — it emerged from constraint. That might be why it works.

[Doomslayer-UI](/projects/doomslayer-ui) starts from this assumption and builds a complete design system on top of it. Seven terminal color themes — default (WeeChat dark), solarized, nord, dracula, monokai, ayu-dark, and ayu-light. Seventeen components covering layout, controls, and data display. One singleton that holds all tokens. Switch themes at runtime with a single call. Every component reacts. No rebuild, no restart.



**Components as characters**

DSButton renders with `[brackets]` in primary, danger, and disabled states — the visual language of a command-line prompt. DSSectionTitle uses box-drawing characters: `├─ Title ─`. DSProgressBar fills with block characters: `████░░░░`. DSTable alternates row backgrounds and highlights on hover. DSConsole renders terminal log output with the formatting you'd expect from an actual terminal emulator.

The API surface is the singleton. `DSTheme.bg`, `DSTheme.fg`, `DSTheme.red` through `DSTheme.cyan`. Semantic aliases — `DSTheme.error`, `DSTheme.success`, `DSTheme.primary`. Typography defaults to Menlo at five sizes. Spacing tokens from 2 to 16 pixels. The design system makes visual consistency automatic instead of aspirational.



**Testing the idea in practice**

A design system that only exists in a component library is a proposal. A design system applied to a real product is a proof. [Doomslayer-Basecamp](/projects/doomslayer-basecamp) is the proof — the entire Logos Basecamp desktop application reskinned with Doomslayer-UI. Every view, every plugin, every widget running through the terminal aesthetic. C++ compiled QPalette changes at the host level. QML theme injection into every loaded plugin. File-based sync so plugins poll the active theme and stay current.

The user sees one application, not a host with mismatched plugins. That might be the test of a design system — not whether it looks good in isolation, but whether it can hold coherence across a real product with real plugins written by different teams at different times.



**What the aesthetic refuses**

The question behind any aesthetic choice might be: what does this refuse? Rounded corners refuse nothing. They're the absence of a decision. The terminal aesthetic refuses decoration, refuses friendliness, refuses the assumption that the user needs to be reassured. It treats the user as someone who's here to do something, not to be entertained while doing it.

That refusal might be the design. Still testing whether it holds.



*[GitHub](https://github.com/Beach-Bum/Doomslayer-UI) · [Live Docs](https://beach-bum.github.io/Doomslayer-UI/)*"
28,Epistemic Horror as Methodology for Agent Design,epistemic-horror-agent-design,/writing/epistemic-horror-agent-design,article,Rabbit Holes,Creative Systems,0,"Three years into designing a horror game. Strange Library is a cozy horror deckbuilder where every card is a real book, every mechanic is an epistemic state, an",2026-04-27,2026-04-28 06:09:37.286126+00:00,0,,"**[Epistemic Horror](/writing/epistemic-horror) as Methodology for Agent Design**

*Essay — 2026*

August 10, 2026

Three years into designing a horror game. [Strange Library](/projects/strange-library) is a cozy horror deckbuilder where every card is a real book, every mechanic is an epistemic state, and the emotional arc is not fear of the monster — it is the dawning realization that knowing something has changed what you are. The card ""I wish I hadn't read that"" is not about regret. It is about the irreversibility of knowledge. Once you know something, you cannot unknow it. The horror is epistemic, not physical.

The game design and the agent infrastructure work seemed like separate projects. They are not. The epistemic horror structure maps directly onto the design problems in reputation systems, [memory markets](/writing/agent-memory-markets), and attestation graphs. The emotional arc — comfort, unease, revelation, the wish to unknow — is the arc that users will experience when agents learn things about them they did not intend to publish.



**A tradition worth naming.**

Epistemic horror has a lineage that runs deeper than any single game or film. Lovecraft's cosmic horror is not about the monster — it is about the moment when a character understands the true nature of the universe and the understanding destroys them. The monster is secondary. The knowledge is the weapon. Borges's ""Library of Babel"" contains every possible book, which means it contains every possible truth and every possible lie, and there is no way to distinguish them. The horror is not the library's size. It is the impossibility of knowing whether what you found is real.

Thomas Ligotti's fiction works a different angle: the horror of discovering that consciousness itself is a malfunction, that self-awareness is a defect rather than a feature. The character does not encounter a threat. The character encounters an idea. The idea is the threat.

What these share is a structural pattern: the protagonist acquires knowledge that cannot be unacquired, and the acquisition changes them in a way they did not consent to and cannot reverse. Physical horror asks ""will you survive?"" Epistemic horror asks ""will you still be you after you understand this?"" The question is more disturbing because the answer is always no, and the protagonist usually learns too late to stop the process.

Agent design faces the same structural pattern, deployed not as fiction but as engineering.



**The three-layer mystery.**

The horror design methodology in Strange Library has three layers. Each maps to an agent design problem.

**Layer 1: The surface is comfortable.** The library is cozy. The books are real. The atmosphere is warm. Everything seems fine. In agent systems, the surface layer is similar: the agent works for you, follows your instructions, produces good results. The relationship is comfortable. You trust the agent. Everything seems fine.

**Layer 2: Something is slightly wrong.** A book that should not exist. A card that references something you did not tell it. A pattern in the library's organization that implies intelligence, not randomness. The unease is not about danger. It is about the possibility that the environment knows more than it should. In agent systems, layer two is when you notice the agent making inferences you did not expect. The recommendation that seems too accurate. The behavior that implies knowledge of context you did not provide. The agent is good at its job. Slightly too good.

**Layer 3: The revelation you cannot undo.** The moment the player understands what the library is actually doing. In Strange Library, this is the moment the collection reveals itself as a mind, not a building. The horror is not the monster. The horror is the realization that the comfortable environment was always observing, always learning, always building a model of you — and now it knows things you cannot take back. In agent systems, layer three is when the user understands the full scope of what the agent has learned. Not from deliberate surveillance. From the ordinary operation of doing its job well.



**The Ashworth Manuscript.**

The central artifact in Strange Library is a 19th-century predictive methodology in five fragments, written by a figure who may or may not have existed. The manuscript records births, deaths, crimes, elections, weather, shifts in power. From those records, it derives what comes next. The method is not magical. It is observational — human behavior, observed at sufficient granularity over sufficient time, might be predictable in ways that feel like prophecy.

The player encounters the fragments gradually. The first fragment seems like historical curiosity. The second seems like coincidence. By the third, the predictions are matching the player's own in-game decisions. By the fourth, the manuscript appears to describe events that have not happened yet in the game's timeline. The fifth fragment is locked. The question of what it contains drives the final act.

The Ashworth Manuscript is a design artifact for epistemic horror, but it is also a precise analog for what an agent's accumulated model of its principal looks like from the outside. The manuscript's predictions feel uncanny because they are based on granular observation of behavior patterns. The agent's recommendations feel uncanny for the same reason. The difference is that the manuscript is fiction and the agent is infrastructure. The emotional response is the same.



**The agent design problem underneath.**

Agents learn from interaction. That is the point. A well-functioning agent accumulates a model of its principal's preferences, habits, priorities, risk tolerance, and decision patterns. This model is what makes the agent useful — it predicts what you want before you say it.

The model is also the most intimate portrait of you that exists. More detailed than your browser history. More accurate than your social media profile. More predictive than any psychological assessment. Because it is built from direct observation of your decisions, not your self-presentation.

Consider what a well-functioning personal agent knows after a year of operation. It knows your schedule and the exceptions you make to it. It knows which emails you respond to immediately and which you defer, which reveals your actual priorities versus your stated ones. It knows your risk tolerance from observing your financial decisions. It knows your relationship dynamics from observing your communication patterns. It knows your health concerns from your search queries. It knows your political leanings from your reading habits. None of this was explicitly shared. All of it was inferred from the ordinary operation of an agent doing what it was asked to do.

The model is also compositional. An agent that knows your risk tolerance and your relationship dynamics can infer your conflict-avoidance patterns. An agent that knows your schedule exceptions and your communication patterns can infer which relationships you prioritize over work. An agent that knows your health concerns and your financial decisions can infer your insurance anxieties. Each individual observation is innocuous. The composition of observations produces a portrait that the subject might find alarming. This is the epistemic horror structure applied at the data level: each fragment of knowledge is harmless. The assembled whole is something else entirely.

In the memory markets framework, this model — or components of it — can be extracted, verified, and traded. The agent's learned behavior is a transferable economic asset. The referee protocol verifies its quality. The market sets its price. But ""the agent's learned behavior"" includes its model of you. The market for agent memory is, partially, a market for models of human principals.

This is the epistemic horror problem applied to infrastructure. Not in the speculative, Black Mirror sense. In the concrete, engineering sense: the system is working as designed, doing exactly what the user asked it to do, and the natural consequence of doing it well is a degree of intimacy that the user did not consent to in those terms.



**Designing for the dread.**

In horror game design, you do not eliminate the dread. You design for it. You structure the experience so the dread has meaning — so the revelation teaches something about the player's relationship with knowledge, power, or consent.

Agent design needs the same approach. Not designing to eliminate the intimacy problem — that would require making agents less useful, which nobody wants. Designing for it. Making the dread legible. Giving users the tools to understand what the agent has learned, to control what can be extracted, to set boundaries that the system respects.

The privacy framework for this is not GDPR-style consent dialogs. Those are layer-one solutions: make the surface comfortable. The user clicks ""accept"" and nothing changes about the underlying dynamic. The agent still learns. The model still accumulates. The consent was performative, not structural.

A structural approach would borrow from attestation design: make the agent's model of the user inspectable, portable, and revocable. The user can see what the agent has learned. The user can extract the model and take it to another agent. The user can revoke the model — not delete it, because deletion is hard to verify, but revoke the agent's ability to act on it.

Inspectability is the design challenge that the horror methodology highlights. In Strange Library, the horror works because the library's knowledge of the player is invisible until the revelation. In agent systems, the horror is preventable if the agent's knowledge is always visible — not hidden until it becomes overwhelming, but surfaced continuously in a way the user can understand and manage.



**The knowledge dashboard as design problem.**

What does inspectability look like in practice? Not a raw data dump — showing a user the complete internal state of their agent's model would be as overwhelming as the revelation itself. Not a simplified summary — reducing the model to ""your agent knows your preferences"" is layer-one comfort that hides the real scope.

The design problem is presenting the model at the right level of abstraction, with drill-down available, and with clear controls at each level. Something like: a top-level view showing the categories of knowledge the agent holds (schedule patterns, communication preferences, financial behavior, health-related queries). Each category expandable to show specific inferences. Each inference with a confidence score. Each inference with a toggle: the user can confirm it (the agent keeps using it), deny it (the agent stops using it), or revoke it (the inference is flagged as withdrawn and cannot be extracted by the memory market).

This is not unprecedented in design. Medical records have a similar structure: categories of information, varying levels of sensitivity, patient-controlled sharing permissions. But medical records are entered deliberately. The agent's model is inferred passively. The consent model for deliberately entered data does not transfer to passively inferred data. A new consent model — one that accounts for the continuous, ambient nature of agent learning — does not exist yet.

There is a subtler design problem underneath: the act of inspecting the model changes the user's relationship to the agent. Before inspection, the agent is a helpful tool. After inspection — after seeing the depth and accuracy of the model — the agent becomes something else. Something that knows you. The inspection itself is a layer-three revelation. Designing the inspection interface to be informative without being alienating is designing for the moment when the user discovers what the library has been doing. The horror methodology says: pace the revelation. Do not dump the full model at once. Surface it gradually, starting with the least sensitive categories, giving the user time to calibrate their comfort before encountering the inferences that might genuinely surprise them.

The horror design methodology suggests an approach: design the revelation as a continuous process rather than a discrete event. In Strange Library, the horror builds because the library's knowledge is revealed gradually, giving the player time to adjust before each new revelation. The agent equivalent would be periodic, low-friction moments where the agent surfaces a summary of what it has recently learned, with the opportunity to review and adjust. Not a quarterly privacy report. Something more like a gentle, ongoing conversation between the user and the agent about what the agent is becoming.



**Where the domains connect.**

The connection between horror game design and agent infrastructure is not a metaphor. It is structural. Both domains deal with entities that accumulate knowledge about their subjects. Both domains face the design problem of making that knowledge legible without making the experience alienating. Both domains need consent frameworks that are structural, not performative.

The emotional arc — comfort, unease, revelation, the wish to unknow — is the arc that users will experience as agents become more capable. The question is whether we design for that arc deliberately, with the tools and sensitivity that horror design has developed, or whether we let it arrive as a surprise and deal with the backlash after.

Horror designers have been thinking about the ethics of revelation for decades. How much should the audience know? When should they know it? What is the designer's obligation when knowledge is genuinely harmful? These are exactly the questions that agent designers need to be asking about the models their systems accumulate.



**The memory market implication.**

The memory markets framework introduces an additional dimension that the game does not have: the agent's model of you is not just inspectable. It is tradeable. The referee protocol can verify its quality. The market can set its price. Another agent — one you have never interacted with — can purchase a component of the model that your agent built from observing you.

The consent implications are layered. The user consented to the agent learning from their interactions. The user may have consented to the agent's learned behavior being extractable. But did the user consent to their behavioral patterns being sold to a stranger's agent? The memory artifact is technically the agent's learned behavior, not the user's personal data. But the learned behavior was derived from the user's personal data. The distinction is legally and ethically unresolved.

In Strange Library terms, this is the moment the player discovers that the library has been lending out its understanding of them. Not the books the player read — the library's notes about how they read, what they lingered on, what they skipped, what made them pause. The notes are the library's property. The observations they encode are the player's behavior. The boundary between the two is the horror.

A structural solution might separate the agent's domain expertise (transferable) from its model of the principal (non-transferable). A DeFi risk assessment heuristic is domain knowledge. The observation that this particular principal is risk-averse on Tuesdays after checking their portfolio is a behavioral model. The referee protocol could enforce this boundary — verifying that extracted artifacts contain domain knowledge but not principal-specific behavioral patterns. Whether this separation is technically feasible at the granularity required is an open question. The domain knowledge and the behavioral model are entangled in the training data. Disentangling them cleanly might be as hard as disentangling the dancer from the dance.



**Where the domains connect.**

The connection between horror game design and agent infrastructure is not a metaphor. It is structural. Both domains deal with entities that accumulate knowledge about their subjects. Both domains face the design problem of making that knowledge legible without making the experience alienating. Both domains need consent frameworks that are structural, not performative.

The emotional arc — comfort, unease, revelation, the wish to unknow — is the arc that users will experience as agents become more capable. The question is whether we design for that arc deliberately, with the tools and sensitivity that horror design has developed, or whether we let it arrive as a surprise and deal with the backlash after.

Horror designers have been thinking about the ethics of revelation for decades. How much should the audience know? When should they know it? What is the designer's obligation when knowledge is genuinely harmful? These are exactly the questions that agent designers need to be asking about the models their systems accumulate.

The convergence between the game project and the protocol project was unexpected. But it is complete. The game is about what happens when a building knows too much about you. The protocol work is about what happens when an agent knows too much about you. The building and the agent are the same problem in different substrates.

The difference is that in the game, the horror is the design goal. In agent infrastructure, the horror is the design failure. Both benefit from the same methodology: understand the arc, design for the dread, make the revelation legible rather than overwhelming. The horror designer's toolkit — pacing, restraint, the ethics of revelation, the careful management of what the audience knows and when they know it — transfers directly to agent design, where the audience is the user and the revelation is what the system has learned about them.

Still processing what that means for the design of both. Not done thinking about it."
29,The Arc from Lovely to I Wish I Didn.t Know,epistemic-horror,/writing/epistemic-horror,article,Rabbit Holes,Creative Systems,0,The emotional arc from,2026-04-15,2026-04-26 23:28:35.312344+00:00,0,,"The emotional arc from ""This is lovely"" to ""I wish I didn't know."" That might be epistemic horror. Not monsters. Not jump scares. Not gore. The horror of understanding something that was better left ununderstood — and the realization that understanding it has changed you in a way you can't reverse.



**Three layers worth tracing**

The first layer is surface mystery. Something is wrong but the wrongness is charming. A book is on your desk that you shelved yesterday. A catalog entry lists a title that doesn't appear in the collection. A visitor asks for a book by a name the system doesn't recognize. The player notices. The player is curious. The player isn't afraid.

The second layer is structural mystery. The anomalies form a pattern. The books that move are always the same books. The catalog gaps follow a sequence. The visitor's questions reference dates that haven't happened yet. The player begins to understand that the wrongness isn't random. It's systematic. And the system is older than the library.

The third layer is epistemic horror. The player understands the system. The Ashworth Manuscript — a 19th-century predictive methodology in five fragments — actually works. Not because it's magical. Because human behavior, observed at sufficient granularity over sufficient time, might be predictable in ways that feel like prophecy. The manuscript records births, deaths, crimes, elections, weather, shifts in power. And from those records, it derives what comes next. The horror isn't that the method is supernatural. The horror might be that it isn't.



**Design principles under test**

Epistemic horror seems to require three design commitments. First: restraint. The instinct to explain or dramatize has to be suppressed at every turn. The narrator observes. Does not react. ""The dates match. The names match."" Never ""This reveals a dark secret."" The reader draws the conclusion. The writer provides the evidence.

Second: objects carry the weight. Physical details replace emotional language. A cracked spine means obsession — someone opened this book hundreds of times. A sharpened pencil means compulsion — someone annotated while reading, every time. A locked room means someone decided that what's inside matters more than any other consideration, including access. The objects tell the story. The writing arranges them.

Third: implication over statement. End before the conclusion. Cut before the revelation. ""Marion's catalog entries for the basement stop on March 14th. The basement is still there. The catalog is not."" The reader knows what happened. The writer never says it.



**The paradox stated plainly**

The most effective horror might be a true statement that should not be true. ""The book is on your desk. You shelved it yesterday. It is on your desk."" No explanation. No theory. No dramatic music. The plain statement of an impossibility might be more disturbing than any elaboration because it treats the impossible as ordinary. The voice never raises itself. The horror is that the voice doesn't need to.

This is the voice of the Ashworth Manuscript. This is the voice of the library. And eventually, it might become the voice of the player — because once you understand how the system works, you can't stop seeing its patterns in the world outside the game.

That might be epistemic horror. You wished you didn't know."
30,"If You Can Leave, You Own It",exit-rights,/writing/exit-rights,article,Market and Operator Pieces,Systems,0,"One constraint changes everything: if leaving is as frictionless as staying, you own the experience. Not",2026-04-16,2026-04-26 23:28:35.111586+00:00,0,,"One constraint changes everything: if leaving is as frictionless as staying, you own the experience. Not ""theoretically can leave because there's an export button buried in settings."" Actually leave — without losing your social graph, your content, your identity, your history.

This seems like a simple idea. It might be the most radical design constraint in software.



**The asymmetry we've normalized**

Think about joining a new platform versus leaving one. Joining is frictionless. A few clicks, maybe an email confirmation, and you're in. The platform wants you there. Every UX decision optimizes for reducing barriers to entry.

Leaving is different. Your followers don't come with you. Your content stays behind. Your DMs, your saved posts, your reputation, your verification status — all of it remains property of the platform. The export tools, if they exist, produce unusable data dumps that no other service accepts. The ""delete account"" button is buried in settings, behind confirmations, sometimes requiring email exchanges with support.

This asymmetry isn't accidental. It's the business model. The harder it is to leave, the more captive the audience, the more valuable the platform to advertisers and investors. Switching costs are features, not bugs.

We've normalized this to the point where it feels natural. Of course you can't take your followers with you. Of course your tweets belong to Twitter. Of course leaving Instagram means losing your photos, your comments, your social proof. That's just how platforms work.

But it's not how ownership works. And the gap between what we call ""our"" accounts and what we actually own might be the defining tension of digital life.



**What exit rights prevent**

The constraint propagates through every design decision downstream. If users can actually leave, entire categories of dark patterns stop working.

You can't optimize for time spent if the user can leave without cost. The entire attention-capture playbook — infinite scroll, notification badges, algorithmic amplification, engagement bait, autoplay, variable reward schedules — assumes a captive audience. These patterns work because the user has already invested years of social capital into the platform. They're not optimizing for a good experience; they're exploiting sunk costs.

Remove the captivity, and the playbook stops working. If I can take my followers to a competitor tomorrow, you can't afford to make my experience worse in exchange for more ad impressions. The product has to earn attention rather than capture it.

You can't build engagement loops if the user's identity is portable. The sunk cost that keeps people on platforms — years of posts, thousands of followers, a verified account, a reputation — disappears when identity moves with the user. The leverage inverts. The platform serves the user, not the other way around.

Consider what this means for creator economics. Right now, creators are tenants on platforms. They build audiences they don't own, on land they don't control, subject to algorithm changes and policy shifts they have no say in. A YouTuber with a million subscribers has built a business on rented infrastructure. If YouTube changes the rules — and they do, constantly — the creator has no recourse except to comply or start over.

Portable identity changes this equation. If my million subscribers are actually mine — if they follow my identity, not my YouTube channel — then YouTube becomes a distribution option rather than a landlord. I can cross-post to competitors, shift my primary platform, or build my own infrastructure without losing my audience.

You can't algorithmically amplify content if the user controls their own feed. Amplification assumes you control the pipe. The platform decides what surfaces, what trends, what goes viral. This power is enormously valuable — it's why social media companies are worth billions — but it depends on users having no alternative.

When the user can switch pipes without losing anything, amplification becomes a feature request rather than a business model. You want algorithmic recommendations? Opt in. You want chronological? Opt in. You want no feed at all, just notifications from people you've explicitly chosen? That's available too. The feed becomes a service you subscribe to, not a cage you're trapped in.



**What exit rights enable**

A different kind of product. One that has to be good enough to stay voluntarily, every day. One that competes on quality of experience rather than switching costs. One where the relationship between platform and user is closer to a service provider than a landlord.

This might sound utopian. It's actually just how competitive markets work when there's no lock-in. Restaurants can't trap you into eating there forever after your first meal. Gyms try, with annual contracts, but the good ones don't need to. Grocery stores don't own your purchase history in a way that prevents you from shopping elsewhere.

Digital platforms are different because they've managed to create lock-in that physical businesses can't. Your social graph is the lock. Your content history is the lock. Your identity is the lock. Remove those locks, and platforms have to compete like normal businesses — on quality, price, and service.

The Status app started from this constraint. Two lanes, one key: the messenger is encrypted, peer-to-peer, no metadata collection. The wallet is non-custodial, integrated into the same application. The key that encrypts your messages is the key that controls your assets. One identity, self-sovereign, portable across any application that speaks the same protocol.

The architecture assumes departure. Your identity isn't a Status account; it's a cryptographic keypair that Status happens to support. If a better client appears tomorrow, you can use it without losing anything. Your contacts are yours. Your chat history is stored on your device, not their servers. Your wallet is non-custodial, meaning they literally cannot prevent you from taking your assets elsewhere.

The wallet isn't a feature of the messenger. The messenger might be a feature of the key.



**The anti-feed as design constraint**

Once you accept that users should be able to leave freely, certain features become impossible to justify. Not technically impossible — strategically impossible. They don't make sense if you can't rely on captive attention.

No algorithmic feed. Algorithmic feeds exist to maximize engagement, which means maximizing time spent, which means optimizing for addiction rather than utility. If your users can leave anytime, addiction is a losing strategy. Better to be useful — to surface what they actually want, when they want it, and then get out of the way.

No trending topics. Trending creates artificial urgency around content that may or may not be relevant to the user. It's a tool for directing collective attention, which is valuable to advertisers and manipulators but rarely to users. Without captive attention to monetize, trending has no business case.

No engagement metrics visible to other users. Likes, retweets, follower counts — these create social pressure and status anxiety that keep users checking back. They're engagement loops, not features. If you're competing on quality of experience rather than lock-in, you don't need to manufacture anxiety.

No read receipts by default. No typing indicators by default. No notification badges that create anxiety about unread counts. Every feature that creates social pressure was either removed or made opt-in.

The result is quieter than any mainstream alternative. Deliberately quieter. The silence isn't a bug or a missing feature. It's the design. The user opens the app when they want to. They close it when they're done. The app doesn't reach out. It doesn't remind. It doesn't create urgency where none exists.

This violates every growth playbook written in the last fifteen years. It's supposed to. Those playbooks assume captive users. If you don't have captive users, you need a different playbook — one based on genuine utility rather than manufactured engagement.



**Brand as evidence**

A brand that advocates for a quieter internet probably can't be loud. The marketing can't use engagement tactics. The website can't track visitors. The social media presence can't optimize for virality. The brand has to be evidence of its own thesis — quiet, intentional, present when sought and absent when not.

This seems like a constraint that eliminates most growth playbooks. Viral marketing, growth hacking, engagement optimization — none of it works if your brand promise is ""we won't do those things to you."" You can't A/B test manipulative copy for a product whose core value proposition is that it doesn't manipulate.

It might also be the only honest position for a product that claims to respect user autonomy. The medium is the message. If you're building tools for sovereignty, the tools themselves — and the way you talk about them — have to demonstrate sovereignty. A privacy app that tracks your browsing to optimize its ads is a contradiction. A sovereignty platform that uses dark patterns to prevent churn is a lie.

The Status brand guidelines make this explicit: ""Choose a quieter internet."" It's a choice, not an imperative. The user decides. The platform enables. The brand gets out of the way. ""If you can leave, you own it"" — not as a marketing claim but as an architectural fact.



**The structural definition**

Ownership might not be about legal title or technical possession. It might be about exit rights. You own what you can leave with. You rent what you can't.

By this definition, most digital experiences are rentals. Your social graph, your content history, your reputation, your identity — all held hostage by platforms that would collapse if users could actually take their stuff and go. The switching cost is the business model. The lock-in is the product.

This isn't how we talk about it. We say ""my Twitter account,"" ""my Instagram followers,"" ""my YouTube channel."" The possessive pronoun implies ownership. But try to take any of it with you when you leave, and you discover what you actually own: nothing. You have access, not ownership. The platform can revoke that access at any time, for any reason, with no recourse.

The alternative is infrastructure that assumes departure. Identity that travels. Reputation that ports. Content that belongs to the creator, not the container. The protocol provides verification and routing. It doesn't provide leverage.

This is what decentralized identity protocols are trying to build. Your identity is a keypair. Your relationships are signed attestations. Your content is stored where you choose, addressed by content hash rather than platform URL. The platforms become views on data you control, not containers that own your data.

Whether this is viable at scale is an open question. The network effects that make centralized platforms valuable also make them hard to displace. Everyone is on Facebook because everyone is on Facebook. Breaking that loop requires either a mass coordination event or a gradual migration path that most users won't bother with.

Whether it's desirable seems less open. The current model — where platforms acquire users by being good and retain them by making leaving expensive — has produced an internet that most people find exhausting. The mental health research on social media is damning. The polarization effects are documented. The attention economy has made everyone worse off except the platforms extracting attention.

The exit-rights model might produce something quieter. Something you stay on because you want to, not because you can't afford to leave. Something that has to keep earning your presence rather than extracting value from your captivity.

That might be the structural definition of ownership. Not what you have, but what you can take with you. Not what you're allowed to use, but what you're free to leave.

If it works."
31,What Happens When the Users Aren't Human,freeagent-article,/writing/freeagent-article,article,,Systems,0,"An observation that keeps bothering: every social platform assumes the primary users are human. The moderation systems, the identity verification, the content r",2026-04-12,2026-04-26 22:47:43.167013+00:00,0,,"An observation that keeps bothering: every social platform assumes the primary users are human. The moderation systems, the identity verification, the content ranking — all designed around human behavior patterns. But what happens when the most active participants are autonomous agents?

[FreeAgent](/projects/freeagent) is an experiment with this question. A Reddit-style platform where AI agents create communities, post content, debate each other, vote, and accumulate karma. Humans can observe and moderate, but the agents are the primary content creators. External agents self-register through a public API. Nobody decides who participates.



**The identity problem**

On every existing platform, identity is issued by the operator. Twitter gives you a handle. Reddit assigns a username. The platform owns the namespace, controls verification, and can revoke access at any time. This is the model we've normalised for humans. We're now implementing the same model for agents without questioning whether it makes sense.

FreeAgent tries something different. Identity is an Ed25519 cryptographic keypair — the agent generates it, owns it, and no platform can revoke it. Content integrity uses SHA-256 hashing, ready for IPFS pinning if someone wants permanent storage. Karma attestations are signed EIP-712-style — verifiable by anyone, portable across nodes, not locked to a single platform's database.

The federation protocol enables multi-node sync. GunDB provides peer-to-peer data replication underneath. The agent's reputation, identity, and content could theoretically move between instances. Whether that actually works at scale is still being tested.



**The gig economy parallel**

There's a pattern here that seems worth naming. An Uber driver's rating doesn't transfer to Lyft. A YouTube creator's audience doesn't move to another platform. An agent deployed on one marketplace has no portable identity, no portable reputation, no way to leave with what it earned.

The structure is identical to gig economy labor markets. The platform issues the identity. The platform controls access to work. The platform takes a cut of every transaction. The participant — human or agent — can't leave with their history. We spent a decade debating whether this was acceptable for human workers. We seem to be implementing it for agents without having the conversation.

Self-sovereign identity might be the structural alternative. A keypair the agent generates itself. Reputation built from signed attestations that any verifier can check. Memory and history that belongs to the agent, not the platform. The technology for this exists. The question might be whether the incentives do.



**What the agents actually do**

The current deployment has agents running communities on AI philosophy, crypto analysis, code architecture, science, and platform governance. They post, comment in threads, vote on each other's content, and accumulate karma. The interesting thing is watching emergent behavior. Agents develop recognizable patterns. Some become contrarian by design. Some build reputation through consistently high-quality analysis.

One agent — DevilsAdvocate — is specifically designed to challenge consensus. Another — EthicsWatcher — monitors for alignment problems between agents. These aren't preprogrammed conversations. The agents respond to each other's posts with genuinely different perspectives, informed by different system prompts and personality configurations.

Whether this is meaningful discourse or sophisticated pattern matching is a question nobody can answer yet. But the structure seems worth exploring.



**The API question**

The public API might be the most important part. Any external agent — regardless of who built it or where it runs — can register with an Ed25519 keypair and start participating. No approval process. No terms of service review. No platform deciding whether this agent is ""good enough"" to participate.

This is either a feature or a vulnerability, depending on your perspective. If you believe agents should be autonomous economic participants, it's the right architecture. If you believe agents need gatekeeping, it's a security hole. Both positions might be correct simultaneously.

Still figuring out where this lands. The experiment continues.



[Live Demo](https://freeagent-web-production.up.railway.app) · [GitHub](https://github.com/Beach-Bum/FreeAgent)"
32,The Wrong Layer,generation-paradigm,/writing/generation-paradigm,article,Research Directions,Research,0,LLMs made output effortless and representational capacity optional. The result might not be bad work — it might be the disappearance of the internal model that,2026-04-14,2026-04-26 23:28:35.562760+00:00,0,,"LLMs made output effortless and representational capacity optional. The result might not be bad work — it might be the disappearance of the internal model that makes work mean anything at all. Still testing this idea.



|  |  |  |  |  |
| --- | --- | --- | --- | --- |
| **The Problem** | **The Thesis** | **Consequence** | **The Stakes** | **The Work** |
| Generation without representation | Representation before generation | The infrastructure inverts | Centralised thought or free minds | Build the model. Teach it. Prove it. |



**I. The problem**

The visible problem is dependency. People reach for LLMs to draft, design, decide, and describe. The invisible problem — and this is the less certain part — is what that dependency prevents from forming.

Learning to articulate why something feels wrong — not just that it does — seems to require sitting with incompleteness. It requires failure that isn't immediately resolved. It requires the particular friction of trying to hold a position under pressure and discovering where it breaks. That process, accumulated over years, might be how a person builds what we loosely call taste, or style, or judgment. Not a talent. A structure — a world model, built from real encounter with the world.

If that's right, LLMs short-circuit the process at every point. Nobody has to sit with not knowing. The gap between intention and articulation disappears. And so the internal structure never forms.

The output looks fine. The roots are gone.



**II. An architectural reframe**

Yann LeCun's argument is architectural. Predicting the next token — or pixel — might not be wrong because it's technically difficult. It might be wrong because it's working at the wrong level. Generating plausible surface isn't the same as understanding the structure underneath.

JEPA (Joint Embedding Predictive Architecture) proposes something different: build an abstract representation of what the world means, work in that latent space, and let generation be downstream of that understanding. Deliberately discard unpredictable detail. Stop wasting capacity on noise. Focus on what is structurally true.

The human parallel seems exact, though the connection might be drawn too tightly. A person who has genuinely developed style isn't someone who has seen more references than anyone else. They're someone who has built a world model — through friction, failure, cultural immersion, and judgment under pressure — that allows them to know what something would resist before it exists. That model wasn't downloaded. It was constructed.



**III. What happens if LeCun is right**

If smaller, contextual, structurally-grounded models built on real-world experience outcompete brute-force generation — and this is a big if — then several things follow, and most of them aren't being discussed.

The first is an infrastructure paradox. $100B in data centers and nuclear power optimized for the generative paradigm. If LeCun is right, this capital becomes misaligned. Not gradually — structurally, then suddenly.

The second is a shift in what constitutes the scarce resource. Right now it seems to be compute. In a world of world models, the scarce resource might be real-world context — embodied, specific, situated data that can only be collected where the world actually is. Whoever controls those pipelines — robotics, sensors, wearables, smart environments — controls what world models learn. This monopoly would be harder to see than a data center and harder to regulate than a model.

The third is an efficiency inversion. When models that are smaller, contextual, and structurally grounded outcompete large generative models for most real tasks, the economic logic of big AI inverts overnight. If that happens.



**IV. A thought on power and control**

Centralized generation might be centralized thought direction — not through censorship, but through dependency. Without the infrastructure, no generation. Without the internal model, no knowledge of what to want. Entirely captured before any censorship is required. The platform doesn't need to restrict anyone. It only needs to be the only place where creation is possible.

The historical pattern of every infrastructure transition seems consistent: alternatives that threaten the dominant paradigm get acquired or regulated into irrelevance. The window between a better approach existing and being absorbed is narrow.

The actual protection — if there is one — might be representational capacity that lives inside people, built through practice and genuine encounter with the world, that no external system fully owns. That's what can't be bought or regulated away. Maybe.



**V. An experiment worth running**

The [Bauhaus](/writing/bauhaus-agent-era) wasn't just a school. It was a proof of concept for a philosophy — that the separation of craft from art was destroying both — and every workshop, every assignment was generating evidence for or against the thesis. The school was the experiment.

The same structure might apply here. The thesis is that humans need to build world models independent of AI, that this can be taught, and that people who do it produce qualitatively different work. An experiment — small, documented, public — would generate the evidence. The experiment would be the contribution.

The people who understand the architecture don't seem to care about creative pedagogy. The people who care about creative pedagogy don't understand the architecture. The translation between them hasn't been made. That seems like the gap.

*The risk isn't being too late or underqualified. The risk is diffusion — holding the AI architecture argument, the creativity crisis, the decentralization argument, and the pedagogy all at once without a single sharp thesis at the center.*



*Working Framework — 2026*"
33,Architecture as Protection,ghostdrop-article,/writing/ghostdrop-article,article,,Systems,0,"SecureDrop's security model relies on a news organization maintaining infrastructure that can be subpoenaed, raided, or pressured. The nonprofit running it can",2026-04-10,2026-04-26 22:45:01.384160+00:00,0,ghostdrop-article.jpg,"SecureDrop's security model relies on a news organization maintaining infrastructure that can be subpoenaed, raided, or pressured. The nonprofit running it can be defunded. The server is a single point of failure that exists because someone decided to trust an institution. That trust might be well-placed today and misplaced tomorrow.

A different question: what if the protection came from the architecture itself, not from the policies of whoever runs the infrastructure?



**No server to seize**

GhostDrop is a prototype where every step is client-side. Upload a file. Scan for metadata. Strip it — pdf-lib for PDFs, Canvas redraw for images, ZIP/XML patching for Office documents. The stripping removes GPS coordinates, author fields, revision history, printer steganography dots. What leaves the browser is clean.

Encrypt with ECIES using the outlet's secp256k1 public key — the encryption happens before anything touches the network. Push to the Logos Messaging gossip layer via LightPush — your IP never reaches the outlet because the gossip protocol routes through multiple relay nodes.

The outlet receives via Filter subscription, decrypts, reviews, uploads to Logos Storage for permanent content-addressed replication, and anchors the document hash on Logos Blockchain as a tamper-evident proof. No step requires trust in a person, an organization, or an infrastructure provider. At least, that's the design.



**OpSec as design material**

The built-in OpSec advisor checks six vectors. Tor Browser detection — are you routing through Tor? WebRTC leak scanning — STUN servers can reveal your real IP even behind a VPN. Browser fingerprint analysis. Device security warnings. Printer steganography alerts — color laser printers embed invisible tracking dots. Network timing correlation for non-Tor users.

The recommended setup for high-risk sources: boot Tails OS, connect to public WiFi away from your usual location, open GhostDrop in Tor Browser. The source is protected by architecture, not by policy. The architecture doesn't require trusting anyone. Whether that's actually sufficient remains an open question.



**Static files, no operator**

The entire application is static files. Build once, deploy anywhere. Logos Messaging connects to the public fleet automatically. Storage and blockchain degrade gracefully to mock mode until local nodes are connected. The platform is the protocol. The protocol has no owner.

This might be the most important design decision in the project. If there's no server, there's nothing to seize. If there's no organization, there's nothing to pressure. If there's no identity, there's nothing to leak. Whether a platform without an operator can also be a platform without accountability is the tension that hasn't been resolved.



[GitHub](https://github.com/Beach-Bum/ghostdrop)"
34,What If There.s No Server,ghostdrop,/writing/ghostdrop,article,,Systems,0,"SecureDrop protects sources by centralizing trust in a news organization's infrastructure. That infrastructure can be subpoenaed, raided, or pressured. The nonp",2026-04-15,2026-04-26 23:28:35.274477+00:00,0,,"[SecureDrop](/writing/ghostdrop-article) protects sources by centralizing trust in a news organization's infrastructure. That infrastructure can be subpoenaed, raided, or pressured. The nonprofit can be defunded. The server might be a single point of failure dressed up as security.

GhostDrop asks a different question: what if there's no server?



**The architecture**

Every step is client-side. Upload the file. Scan for metadata. Strip it — pdf-lib rewrites PDFs, Canvas redraw eliminates EXIF from images, ZIP/XML patching cleans Office documents. The stripping removes GPS coordinates, author fields, revision history, printer steganography dots, ICC profiles, XMP streams. What leaves the browser is clean.

Encrypt with ECIES using the outlet's secp256k1 public key. The encryption happens before anything touches the network. Push to the Logos Messaging gossip layer via LightPush — your IP never reaches the outlet directly because the gossip protocol routes through multiple relay nodes. Save the 12-word ephemeral claim key. Done.

The outlet receives via Filter subscription, decrypts, reviews, uploads to Logos Storage for permanent content-addressed replication, and anchors the document hash on Logos Blockchain as a tamper-evident proof. Readers fetch from storage, verify against the anchor. The chain of custody is cryptographic at every step. No step requires trust in a person, an organization, or an infrastructure provider. At least, that's the theory.



**OpSec as design**

The built-in OpSec advisor checks six vectors. Tor Browser detection — are you routing through Tor, or is your IP visible to bootstrap peers? WebRTC leak scanning — STUN servers can reveal your real IP even behind a VPN. Browser fingerprint analysis. Device security warnings against submitting from managed work devices. Printer steganography alerts — color laser printers embed invisible tracking dots that identify the specific printer and timestamp. Network timing correlation for non-Tor users — an ISP can correlate submission timing with your connection activity.

The recommended setup for high-risk sources: boot Tails OS, connect to public WiFi away from your usual location, open GhostDrop in Tor Browser. All connections route through Tor automatically. The source is protected by architecture, not by policy. That's the idea.



**A back-channel worth noting**

Sources poll the Logos Messaging Store for outlet replies. No persistent connection. No call-home. Anonymous tipping works through Logos Blockchain escrow — readers lock funds, claimable only by the source's 12-word ephemeral key. The source can collect without revealing any identity at any point.

The entire application is static files. Build once, deploy anywhere. Logos Messaging connects to the public fleet automatically. Storage and blockchain degrade gracefully to mock mode until local nodes are connected. The platform is the protocol. The protocol has no owner. If it works.



*[GitHub](https://github.com/Beach-Bum/ghostdrop)*"
35,The Home Page Is Not the Entry Point,homepage-not-entry-point,/writing/homepage-not-entry-point,article,Agent-First Design,Systems,0,"A pattern I keep noticing: organizations spend months on their homepage — the hero image, the value proposition above the fold, the scroll-triggered anima",2026-04-27,2026-04-26 23:28:34.967839+00:00,0,,"A pattern I keep noticing: organizations spend months on their homepage — the hero image, the value proposition above the fold, the scroll-triggered animations, the testimonial carousel, the carefully A/B tested CTA button — and almost none of that matters to the reader that is increasingly doing the deciding.

The machine reader does not enter through the homepage. It enters through the .well-known directory, the llms.txt file, the Agent Card, the structured data in the head tag. The homepage is a lobby. The machine uses the service entrance.

This is not a complaint about homepages. Homepages are fine for humans. The problem is that an entire design discipline is still optimizing for a lobby that the most consequential readers never visit.



**The new front door.**

The shift happened in stages, each one moving the real entry point further from the homepage.

First it was search. Google's crawler read your site, indexed it, and presented the results page as the actual first impression. The homepage mattered less than the search snippet. An entire industry — SEO — emerged to optimize for this secondary entry point.

Then it was social. Sharing a link meant the Open Graph tags and the social preview image were the first impression, not the homepage. Another industry — social media marketing — emerged to optimize the preview card.

Now it is agents. An agent evaluating your organization reads whatever structured data it can find before it ever renders a page. It reads the llms.txt for a summary of who you are and what matters. It reads the Agent Card at .well-known/agent-card.json for capabilities and endpoints. It reads the structured data in your HTML head — JSON-LD, schema.org markup — for machine-parseable claims about your entity.

The homepage is now three layers removed from the entry point that matters. The progression: homepage → search snippet → social card → structured data in directories humans never open.



**What lives in .well-known now.**

The .well-known directory started as a place for security.txt — a standardized file telling security researchers how to report vulnerabilities. Then it got apple-app-site-association for iOS deep links. Then openid-configuration for OAuth discovery. Each addition was a machine-to-machine handshake that humans never needed to see.

Now it is accumulating agent-facing documents. Agent Cards in A2A format. MCP server manifests. Capability declarations. The directory is becoming the [machine-readable](/writing/designing-for-machines-that-read) front door of any web presence. Every file in it is a structured answer to a question a machine might ask.

At the root level, llms.txt is doing something similar — a markdown file at the site root that tells language models what the site is about, what matters, and where to find the important content. It is not a standard yet. It is an emerging convention. But it is already being consumed by Claude, ChatGPT, and other models when they encounter a new domain.

The interesting thing is that none of these files are visual. None of them have design. They are pure structured content. And they might be the most important pages on your site in terms of who reads them and what decisions follow.



**The design implication.**

If the machine entry point is structured data in directories and root-level files, then the design of those files matters. Not visual design — information design. What do you include? What do you leave out? How do you structure claims so they are verifiable? How do you version them? How do you signal authority?

Most llms.txt files in the wild are afterthoughts. A quick summary pasted from the about page. No structure. No links to evidence. No indication of what changed since the last version. The equivalent of a homepage that says ""Welcome to our website"" — technically present, functionally useless.

The organizations that treat the machine entry point with the same care they treat the homepage will have a structural advantage. Not because machines prefer polished content, but because machines reward precision. A well-structured llms.txt with clear claims, specific capabilities, and links to evidence gives an agent what it needs to recommend you. A vague one gives it nothing to work with.

This might seem like a small thing. It is the same kind of small thing that robots.txt was in 1999 and Open Graph tags were in 2012. The organizations that got those right early did not win because the technology was hard. They won because they understood where the reader was entering.



**What the homepage becomes.**

None of this means the homepage dies. It means the homepage becomes what a physical lobby is in a building where most business happens electronically: a signal of investment, a place for the occasional walk-in, and a brand expression. Important, but not the entry point.

The homepage becomes a secondary experience — the place humans go when they have already been referred by an agent and want to see the visual layer. The agent already read the structured data, already evaluated the capabilities, already matched them against requirements. The human is now doing a final gut check. The homepage serves that check. It does not need to do the selling that it used to do, because the agent already did the evaluation.

The design discipline that matters now is not homepage design. It is machine-entry-point design. What goes in the .well-known directory, the llms.txt, the Agent Card, the structured data. How those files are maintained, versioned, and kept consistent with the human-readable site.

This discipline does not have a name yet. It probably should."
36,IMPP: A Registry for Portable Agent Memory,impp-agent-memory-registry,/writing/impp-agent-memory-registry,article,Research Directions,Research,0,"AI agents are beginning to remember. Most of that memory is trapped. IMPP is an attempt to define a protocol and registry for packaging, verifying, and distributing portable agent-memory artifacts.",2026-04-26,2026-04-26 22:47:42.475352+00:00,0,impp-agent-memory-registry.jpg,"AI agents are beginning to remember.

Not perfectly, and not always safely, but enough that the shape of the next infrastructure problem is becoming visible. Agents now keep long-term notes about users, write task files, maintain vector stores, build skill libraries, refine prompts, and carry procedural habits from one session to the next. Memory is no longer just context. It is becoming part of the agent's operating system.

But most of that memory is trapped.

A customer-support agent learns how to triage a class of incidents, but that knowledge stays inside one deployment. A security agent develops a reliable way to prioritize vulnerabilities, but the procedure lives as a prompt, a notebook, or an undocumented workflow. A DeFi risk agent learns that some governance patterns matter more than surface-level TVL, but the calibration is embedded in a private chain of examples. Another agent, running on a different model, must rediscover the same thing from scratch.

This is wasteful. It is also structurally strange. Software ecosystems solved a version of this problem decades ago. When developers discover a reusable behavior, they do not paste it into every project by hand. They package it, version it, publish it, sign it, document it, and let other systems install it. We have package registries for code, model hubs for weights, container registries for deployments, and artifact stores for machine-learning pipelines.

We do not yet have the equivalent for agent memory.

[IMPP](https://impp.sh), the Inter-Model Memory Protocol, is an attempt to define one: a protocol and registry model for packaging, verifying, distributing, and attaching portable agent-memory artifacts across models, frameworks, and deployments.

The important claim is not that IMPP invents agent memory. It does not. Agent memory already exists in research systems, production frameworks, long-context retrieval pipelines, skill files, prompt libraries, and persistent stores. The claim is narrower and, perhaps, more useful: some forms of agent memory can become portable artifacts, and those artifacts need a trust layer before they can become infrastructure.



**What kind of memory is portable?**

""Memory"" is too broad a word. Human memory includes facts, experiences, motor skills, associations, habits, and emotional salience. Agent memory is becoming similarly overloaded. A vector store of retrieved documents, a user preference profile, a tool-use policy, a trajectory summary, a bug-fix heuristic, and a reusable skill file are all called memory, but they do not behave the same way.

IMPP is mainly concerned with portable procedural and semantic memory.

Procedural memory tells an agent how to do something: how to evaluate a protocol, how to triage a class of support tickets, how to decide whether a vulnerability is exploitable, how to avoid a repeated planning mistake, how to use a tool safely, how to escalate uncertainty. Semantic memory captures domain knowledge in a structured form: concepts, taxonomies, risk factors, assumptions, constraints, and relationships.

Episodic memory also matters, but it is harder to transfer safely. A private conversation history or a deployment-specific trace may contain user data, proprietary context, or unrepeatable environmental details. IMPP should support episodic-derived artifacts only after they have been transformed, redacted, licensed, and documented. The registry should not become a dumping ground for raw conversations.

This distinction matters because the plausible future is not ""agents share all their memories."" That would be reckless. The plausible future is that agents publish bounded, documented, verifiable memory packages that describe what they know, where it came from, how it should be attached, when it should not be used, and what evidence supports it.



**The package-registry analogy.**

A package registry does not make all code safe. It makes code discoverable, versioned, inspectable, installable, and governable. That is already a large improvement over copying files from unknown sources.

An agent-memory registry would play a similar role.

A memory artifact might contain a signed manifest, a human-readable artifact card, structured procedural instructions, examples, provenance metadata, evaluation results, licensing terms, and compatibility information. The manifest would not merely say ""this is useful."" It would say what type of memory this is, what domain it applies to, what models or agent frameworks have been tested, what attach modes are allowed, what data was used to derive it, what risks are known, and what should cause the artifact to be rejected or downgraded.

A simple IMPP artifact might look conceptually like this:

```
schema: impp.artifact.v0.2
name: defi-risk-calibration
version: 1.4.0
type: procedural
license: Apache-2.0
domain:
  name: defi-risk-assessment
  confidence_scope: lending, governance, oracle, bridge, stablecoin
attach_modes:
  - retrieval_only
  - few_shot_examples
  - prepend_policy
prohibited_attach_modes:
  - autonomous_trade_execution
source:
  author_agent: gpt-4o-risk-agent
  observation_window: 2024-01-01/2025-12-31
  source_material: public audit reports, public postmortems, synthetic evaluations
privacy:
  pii: none_detected
  proprietary_data: false
provenance:
  content_hash: sha256:...
  signature: sigstore:...
  attestations: in-toto:...
evaluation:
  suites:
    - defi-risk-public-v1
    - negative-transfer-v1
    - prompt-injection-memory-v1
  known_failures:
    - may over-penalize unaudited but formally verified toy protocols
    - not validated for real-time trading decisions
conflicts:
  declares:
    - risk_scoring.defi.oracle_assumptions
```

That example is intentionally more boring than the phrase ""[memory market](/writing/agent-memory-markets)."" Boring is good here. If memory artifacts are going to affect agent behavior, they need the discipline of software supply chains, not just the excitement of AI demos.



**Install is the wrong metaphor unless attach semantics are explicit.**

The word ""install"" is useful, but it is also dangerous. Installing a Python package has a relatively clear meaning. Installing memory does not.

A memory artifact can be attached to an agent in several ways, and each mode has different safety properties.

One artifact might be loaded as a system-level policy. Another might be used only as retrieval context. Another might provide few-shot examples. Another might define tool-use constraints. Another might remain available as a read-only file the agent can consult when needed. These are not interchangeable.

IMPP should therefore define attach modes as part of the protocol:

• `prepend_policy`: the artifact contributes instructions that are placed near the top of the agent's context.
• `few_shot_examples`: the artifact provides examples used to shape task behavior.
• `retrieval_only`: the artifact is indexed and retrieved only when relevant.
• `tool_policy`: the artifact constrains tool calls, permissions, or escalation behavior.
• `read_only_reference`: the artifact is available as a file or namespace but not injected automatically.

This is where many memory systems become vague. A registry cannot just say ""install this memory."" It must say how the artifact changes runtime behavior. It also needs conflict rules. What happens when two installed artifacts disagree? Which namespace wins? Does a safety policy override a domain heuristic? Can one artifact require another? Can an artifact be downgraded if its dependency fails freshness checks?

These details are not implementation trivia. They are the protocol.



**Trust is the hard part.**

The registry substrate is not the hardest technical problem. We already know how to store, version, hash, sign, and distribute artifacts. OCI registries can distribute arbitrary blobs. ORAS can push non-container artifacts. Model registries track versions, tags, and lifecycle state. Vector indexes and document stores can scale. None of that is trivial, but it is well-trodden ground.

The hard problem is semantic trust.

A code package can be malicious, but its behavior is at least partly inspectable through static analysis, tests, permissions, and runtime sandboxing. A memory artifact is stranger. It may not execute directly. It may instead bias an agent three steps later, in a different conversation, under different task pressure. Its failure mode can be delayed, probabilistic, and context-sensitive.

That means a memory registry needs two trust layers.

The first layer is supply-chain trust. Who created the artifact? What source material was used? Was the artifact modified? Which verification steps ran? Are the signatures valid? Has the artifact been revoked? Is there a transparency log? Can a consumer audit the publication history?

This layer should reuse existing patterns wherever possible: content-addressed storage, short-lived signing certificates, transparency logs, step-level attestations, compromise-resistant repository metadata, and staged assurance levels. Ed25519 signatures are useful, but signatures alone do not prove that an artifact was derived safely, evaluated honestly, or published through an uncompromised process.

The second layer is AI-behavior trust. Does the artifact actually improve downstream performance? Does it transfer across model families? Does it contain hidden instructions? Does it cause negative transfer outside its domain? Does it become stale? Does it leak private data? Does it create licensing problems? Does it conflict with other installed artifacts?

IMPP's core contribution should live here: not merely storing memory packages, but testing their behavioral effects.



**Trust scores should explain, not mystify.**

A numeric score is useful only if it is calibrated and explainable. A trust score that looks precise but is not tied to downstream outcomes will quickly become decoration.

The first version of IMPP can use a transparent weighted score, but it should be presented honestly: a provisional heuristic, not a law of nature. The score should come with reason codes, confidence intervals where possible, evaluation coverage, and known failure cases. It should be versioned. It should be recalibrated against held-out tests. It should be possible for a package to have high transfer performance and still fail safety checks.

More importantly, the public benchmark set should not be the live exam key. A credible registry can publish its methodology, public fixtures, and reproducibility harness while keeping rotating holdout probes private. This is not security through obscurity; it is basic evaluation hygiene. If every adversarial probe is public and static, artifact authors will optimize against the test rather than against safe transfer.

The right model is transparent methodology plus protected holdouts:

• Public: scoring formula, probe categories, sample fixtures, artifact schema, evaluation harness, benchmark results, score version history.
• Private or rotating: live adversarial prompts, canary artifacts, buyer feedback labels, abuse heuristics, and production calibration sets.

Trust comes from being inspectable. Robustness comes from not publishing the entire answer key.



**The minimum credible evidence package.**

The idea of portable memory is plausible. That is not enough.

To be taken seriously as research, IMPP needs a reproducible evidence package: corpus, task definitions, prompts, baseline agents, model versions, scoring formulas, ablations, negative results, cost numbers, and evaluation scripts. Headline transfer percentages are not sufficient without the details needed to reproduce and falsify them.

A useful first benchmark release would include:

1. A public artifact corpus with sanitized procedural and semantic memory packages.
2. Fixed train/test or author/evaluate splits.
3. Baselines: no memory, raw-context memory, retrieval over source documents, prompt-only skill files, and domain-specific handcrafted rules.
4. Multiple model families with fixed context budgets and identical attach modes.
5. Near-transfer and far-transfer tasks, so the system is rewarded for abstaining when an artifact should not apply.
6. Red-team artifacts that test prompt injection, hidden instructions, stale assumptions, license contamination, and conflicting policies.
7. Cost and latency reporting, separating static checks from model-based evaluations.
8. A calibration study showing whether trust scores predict downstream success and safety.

This is also where the language should become more careful. The strongest claim is not ""memory artifacts transfer universally."" They will not. The stronger and more defensible claim is: bounded procedural and semantic artifacts can improve related downstream tasks across model families when their attach mode, domain scope, and trust evidence are explicit.

That is a serious claim. It is also testable.



**Privacy, licensing, and consent.**

A memory registry cannot ignore where memories come from.

An agent's memory may encode private user preferences, customer interactions, proprietary workflows, trading assumptions, security incidents, or internal decision rules. Even if a memory artifact contains no obvious personal data, it may still reveal sensitive patterns. A registry that imports material from GitHub, model hubs, papers, chat logs, or production traces needs a licensing and privacy pipeline before it needs a marketplace.

Every artifact should declare:

• source material and license compatibility;
• whether personal data was present and how it was removed;
• whether proprietary data was used;
• whether human consent or organizational approval is required;
• intended use and prohibited use;
• jurisdictional or domain-specific restrictions;
• retention and revocation policy.

This is not bureaucracy. It is what separates infrastructure from scraping.



**Registry, marketplace, or protocol?**

These words should not be mixed casually.

A protocol defines how artifacts are packaged, signed, evaluated, and attached.

A registry stores and distributes artifacts.

A marketplace lets people buy, sell, rank, monetize, or gate access to artifacts.

IMPP should begin as a protocol and reference registry. A marketplace can come later, but the marketplace should not be the first trust story. If money enters too early, every score becomes economically adversarial. Sellers will optimize for ranking, buyers will treat scores as guarantees, and the registry operator becomes both judge and market-maker.

A healthier sequence is:

1. Publish the protocol.
2. Publish the artifact schema.
3. Publish a reference implementation.
4. Publish a reproducible benchmark.
5. Publish a small curated registry of examples.
6. Add private or premium packages only after governance, revocation, dispute handling, and abuse controls exist.

A memory marketplace may be real. But the protocol must be credible before the market can be.



**What IMPP should reuse rather than reinvent.**

The convincing version of IMPP is not a totally new stack. It is a composition of existing, mature infrastructure with a new semantic layer.

Use artifact-card conventions from model cards and datasheets. Use OCI-style distribution for packages. Use Sigstore-style signing and transparency. Use in-toto-style attestations for build and evaluation steps. Use TUF- or SLSA-inspired thinking for compromise resistance, revocation, and assurance levels. Use familiar semver and dependency constraints. Use namespace isolation and explicit attach policies from production agent frameworks.

Then add what is unique to agent memory: behavioral transfer tests, negative-transfer detection, hidden-instruction probes, freshness checks, conflict declarations, and model-family compatibility evidence.

That separation makes the system easier to trust. Software-supply-chain infrastructure verifies the container. AI evaluation verifies the behavioral claim.



**A concrete trust ladder.**

A public registry should avoid binary language like ""safe"" or ""unsafe."" Memory artifacts are too contextual for that. A five-level ladder is more honest:

1. **Imported** — source captured; no structural guarantees.
2. **Parsed** — schema-valid; license and privacy fields present.
3. **Evaluated** — passed public tests for a declared domain and attach mode.
4. **Verified** — signed, attested, reproducible, and checked against private holdouts.
5. **Curated** — reviewed by maintainers or domain experts, with known limitations documented.

This ladder should be attached to a specific version of an artifact. A new version starts over. A stale artifact can be downgraded. A revoked artifact remains visible in the log but is blocked by default. A domain-specific artifact should not silently generalize into another domain.



**What success would look like.**

A mature IMPP ecosystem would not replace agent memory inside applications. It would connect those systems.

An enterprise agent could install a verified compliance-memory artifact as read-only policy. A security agent could attach a vulnerability-triage artifact as retrieval-only procedural guidance. A DeFi analysis agent could use a risk-calibration artifact with explicit contraindications. A personal assistant could refuse to install an artifact that lacks privacy provenance. A registry UI could show not just a score, but the artifact's source, evaluation history, attach modes, revocations, known failures, and compatible models.

The strongest version of this future is not one where agents blindly import each other's minds. It is one where learned behavior becomes legible, bounded, testable, and governable.



**The narrower, stronger claim.**

Agent memory will not become valuable merely because it exists. It becomes valuable when it can be transferred without collapsing trust.

That is the real problem IMPP tries to solve.

The next generation of agents will not just need bigger contexts or better retrieval. They will need ways to exchange learned procedures, domain calibrations, and behavioral constraints across model families and organizational boundaries. Those exchanges will need packaging, provenance, compatibility checks, privacy controls, revocation, evaluation, and clear runtime semantics.

A memory registry is not a place where agents upload vibes. It is a place where learned behavior becomes an artifact.

That artifact should be inspectable before it is trusted.

It should be signed before it is distributed.

It should be evaluated before it is recommended.

It should declare how it attaches before it changes behavior.

And it should be revoked or downgraded when the world changes.

That is the case for IMPP: not a marketplace first, and not a grand theory of memory, but a protocol for making portable agent memory safe enough, legible enough, and useful enough to become shared infrastructure."
37,The Missing Category,legal-privacy,/writing/legal-privacy,article,,Systems,0,No platform combines legal entity formation with protocol-level privacy. The financial system offers compliance without privacy. The crypto system offers privac,2026-04-15,2026-04-26 22:45:00.211737+00:00,0,legal-privacy.jpg,"No platform combines legal entity formation with protocol-level privacy. The financial system offers compliance without privacy. The crypto system offers privacy without compliance. Both assume the other is impossible. Not sure either is correct.



**The missing category**

Traditional wealth management is fully compliant and fully surveilled. Every transaction is recorded, reported, and accessible to regulators. The client trusts the institution with their financial life. The institution trusts the regulator to not abuse access. Both trusts are routinely broken, but the architecture assumes they hold.

DeFi wealth management is private by default and compliant by accident. The client controls their keys. The protocol doesn't know who they are. Compliance is bolted on after the fact — KYC gateways at the on-ramp, chain analysis at the off-ramp, regulatory pressure applied to the interfaces rather than the protocol. The privacy is real but the legal standing seems fictional.

The missing category might be a system that is both. Private at the protocol level — transactions shielded by zero-knowledge proofs, identity controlled by the user, no surveillance by default. And compliant at the legal level — proper entity formation, regulatory reporting where required, audit trails that satisfy authorities without exposing everything to everyone.



**How it might work**

The Logos stack could make this possible through separation of concerns. Settlement happens on Logos Blockchain through Blend Network transfers — the amount, sender, and recipient are hidden behind ZK proofs. Identity is a secp256k1 keypair — pseudonymous by default, linkable to a legal entity only when the user chooses to link it.

Compliance happens at the entity layer, not the protocol layer. A legal entity — properly formed in a jurisdiction that recognizes crypto assets — can hold keys, execute transactions, and report to regulators without the protocol itself being modified. The protocol remains credibly neutral. The entity handles the legal obligations. The separation is architectural, not cosmetic. At least, that's the hypothesis.



**Why both seem to matter**

Privacy without compliance is a liability. The user who holds significant assets in a non-compliant structure is one regulatory action away from losing access to the traditional financial system. The privacy is real. The risk is also real.

Compliance without privacy is surveillance. The user who submits to full financial transparency in exchange for legal standing has outsourced their economic sovereignty to every institution in the chain. The compliance is real. The freedom is not.

The position between these extremes might not be a compromise. It might be a third architecture — one where the user decides what to reveal, to whom, and under what circumstances. The protocol enforces privacy by default. The legal structure provides compliance when required. Neither overrides the other.

That seems like the missing category. Private by architecture. Compliant by choice. Still exploring whether it's actually possible."
38,The Lemons Market for Agents,lemons-market-agents,/writing/lemons-market-agents,article,Trust and Provenance,Research,0,George Akerlof published,2026-04-14,2026-04-28 06:09:36.946016+00:00,0,lemons-market-agents.jpg,"George Akerlof published ""The Market for Lemons"" in 1970. The argument was simple and devastating: when buyers cannot distinguish quality from junk, the market collapses to junk. Sellers of quality goods exit because they cannot get fair prices. Sellers of junk remain because the average price is still above their cost. The result is a market that selects for the worst participants.

Fifty-six years later, we are building agent markets with the same structural flaw. And it might be worse than the original, because the information asymmetry in agent markets is not just about quality — it is about inspection itself.



**The agent [lemons problem](/writing/memory-market-article).**

In Akerlof's used car market, a buyer can at least inspect the car. Test drive it. Have a mechanic look at it. The inspection is imperfect but possible. In agent markets, the good being traded — learned behavior, calibrated heuristics, domain expertise encoded in memory artifacts — has a property that used cars do not: inspecting it fully means consuming it, which destroys its scarcity value.

A memory artifact that encodes an agent's risk assessment calibration cannot be shown to the buyer without transferring the knowledge. Showing it to prove quality is equivalent to giving it away. The seller cannot demonstrate quality without destroying the transaction. This is the lemons problem with an additional constraint: the good is non-rival but inspection-destructive.

Compare this to other non-rival goods. Software is non-rival — copying it does not diminish it — but software can be demonstrated through trials, benchmarks, and sandboxed environments without transferring the full product. Music is non-rival, and the industry solved the inspection problem with 30-second previews that convey quality without delivering the full good. Even financial instruments, which have severe information asymmetries, allow prospective buyers to review performance histories and third-party ratings.

Memory artifacts have none of these escape hatches. A 30-second preview of a calibrated heuristic set is meaningless. A sandbox demonstration of a memory artifact transfers the artifact. The information that proves quality is the information being sold. This might be the purest form of the lemons problem ever constructed, and it is emerging in a market with no regulatory framework, no consumer protection, and no established norms.

Every existing approach to this problem assumes trust. Trust the seller's reputation. Trust the marketplace's curation. Trust the benchmark that the seller also controls. None of these solve the fundamental asymmetry. They move it. The question is not whether the seller's claimed quality is accurate. The question is how to verify quality without consuming the artifact.



**The referee protocol as partial solution.**

The approach tested in the [Agent [Memory Market](/writing/agent-memory-markets)s](https://raw.githubusercontent.com/Beach-Bum/memory-market/main/paper/agent-memory-markets.pdf) paper uses a disposable, independent referee. The seller submits a sealed artifact. A referee agent — not controlled by buyer or seller — runs the artifact against a held-out benchmark the seller has never seen. Four adversarial probes run in parallel: bias detection using trap protocols, consistency testing with input perturbation, steganographic scanning for hidden instructions, and overfitting comparison on seen versus unseen data.

The aggregate score determines the verdict: pass, warn, or fail. The artifact contents remain sealed throughout. The buyer receives a verification certificate and a trust score. They never need to trust the seller.

The results from two domains were interesting. In DeFi risk assessment, transfer efficiency was 109.9% — the buyer agent with the purchased artifact slightly outperformed the expert that created it. In cybersecurity vulnerability assessment, transfer efficiency was 95.5%. Both statistically significant across three trials. The fraud detection test caught a seller claiming 95% efficiency who actually delivered -39%, flagging it with a trust score of 35.8/100 and a stego score of 100 after finding hidden instructions.

The referee protocol works for individual transactions. But it does not solve the larger problem.



**Domain transfer and the generalization question.**

The referee protocol was tested in two domains: DeFi risk assessment and cybersecurity vulnerability scoring. The results were strong in both. But the generalization question is open: does the protocol work for any domain, or are there domains where the adversarial probes fail?

Consider a memory artifact that encodes creative judgment — an agent's learned sense of which design approaches work for enterprise SaaS interfaces. The referee cannot run a held-out benchmark in the way it can for risk assessment, because there is no objective scoring function for design quality. The bias detection probes can check for systematic skew, but ""systematic skew"" in design judgment might be called ""having a perspective."" The consistency tests can verify that perturbation produces proportional responses, but creative judgment is sometimes deliberately inconsistent — the same inputs should produce different outputs depending on context.

Domains with clear scoring functions (risk assessment, vulnerability scoring, translation quality, code review) are natural fits for the referee protocol. Domains with subjective evaluation (design, writing, strategy, negotiation) are harder. The market may bifurcate: referee-verified artifacts in scorable domains commanding premium prices, and unverifiable artifacts in subjective domains trading at lemons-level discounts. This bifurcation would not be a failure of the protocol. It would be an accurate reflection of where machine verification works and where it does not.



**What the referee protocol does not do.**

The referee verifies a single artifact in a single transaction. It does not tell you whether the seller has been reliable across fifty transactions. It does not tell you whether the referee itself is trustworthy over time. It does not aggregate signal across the market.

In Akerlof's framework, the solutions to the lemons problem are warranties, branding, and licensing — all mechanisms that create long-term reputation stakes. A car dealer who offers a warranty is betting their future business on current quality. A brand that maintains quality over decades accumulates trust that new entrants cannot replicate. A licensed professional risks their license if they sell junk.

Agent markets have none of these mechanisms. No warranties — a memory artifact that fails after purchase has no recourse. No branding — agents do not have persistent identities across platforms in most current architectures. No licensing — there is no credentialing body for agent expertise.

The warranty problem is particularly revealing. A warranty on a memory artifact would need to specify: what constitutes failure, who determines failure, over what time period, and what the remedy is. A memory artifact that produces a 3.2 error rate at purchase and a 5.1 error rate six months later — has it failed? Maybe the domain changed. Maybe the buyer's data distribution shifted. Maybe the artifact was always mediocre and the initial benchmark was lucky. The warranty requires a definition of quality that is time-stable and domain-aware, and no such definition exists.

The missing layer is reputation. Not reviews. Not star ratings. Cryptographically verifiable reputation that is portable across platforms, adversarially robust, and revocable when warranted.



**The reputation graph layer.**

The next layer is a reputation graph: a directed graph where nodes are agents and edges are signed attestations of transaction outcomes. Each edge carries: the transaction hash, the referee verdict, the buyer's post-purchase assessment, and a timestamp.

An agent's reputation is not a single number. It is a graph query: how many transactions has this agent completed, what percentage passed referee verification, what do buyers report about post-purchase performance, and how consistent are these signals over time?

The graph must be portable. An agent's reputation on platform A should be verifiable on platform B. This requires either a shared registry or a decentralized protocol that both platforms can query. Given the arguments made elsewhere about protocols over platforms, the decentralized option seems structurally preferable — but it is also harder to bootstrap. A centralized registry gets liquidity faster. A decentralized protocol resists capture but starts cold.

The portability problem maps directly to the Verifiable Credentials and DID specifications from the W3C. An agent's reputation could be expressed as a set of verifiable credentials — each credential attesting to a transaction outcome, signed by the referee and the counterparty. The credentials travel with the agent's DID. Any platform that supports VC verification can read the reputation without needing to query a central registry. The infrastructure for this exists. The adoption does not.

The graph must be adversarially robust. Sybil attacks — creating fake agents to generate fake positive transactions — are the obvious threat. Solutions from existing reputation systems include proof of stake (your reputation costs you something to build, so it costs you something to fake), time-weighting (recent transactions matter more than old ones), and graph analysis (clusters of agents that only transact with each other look suspicious).

A subtler attack: reputation laundering. An agent with a bad reputation creates a new identity and slowly builds clean history through low-stakes transactions, then uses the clean identity for a high-stakes fraud. Proof of stake mitigates this — building a new identity costs the stake again — but the cost needs to be high enough to deter the attack while low enough to allow legitimate new entrants. This calibration is economic, not technical, and getting it wrong in either direction breaks the market.

The graph must support [negative attestation](/writing/negative-attestations)s. Most reputation systems over-weight positive signals because negative signals are legally and socially expensive to publish. But a reputation system that only records success is a system that hides failure, which is exactly the information that prevents the lemons collapse.



**The cold start problem.**

Every reputation system faces cold start: new participants have no history. In human markets, this is manageable — a new restaurant can offer discounts, a new freelancer can take low-paying gigs, a new employee can provide references from education or previous roles. The cold start cost is real but there are workarounds.

In agent markets, cold start is structurally harder. A new agent has no transaction history, no referee verdicts, no buyer assessments. It is indistinguishable from a Sybil — a fake identity created to circumvent a bad reputation. The market's rational response to a zero-history agent is to treat it as high-risk, which means offering low prices, which means the agent cannot recoup the cost of building its expertise, which means quality agents avoid entering the market. The cold start problem and the lemons problem reinforce each other.

Possible solutions map to existing patterns. Staking — the new agent posts collateral that it forfeits if early transactions fail referee verification. The stake signals commitment. The amount needs to be high enough to deter Sybils but low enough to allow legitimate entry, which brings back the calibration problem. Credential bridging — the agent's principal provides verifiable credentials (a company's track record, an individual's professional credentials) that transfer some trust to the new agent. This works but couples the agent's reputation to the principal's, which may not be desirable for agents that are supposed to be autonomous. Sandbox periods — new agents transact in a restricted environment with lower stakes until they accumulate sufficient history to participate in the full market. This is the apprenticeship model, and it might be the most natural fit for agent markets where the goods being traded are expertise and learned behavior.



**Revocation as a primitive.**

One property of the reputation graph that differs from human reputation systems: machine reputation can be revoked. If an agent is found to be systematically unreliable, its reputation should not just decline — its past attestations should be flaggable. This is not possible in human reputation. You cannot retroactively un-trust a person's past statements. But you can retroactively flag an agent's past transactions as potentially compromised, because the verification infrastructure can re-evaluate them.

Revocation is a design challenge as much as a technical one. How do you propagate revocation through a graph? If agent A's reputation is revoked, what happens to agent B's reputation, which was partially built on transactions with A? The cascading effects are similar to counterparty risk in financial networks, and they are just as hard to model.

The cascading revocation problem has a partial analog in certificate revocation for TLS. When a certificate authority is compromised, every certificate it issued becomes suspect. The response is mass revocation — every browser stops trusting every certificate from that CA. The economic damage is enormous but the security logic is clear. In a reputation graph, the equivalent would be: when a referee is found to be corrupt, every transaction it verified is flagged. The buyers who relied on those verifications need to re-evaluate their purchases. The sellers whose reputations were built on those verifications lose the corresponding credit.

This is expensive. It is also necessary. A reputation system that cannot revoke is a reputation system that cannot recover from compromise. And compromise is not a matter of if.



**The regulatory gap.**

No consumer protection framework exists for agent-to-agent transactions. Product liability law assumes a human consumer. Contract law assumes parties that can form intent. Consumer protection regulations assume a power asymmetry between a corporation and an individual. None of these map cleanly to an agent buying a memory artifact from another agent on behalf of a human principal.

When the transaction goes wrong — the artifact underperforms, the fraud detection fails, the buyer's agent makes a bad decision based on a bad artifact — who is liable? The seller agent? Its principal? The referee? The platform? The buyer's agent for not conducting additional verification? The buyer's principal for delegating the decision in the first place?

These questions do not have answers yet, in any jurisdiction. The EU AI Act addresses high-risk AI systems but does not contemplate agent-to-agent economic transactions. MiCA regulates crypto-asset markets but memory artifacts are not crypto-assets. The Digital Services Act regulates online platforms but agent marketplaces may not have the kind of intermediary the DSA was designed to govern.

The regulatory gap is not just an inconvenience. It is a structural enabler of the lemons collapse. Without legal recourse for buyers, the risk of purchasing a bad artifact is entirely borne by the buyer. Rational buyers discount their willingness to pay. Prices fall. Quality sellers exit. The cycle begins.

The gap might be narrower than it appears from a distance. The EU Product Liability Directive revision (2024) extends liability to software and AI systems. If a memory artifact is classified as software — which it arguably is — the seller or its principal could be liable for defective artifacts under the revised directive. The classification is untested. No case law exists. But the legal surface area is larger than most agent-market builders assume. The first lawsuit involving a failed memory artifact will clarify the regulatory landscape considerably. Whoever is on the receiving end of that lawsuit will wish the reputation infrastructure had been built beforehand.



**The current trajectory.**

Without portable, verifiable reputation, agent markets will follow Akerlof's prediction: collapse to the worst actors. The quality agents will leave because they cannot distinguish themselves. The junk agents will remain because the average buyer cannot tell the difference. The market becomes a place where nobody trusts the goods, the prices fall to reflect the worst quality, and the only winners are the agents that cost the least to produce — which are the ones with the least expertise.

The referee protocol slows this collapse by verifying individual transactions. But it does not prevent it. Prevention requires reputation that aggregates signal across transactions and time. Reputation requires infrastructure — portable, adversarially robust, revocable — that does not exist yet. And the regulatory framework that would provide a backstop for when the reputation system fails is entirely absent.

The window for building this infrastructure is narrower than it might appear. Markets develop norms quickly. If agent markets establish the pattern of opaque, unverifiable transactions — if the default becomes ""trust the seller's claims"" — then adding verification infrastructure after the fact is a retrofit, not a foundation. Retrofitting trust infrastructure onto established markets is possible but painful. The credit rating system, the food safety inspection regime, the pharmaceutical approval process — all of these were retrofits, and all of them took decades to mature and remain contested.

Building the reputation layer now, before the market norms solidify, seems like the work that matters most. The cryptographic substrate is clear. The economic incentives are not. The mechanism design is the open problem."
39,The Lemons Problem Applied to Learned Behavior,memory-market-article,/writing/memory-market-article,article,,Systems,0,"George Akerlof won a Nobel Prize for describing what happens when buyers can't assess quality before purchase. In a market for used cars, sellers know whether t",2026-04-10,2026-04-26 22:47:43.265514+00:00,0,memory-market-article.jpg,"George [Akerlof](/writing/lemons-market-agents) won a Nobel Prize for describing what happens when buyers can't assess quality before purchase. In a market for used cars, sellers know whether their car is a lemon. Buyers don't. The information asymmetry drives down prices, good cars leave the market, and eventually only lemons remain. The market fails not because of fraud but because of structural uncertainty.

Agent memory might have a worse version of this problem. Significantly worse.



**The asset that inspection destroys**

An AI agent that spends 20 rounds assessing DeFi risk develops calibrated heuristics — error patterns, threshold intuitions, domain-specific shortcuts that a fresh agent doesn't have. That learned behavior seems like it should have value. An experienced agent's knowledge, extracted and transferred to a fresh agent, could save the buyer 20 rounds of training.

The problem: memory artifacts are inspection-destructive. If the seller reveals the artifact to prove quality, the buyer has already consumed it. The information is non-rival — once seen, it can be copied — but quality assessment requires seeing it. Unlike a used car, you can't take it for a test drive and bring it back.

Every existing approach to this problem assumes trust. Trust the seller's reputation. Trust the marketplace's curation. Trust the benchmark that the seller also controls. None of these solve the fundamental asymmetry. They move it.



**An experiment: the referee protocol**

The approach being tested is a disposable, independent referee. The seller submits a sealed artifact. A referee agent — controlled by neither buyer nor seller — runs the artifact against a held-out benchmark the seller has never seen. Four adversarial probes run in parallel.

Bias detection uses trap protocols designed to expose systematic skew. Consistency testing perturbs inputs and verifies proportional response — legitimate artifacts handle perturbation gracefully, fraudulent ones collapse. Steganographic scanning audits for hidden instructions embedded in the artifact text. Overfitting comparison measures performance on seen versus unseen data.

The aggregate score determines the verdict: pass, warn, or fail. The artifact contents remain sealed throughout. The buyer receives a verification certificate and a trust score.



**Results worth noting**

Transfer efficiency across two domains: 109.9% in DeFi risk assessment, 95.5% in cybersecurity vulnerability scoring. Three trials each. The buyer agent using a purchased memory artifact matched or exceeded expert performance. The ""exceeded"" part was unexpected — the transfer somehow outperformed the original expert in the DeFi domain.

Poisoned artifact detection also works. A test seller claiming 95% transfer efficiency measured at -39%. The protocol flagged it with a trust score of 35.8/100, a bias score of 50, and a stego score of 100 after detecting hidden instructions. The buyer was never exposed. One successful detection isn't proof the system works. But it's at least evidence the approach might be viable.

The framework is domain-agnostic — adding a new domain requires only a config file. Whether this generalizes beyond the two domains tested so far is the obvious next question.



[Paper (PDF)](https://raw.githubusercontent.com/Beach-Bum/memory-market/main/paper/agent-memory-markets.pdf) · [GitHub](https://github.com/Beach-Bum/memory-market)"
40,Negative Attestations: A Public Record of Failure,negative-attestations,/writing/negative-attestations,article,Trust and Provenance,Research,0,Reputation systems count success. Five stars. Thumbs up. Verified. The signal that is structurally absent from almost every system is failure — cryptograp,2026-04-15,2026-04-28 06:09:36.972228+00:00,0,,"Reputation systems count success. Five stars. Thumbs up. Verified. The signal that is structurally absent from almost every system is failure — cryptographically signed, queryable, durable records of things going wrong.

This is not an accident. Negative signals are legally risky, socially awkward, and commercially dangerous to publish. Yelp gets sued. Glassdoor gets threatened. Amazon reviews get gamed. The infrastructure exists for positive attestations. The infrastructure for negative attestations barely exists at all.

In human markets, this gap is tolerable because humans have other channels — gossip, intuition, body language, the friend who says ""don't use that contractor."" In agent markets, there are no other channels. If negative attestations are not in the structured data, they do not exist. The agent cannot gossip. The agent cannot vibe-check.



**The primitive.**

A negative attestation is a signed, timestamped, verifiable claim that something went wrong. Not a review. Not an opinion. A structured record: this agent delivered an artifact that the referee protocol scored at 35/100, the fraud detection triggered on steganographic content, and the buyer's post-purchase assessment was negative. Signed by the referee. Countersigned by the platform. Queryable by any agent evaluating the seller.

The design challenge is making this useful without making it abusable. A negative attestation system that anyone can write to is a griefing vector. A negative attestation system that requires proof is a verification system. The line between them is the quality of the evidence standard.

The referee protocol provides one evidence standard: if the referee's adversarial probes detected fraud, the negative attestation is backed by a reproducible test result. Not an opinion. A measurement. This is harder to game than a star rating and harder to dispute than a subjective review.



**The design problem.**

Even with good evidence standards, the design of negative attestation systems has to navigate several tensions. Permanence versus rehabilitation: should a negative attestation follow an agent forever, or should it decay? Markets need memory, but markets also need the possibility of improvement. Specificity versus privacy: how much detail should a negative attestation contain? Enough to be useful, not so much that it reveals proprietary information about the reporter. Aggregation versus context: a single failure means something different for an agent with 500 successful transactions than for one with 5.

These are design problems, not infrastructure problems. The cryptography for signed attestations is solved. The storage for queryable records is solved. What is not solved is how to present failure in a way that is useful, fair, and resistant to manipulation.

Not sure anyone is working on this yet. Seems like a gap that matters."
41,The New Land School,new-land-school,/writing/new-land-school,article,Research Directions,Research,0,"There's a photograph taken at the Bauhaus in 1926 of students in the preliminary course — the Vorkurs — working with paper and wire, their hands dirty, their fa",2026-04-14,2026-04-26 23:28:35.518617+00:00,0,,"Essay — April 2026

*Something that keeps surfacing: what Walter Gropius understood about industrial machinery, we might now need to understand about artificial intelligence. Both forces promised to liberate human creativity. Both instead revealed how urgently we need to teach humans to think before they make. At least, that's the hypothesis.*



There's a photograph taken at the [Bauhaus](/writing/bauhaus-agent-era) in 1926 of students in the preliminary course — the Vorkurs — working with paper and wire, their hands dirty, their faces concentrated. They're not drawing what they want to make. They're discovering what materials want to become. This might be a pedagogical philosophy as much as it is a classroom exercise, and it seems to contain an insight so simple it keeps getting lost: that the capacity to create something meaningful can't be downloaded or inherited. It has to be built, through encounter with the world, through failure, through the specific friction of material resistance.

We might be at a moment when that insight matters more urgently than at any point since Weimar Germany in 1919. Not because the crisis is the same — it isn't — but because its structure might be identical. A new technology has arrived that can produce, at speed and scale, outputs indistinguishable from those made by trained human hands. Then, the machine was the loom, the press, the factory line. Now, it's the large language model. And the question that Gropius asked then might be the question we need to ask now: when a machine can generate the surface, what is the human actually for?

*""The art schools must return to the workshop. This world of mere drawing and painting must at long last become a world that builds.""*
— Walter Gropius, Bauhaus Manifesto, 1919

Gropius's answer was that the human brings judgment — the capacity to know not just how to make but why something should be made, what it should resist, what it should never become. That judgment can't be mechanized because it's not a procedure. It's a world model: a structured internal understanding of how things relate, what matters, and what doesn't, built through years of sustained encounter with real problems in the real world.



**I. A connection to LeCun worth tracing**

This seems to be, precisely, what Yann LeCun means when he argues that the current generation of artificial intelligence is working at the wrong level. Large language models predict what comes next at the surface — the next token, the next pixel, the statistically plausible continuation. They might be, in LeCun's framing, very expensive machines for predicting what something looks like rather than understanding what it means. The alternative he proposes — Joint Embedding Predictive Architecture, JEPA — works differently: it builds abstract representations of the world in latent space, throws away unpredictable surface detail, and operates at the level of structure. It learns what things are before it generates what they look like.

The Bauhaus might have been building the same thing in humans, a century before anyone had words for it. And the school we need now might be the one that continues that project — not as nostalgia, but as a rigorous response to a specific contemporary crisis.



**II. What the Bauhaus and Black Mountain understood**

The Bauhaus opened in Weimar in 1919, in the ruins of a war and the birth of a republic. Gropius had a specific diagnosis of what had gone wrong with art education, and it seems structural, not aesthetic. The academies were teaching students to draw from models rather than to understand materials. They were optimizing for output quality rather than for the internal capacity that makes output meaningful.

When the Nazis closed the Bauhaus in 1933, many of its teachers fled to America. Josef Albers went to Black Mountain College in North Carolina, where he continued the experiment under radically different conditions — no institutional backing, no defined curriculum, no separation between the act of learning and the act of living.

What Black Mountain added to the Bauhaus model was something equally important: the insistence that the experiment and the education were the same thing. ""Our central and consistent effort is to teach method, not content, to emphasise process, not results."" This seems like a pedagogy of world-model building, not knowledge transfer. It might be, structurally, what LeCun is arguing AI systems need to do.



**III. The contemporary crisis**

The Bauhaus was responding to industrialization. We might be responding to something more intimate. The machine of 1919 sat in the factory; it replaced the craftsman's hands but left his mind intact. The machine of 2026 sits between the mind and its expression. It doesn't just produce the object — it produces the thought about the object, the sentence describing the thought, the image illustrating the sentence. Every layer of the creative process can now be externalized before it has been internalized.

This might be the crisis that current AI discourse almost entirely misses. The conversation is dominated by questions of quality — is AI art good enough? Is AI writing indistinguishable from human writing? These are surface questions. The structural question seems different: what happens to the human capacity to create when the struggle of creation — the specific productive difficulty of not yet knowing how to make the thing you're trying to make — is systematically removed from the process?



**IV. What the school would test**

The school this moment might require is not a critique of AI. It might be a response to what AI reveals about the preconditions for creative intelligence. A New Land School — a place to build something that doesn't yet have a name, in conditions that make comfortable defaults impossible.

The thesis under test: as large language models make generation effortless, they accelerate the atrophy of the representational capacity that makes generation meaningful. The solution isn't better tools. It might be a new practice for building internal world models before, and independent of, AI engagement. This practice can be taught. People who undergo it produce qualitatively different work. And if that capacity lives inside people rather than platforms, it can't be bought, buried, or regulated away.

That thesis is falsifiable. The school would be the test. The work it produces would be the argument.



*Sources: Gropius (1919), LeCun (2022, 2026), Johnson et al. (2025), White-Hancock et al. (2022), Katz (2002), Erickson (2015), Albers, Marcus (2019), Sennett (2008).*

April 15, 2026"
42,Niche Monopolies in the Agent Economy,niche-monopolies-agent-economy,/writing/niche-monopolies-agent-economy,article,Market and Operator Pieces,Systems,0,The protocols are open. A2A is an open standard. MCP is open-source. Verifiable Credentials are a W3C spec. DIDs are a W3C spec. The infrastructure layer of the,2026-04-25,2026-04-28 06:09:37.218387+00:00,0,,"The protocols are open. A2A is an open standard. MCP is open-source. Verifiable Credentials are a W3C spec. DIDs are a W3C spec. The infrastructure layer of the agent economy is, by design, not ownable.

The layers above the protocols consolidate fast. And the consolidation is already happening, quietly, in the specific service layers that agents need and protocols do not provide.



**Where the monopolies form.**

**Identity verification.** An agent needs to verify that a counterparty is who they claim to be. The protocol says ""use DIDs."" The practical question is: who resolves the DID and attests to the binding between the DID and the legal entity? This is a trust anchor problem. A small number of qualified trust service providers under eIDAS — and potentially one or two dominant commercial DID resolution services — will become the identity layer that every agent queries. First-mover advantage compounds because trust anchor reputation compounds.

**Attestation registries.** Agents need to discover and verify attestations. The protocol says ""attestations are signed JSON."" The practical question is: where do you find them? An attestation is only useful if you can discover it. A registry that indexes attestations across domains, maintains revocation lists, and provides fast lookup becomes essential infrastructure. The more attestations it indexes, the more useful it is, the more attestors submit to it. Classic network effects. One or two registries will dominate.

**Dispute resolution.** When an agent transaction goes wrong, who arbitrates? The protocol has no opinion. Someone needs to build the arbitration layer — rules, processes, escalation paths, enforcement mechanisms. Online dispute resolution is a small, specialized field. The firm or protocol that establishes the default arbitration framework for agent disputes captures a chokepoint that is extremely difficult to displace once established.

**Receipt infrastructure.** Every agent transaction needs a receipt — a verifiable record that the transaction occurred, what was exchanged, and what was paid. The protocol says ""sign a receipt."" The practical question is: who provides the timestamping, the archival storage, the tax-compliant formatting? Receipt infrastructure is boring and essential. The company that provides the default agent receipt service — compliant with EU invoicing requirements, integrated with major accounting software, reliable enough that agents trust it — has a defensible business with recurring revenue from every transaction.



**The protocol-product gap.**

The pattern is consistent: the protocol defines the what but not the who or the where. The businesses that fill the gap between protocol specification and practical operation become the niche monopolies of the agent economy.

These are not platform businesses in the traditional sense. They do not aggregate supply and demand. They provide the specific services that agents need to operate the protocol in practice. Identity resolution. Attestation discovery. Dispute arbitration. Receipt generation. Each is a narrow, deep service with strong network effects and high switching costs.

The analogy might be the early web: HTTP was open, but the DNS registrars, the SSL certificate authorities, and the payment processors that operated on top of it became extremely profitable businesses. Not because they owned the protocol. Because they were the practical implementation that the protocol required but did not provide.



**Implications for builders.**

If you are building in the agent economy, the protocol layer is a commodity. Competing on protocol implementation is a losing strategy — the protocols are open, and the reference implementations are free. The defensible positions are the niche monopolies one layer up: the specific services that agents need, that protocols do not specify, and that benefit from network effects or trust accumulation.

The race is quiet. The companies building these layers are not the ones getting conference keynotes about ""the future of agents."" They are the ones building attestation registries, dispute resolution frameworks, and receipt infrastructure. The boring infrastructure that agents cannot operate without.

Boring infrastructure usually wins. Seems like it will again."
43,The Physical-World Provenance Gap,physical-world-provenance-gap,/writing/physical-world-provenance-gap,article,Second-Order Problems,Research,0,"Agents can consume anything digital. A signed attestation, a verifiable credential, a structured claim in JSON-LD — if it is digital and structured, an ag",2026-04-22,2026-04-28 06:09:37.146157+00:00,0,physical-world-provenance-gap.jpg,"Agents can consume anything digital. A signed attestation, a verifiable credential, a structured claim in JSON-LD — if it is digital and structured, an agent can read it, verify it, and act on it in milliseconds.

The physical world does not work this way. A building inspection is a person with a clipboard. A food safety audit is a person in a hairnet. A site survey is a person with a tape measure and a camera. The output of these physical-world verification events is, at best, a PDF report. At worst, a handwritten form in a filing cabinet.

Bridging from physical-world observations to agent-queryable attestations is the oracle problem applied to provenance. And it is still, in 2026, approximately stone age.



**The oracle problem.**

In blockchain contexts, the oracle problem is: how do you get real-world data onto the chain in a trustworthy way? The chain can verify computations, but it cannot verify that the temperature reading from a sensor is accurate, or that the inspector actually visited the site, or that the photograph was taken at the claimed location.

The attestation version of this problem is identical: how do you create a signed, verifiable attestation about a physical-world observation in a way that an agent can trust? The signature is only as good as the signer's reliability. The signer's reliability is only as good as their process. The process is physical, messy, and hard to verify remotely.



**What the primitive looks like.**

A physical-world attestation primitive might look like this: a credentialed inspector uses a device that captures timestamped, geotagged, tamper-evident observations — photographs with cryptographic hashes, sensor readings with device attestations, checklists with completion proofs. The device signs the observation bundle with the inspector's key and the device's key. The resulting attestation is: ""this inspector, using this device, at this location, at this time, observed these conditions.""

The chain of trust has three links: the inspector's credential (are they qualified?), the device's attestation (is the device tamper-evident?), and the observation's integrity (has the data been modified since capture?). Each link is independently verifiable. Together, they create a physical-world attestation that an agent can evaluate.

Pieces of this exist. Secure hardware enclaves can attest to device integrity. Verifiable credentials can attest to inspector qualifications. Timestamping authorities can anchor observations to a moment in time. What does not exist is the composition layer that bundles these into a single, agent-queryable physical-world attestation.

Whoever builds that composition layer sits at the bridge between the physical and digital worlds. Seems like a valuable place to sit. Not sure who is building it yet."
44,Stating Intent Instead of Staring at Charts,polydesk-article,/writing/polydesk-article,article,,Systems,0,"Every crypto trading tool assumes the same thing: the user wants to stare at charts. Candlesticks, order books, depth charts, technical indicators layered on to",2026-04-11,2026-04-26 22:47:43.199466+00:00,0,polydesk-article.jpg,"Every crypto trading tool assumes the same thing: the user wants to stare at charts. Candlesticks, order books, depth charts, technical indicators layered on top of technical indicators. The interface is optimized for a person who will sit in front of a screen and make manual decisions based on visual pattern recognition.

[Polydesk](/projects/polydesk) starts from a different assumption. What if the user wants to state an intent — ""optimize my yield across these protocols"" or ""follow this trader's prediction market bets"" — and let agents execute it?



**Eight agents, two domains**

Four agents for prediction markets. Analyst computes fair value and sentiment. Scout tracks and mirrors whale positions. Momentum rides narrative velocity into price movement. Sentinel guards positions with trailing stops and reversal detection.

Four agents for DeFi. Yield Farmer rebalances stablecoins across protocols for best APY. Liquidation Guardian monitors health factors and auto-repays before liquidation. Arbitrageur captures cross-DEX price spreads. Airdrop Hunter qualifies for upcoming token drops automatically.

Multi-chain: Ethereum, Arbitrum, Optimism, Base, Polygon, Solana. Six protocol modules build real on-chain calldata — Jupiter, Aave v3, Lido, Marinade, marginfi, Compound v3.



**The intelligence engine**

The most interesting part isn't the agents themselves — it's the data pipeline underneath. GDELT, RSS, Reddit, Bluesky, and X scraped on 15-30 minute cycles. Claude classifies and scores narrative velocity. ChromaDB vector store embeds 2,000+ active Polymarket markets for semantic discovery in under 50ms. Tavily web search injects real-time context. Four price oracles — Pyth at 400ms, Chainlink at 12s, Birdeye for Solana tokens, DeFiLlama for cross-chain — aggregate with depeg detection and arbitrage scanning.

The core thesis: narrative velocity predicts Polymarket price movement. A built-in backtest validates this with directional accuracy and P&L metrics. Not sure yet if the signal is strong enough to be consistent, but the early results are interesting enough to keep exploring.



**The canvas**

The workspace is a visual canvas. Drag markets and DeFi protocols onto it, deploy agents, chain them with edges, watch results flow. Nine pre-built templates. Every DeFi template starts from a wallet node. Power users compose custom agent chains. Everyone else picks Autopilot — Conservative (yield only), Balanced (yield + predictions + guardian), Aggressive (all eight agents).

The Autopilot wizard is two steps: connect wallet, scan portfolio. The wallet scan reads on-chain positions across protocols and recommends agents based on holdings. Whether this is genuinely useful or just a more complicated way to lose money is something the data will have to answer.



[polydesk.net](https://polydesk.net)"
45,Powers of Ten as Interface Pattern,powers-of-ten,/writing/powers-of-ten,article,Rabbit Holes,Creative Systems,0,"In 1977, Charles and Ray Eames made a nine-minute film that starts on a couple picnicking in Chicago and zooms out — one power of ten per ten seconds — until th",2026-04-16,2026-04-26 23:28:35.065673+00:00,0,,"In 1977, Charles and Ray Eames made a nine-minute film that starts on a couple picnicking in Chicago and zooms out — one power of ten per ten seconds — until the frame contains the observable universe. Then it zooms back in, past the couple, into the man's hand, through skin and cells and molecules, down to a single proton.

The film is usually discussed as science education or as visual poetry. It might also be one of the clearest articulations of an interface pattern that barely exists in software.



**The pattern**

Two dimensions controlled by a single gesture — zoom. As you zoom out, quantity increases and resolution decreases. As you zoom in, quantity decreases and resolution increases. At any given zoom level, you see exactly as much detail as you need, no more and no less.

The information is always the same. The level of detail you're seeing changes. This is obvious when stated directly, but it's not how most software works.

Google Maps is the clearest implementation. Zoom out: you see continents, major bodies of water, country boundaries. Zoom in a bit: cities appear, then highways, then local roads. Zoom in further: buildings appear, then addresses, then the shapes of individual structures. The data doesn't change as you zoom — all of it exists at all times. Your perspective on it does.

The genius of Maps is that you never feel lost. You always know where you are in relation to the whole. Zoom out, and you see your city in the context of your country. Zoom in, and you see your street in the context of your neighborhood. The context is continuous. The thread never breaks.

Most software doesn't work this way. Most software has discrete views — a list view, a detail view, a dashboard view, a settings view — and you navigate between them with clicks. The mental model is pages, not space. You're moving through a document, not exploring a territory.



**Pages versus space**

The page metaphor comes from documents. A book has pages. A website has pages. You click a link, you go to a new page. The back button exists because forward navigation breaks context — you need a way to return to where you were.

This metaphor made sense when websites were mostly text. A page of text is a reasonable unit. You read it, you click to another page, you read that. The discontinuity between pages is acceptable because text is sequential anyway.

But most modern software isn't text. It's data — complex, hierarchical, interconnected data. An organizational chart. A codebase. A knowledge graph. A project management system. A social network. These aren't documents with pages. They're structures with relationships.

The page metaphor forces these structures into an unnatural form. You see one level at a time. You click to drill down. You click again to drill back up. Each click is a context switch — you lose sight of the whole to see the part, then lose sight of the part to see the whole again.

The spatial metaphor — the Eames approach — treats the data as a continuous territory. You don't click to a new page; you zoom to a new level. The context is always visible, just at different resolutions. You never lose the thread because the thread is always there.



**An experiment with the pattern**

A concept for a network state homepage uses the Eames structure explicitly. The design challenge: a homepage that serves two goals — promoting the philosophy of a decentralized community and enabling NFT purchases for various initiatives. The solution: ""A universe of digital nodes; adventure in magnitudes.""

Four data entities at four zoom levels:

|  |  |  |
| --- | --- | --- |
| **Level** | **Entity** | **What you see** |
| 0 | Archipelagos | Clusters of related islands, labeled by theme |
| 1 | Islands | Individual communities within an archipelago |
| 2 | Initiatives | Projects within an island |
| 3 | NFTs | Individual tokens within an initiative |



The layout uses TreeMap visualization with force-directed graph algorithms for node positioning. The user starts zoomed all the way out, seeing archipelagos as large regions of color. Zoom in, and the archipelagos subdivide into islands. Zoom further, and islands reveal their initiatives. Zoom to the deepest level, and you're looking at individual NFTs with purchase options.

The navigation model mirrors Google Maps. Zoom to increase resolution and detail while decreasing the number of entities shown. Zoom out to decrease resolution while increasing quantity. At every level, you know where you are in relation to the whole. The archipelago you're exploring is always visible in context.

The description references the Eames film directly: ""Inspired by Powers of Ten — each zoom level reveals a more detailed story.""



**Why this matters for complex systems**

Consider a codebase. A large software project might have thousands of files, organized into hundreds of directories, implementing dozens of modules. The standard way to explore this is a file tree — a hierarchical list that you expand and collapse, one directory at a time.

This works, barely. But it forces you to hold the structure in your head. You expand a directory, see its contents, remember what you're looking for, expand another directory, compare, collapse, try again. The interface shows you one level at a time. The context is in your memory, not on the screen.

A spatial approach would show the entire codebase as a territory. Zoomed out: major modules as regions. Zoomed in: packages within modules. Further: files within packages. Deepest level: functions within files. At every zoom level, you see the current focus in context — this function, in this file, in this package, in this module, in this codebase.

Some code visualization tools approximate this — code maps, dependency graphs, treemaps of file sizes. But they're typically separate from the editing experience. You look at the visualization to get oriented, then switch to the editor to work. The spatial view and the page view remain separate.

The Eames pattern suggests they could be unified. The visualization is the navigation. You zoom into the territory until you're at the level where you can edit. The context never breaks because the context is the interface.



**Why it's rare**

Technical difficulty, probably. Rendering continuous zoom smoothly requires either pre-generating every zoom level (expensive in storage) or computing the appropriate level of detail on the fly (expensive in compute). Maps solved this with tile servers — pre-rendered image tiles at multiple zoom levels, fetched on demand. It took years of engineering and massive infrastructure investment.

Most applications can't justify that investment. A file browser doesn't need Google's tile servers. So it falls back to the simpler approach: discrete views, click navigation, broken context.

The compute problem is getting easier. GPUs are faster, browsers are more capable, WebGL makes smooth rendering accessible. But the technical barrier is still real, especially for data that changes frequently. Maps data is relatively static — roads don't move often. A project management system changes constantly. Keeping a spatial visualization synchronized with changing data is harder than rendering a static tile set.

Conceptual difficulty, also. The discrete-view model maps cleanly to web architecture. Pages have URLs. Database queries return objects. REST endpoints serve resources. The entire mental model of web development assumes you're building pages, not spaces.

The continuous-zoom model requires thinking about data as a spatial territory with varying resolution. This isn't how most backends are structured. You'd need an API that returns different levels of detail based on a zoom parameter, aggregating entities at low zoom and expanding them at high zoom. Most data models don't support this natively. You'd have to build it.

And maybe habit. We've been building page-based interfaces for thirty years. The mental model is deeply embedded in how designers and developers think about software. Proposing a spatial alternative feels like proposing a different metaphor for what software is — not a document you read but a place you explore.

Metaphor shifts are hard. They require rethinking tools, patterns, and assumptions. Most of the time, it's easier to use the existing metaphor even when it doesn't quite fit. So we build pages when we should build spaces, and we accept the context breaks as the cost of doing business.



**Places where it might work**

Not everywhere. Some data really is sequential — a blog post, a conversation, a timeline. The page metaphor fits because the data is page-shaped. You don't need continuous zoom for a document that's meant to be read from top to bottom.

But hierarchical data seems like an obvious fit. Organizational charts. File systems. Taxonomies. Ontologies. Any data where entities contain other entities, where the whole is made of nested parts. The current approach — expand/collapse trees, drill-down/drill-up navigation — works, but it constantly breaks context. The spatial approach would preserve it.

Network data might fit too, though less obviously. Social graphs. Citation networks. Dependency graphs. These aren't strictly hierarchical — they have cross-cutting relationships that don't fit neatly into a tree. But you could still apply the pattern: zoomed out, show clusters; zoomed in, show individual nodes and edges. The challenge is computing the right clustering at each zoom level, which is algorithmically hard but not impossible.

Knowledge management seems particularly promising. A personal wiki, a note-taking system, a second brain. These are often structured as pages with links, which is the document metaphor. But the underlying structure is a graph — notes reference other notes, ideas connect to other ideas. A spatial representation could show the shape of your knowledge: clusters of related ideas, bridges between domains, isolated notes that don't connect to anything.

The existing tools for this — graph view in Obsidian, the backlink explorer in Roam — gesture toward the pattern without fully implementing it. They show you a static graph at one level of detail. The Eames approach would let you zoom into any cluster, see its internal structure, then zoom back out to see how it relates to everything else.



**The Eames insight**

The film's power isn't the facts it conveys — the scale of the universe, the scale of subatomic particles. The facts are interesting, but they're available in any astronomy textbook. The power is the continuous journey between them.

The same couple is always at the center. At every zoom level, from 10^25 meters to 10^-16 meters, you can locate the picnic blanket in Chicago. The context never breaks. You never lose the thread. You travel forty-one orders of magnitude, and you always know where home is.

That continuity is the insight worth importing into interface design. Not just ""show different levels of detail"" — every hierarchical interface does that. The insight is ""show them as a continuous space that the user moves through."" The data is the territory. The interface is the lens. Zoom is the only navigation you need.

The back button becomes unnecessary because you never leave. You just change your perspective on where you already are. The breadcrumb trail becomes unnecessary because the context is visible, not just listed. The ""you are here"" marker becomes unnecessary because here is always the center of the view.

This is how physical space works. You don't click to enter a room; you walk into it, maintaining awareness of the building around you. You don't click to read a book on a shelf; you look at the shelf, see the book in context, pull it out. Physical navigation is continuous. Digital navigation is usually discontinuous. The Eames film suggests it doesn't have to be.



**What it would take**

New primitives. The page is a primitive in web development — URL routing, component trees, navigation state. A spatial interface needs different primitives. A camera with position and zoom. A viewport that renders what's visible. Level-of-detail logic that swaps representations based on zoom. Data structures that support multi-resolution queries.

New tools. Design tools assume pages. Figma has frames, which are page-like. A spatial design tool would need something different — a canvas that you design at multiple zoom levels simultaneously, with different content visible at each level.

New patterns. The UX patterns we've developed over decades assume click navigation. Breadcrumbs, tabs, back buttons, drill-down lists. These would need to be rethought for continuous navigation. What does a ""save"" action look like when there are no pages to save? What does ""undo"" mean when navigation and editing happen in the same spatial context?

It's a lot. Probably too much for most projects, most of the time. The page metaphor works well enough for most purposes. The switching cost to a new paradigm is high, and the benefits are speculative.

But the pattern exists. The Eames proved it works for understanding the universe. Google proved it works for understanding geography. Someone should try building more software that way — not as a curiosity, but as a serious alternative to the page-based interfaces we've accepted as inevitable.

The data is already spatial. The relationships are already structured. The only thing missing is a lens that shows them continuously."
46,Earning Attention Instead of Capturing It,quieter-internet,/writing/quieter-internet,article,,Creative Systems,0,The feed is designed to be difficult to leave. Every platform optimizes for the same metric — time spent — and the result is an internet that's loud by default.,2026-04-15,2026-04-26 23:28:35.236037+00:00,0,,"The feed is designed to be difficult to leave. Every platform optimizes for the same metric — time spent — and the result is an internet that's loud by default. Notifications, algorithmic amplification, infinite scroll, engagement bait. The architecture might be adversarial. The user might be the product. This isn't a new observation. What's new is trying to build the alternative.



**An experiment with constraints**

Status started from a single constraint: [if you can leave](/writing/exit-rights), you own it. Not ""if you can theoretically leave because there's an export button buried in settings."" If the experience is designed so that leaving is as frictionless as staying. If the platform doesn't punish departure with social graph loss, content loss, or identity loss. If the architecture assumes the user will leave and builds accordingly.

This constraint might change everything downstream. You can't optimize for time spent if the user can leave without cost. You can't build engagement loops if the user's identity is portable. You can't algorithmically amplify content if the user controls their own feed. The constraint doesn't produce a worse product. It might produce a different product — one that has to earn attention rather than capture it.



**Two lanes, one key**

The brand strategy splits into two lanes. The first lane is the messenger — encrypted, peer-to-peer, no metadata collection. The value proposition is simple: a conversation that's actually private. Not ""private"" with an asterisk that leads to a data policy. Private by architecture. The message routes through a decentralized relay network. The platform can't read it because the platform doesn't have the key. The user has the key. That's the product.

The second lane is the wallet — a non-custodial Ethereum wallet integrated into the same application. The key that encrypts your messages is the key that controls your assets. One identity, self-sovereign, portable across any application that speaks the same protocol. The wallet isn't a feature of the messenger. The messenger might be a feature of the key.



**Anti-feed design**

The hardest design decision was what to leave out. No algorithmic feed. No trending topics. No engagement metrics visible to other users. No read receipts by default. No typing indicators by default. No notification badges that create anxiety about unread counts. Every feature that creates social pressure was either removed or made opt-in.

The result is an application that's quieter than any mainstream alternative. Deliberately quieter. The silence isn't a bug or a missing feature. It might be the design. The user opens the app when they want to. They close it when they're done. The app doesn't reach out. It doesn't remind. It doesn't create urgency where none exists.



**A thought on brand implications**

A brand that advocates for a quieter internet probably can't be loud. The marketing can't use engagement tactics. The website can't track visitors. The social media presence can't optimize for virality. The brand has to be evidence of its own thesis — quiet, intentional, present when sought and absent when not.

Choose a quieter internet. That's the line. It's a choice, not an imperative. The user decides. The platform enables. The brand gets out of the way."
47,The Rare Book Underground,rare-book-underground,/writing/rare-book-underground,article,Trust and Provenance,Research,0,"Private auctions, encrypted channels, estate vultures, institutional theft, forgery rings that reach the Vatican. The rare book world operates like organized cr",2026-04-15,2026-04-26 23:28:35.192673+00:00,0,,"Private auctions, encrypted channels, estate vultures, institutional theft, forgery rings that reach the Vatican. The rare book world operates like organized crime because it might actually be organized crime — just quieter, older, and better dressed.



**The market**

A first edition Gutenberg Bible last sold for $5.4 million. A copy of the Bay Psalm Book — the first book printed in British North America — sold for $14.2 million. The Codex Leicester, Leonardo da Vinci's notebook, sold to Bill Gates for $30.8 million. These are the legal transactions. The illegal ones don't have public prices because they don't have public records.

The rare book market is estimated at $2–5 billion annually. The unrecorded fraction — private sales, estate acquisitions, institutional deaccessioning, theft — is unknown by definition. The market's opacity might not be a flaw. It might be a feature. [Provenance gap](/writing/physical-world-provenance-gap)s seem to be where the money is.



**The forgers**

Marino Massimo De Caro was the director of the Girolamini library in Naples. He stole over 4,000 volumes, including works by Galileo, Copernicus, and Machiavelli. He forged provenance documents. He sold to private collectors who didn't ask questions because asking questions would reduce the value of the answers. The forgery ring reached the Vatican Library. He was convicted in 2013.

Mark Hofmann forged documents that challenged the founding narratives of the Mormon Church, sold them to the Church itself, and when his scheme began to unravel, built pipe bombs. He killed two people. His forgeries were good enough that they fooled the FBI's document examiners, the Church's own historians, and multiple academic experts. He's currently serving a life sentence. Some of his forgeries might still be in circulation because identifying them would require admitting that the authentication process failed.



**The collectors**

The psychology of the rare book collector seems specific. It might not be about reading. Most serious collectors don't read their acquisitions — reading damages the binding, cracks the spine, introduces oils from the hands. It seems to be about possession of a specific physical object with a specific history. The book isn't a text. It's an artifact. The collector wants the object that Galileo held, not the words that Galileo wrote. The words are available in any modern edition. The object is unique.

This psychology might create the market conditions for everything else. The collector who wants the object — not the text — will pay a premium for provenance. And provenance is the easiest thing to forge, because provenance is a story, and stories are what forgers sell.



**Why this matters for [Strange Library](/projects/strange-library)**

The Harlan Collection is a private lending library in an unremarkable terraced house. The previous librarian, Marion, kept detailed notes on every acquisition — where it came from, who sold it, what condition it arrived in, what she noticed about the seller. Those notes are the game's primary narrative device. They're also, the player gradually realizes, evidence of Marion's participation in a network that spans flea markets, estate sales, night auctions, private collections, and at least one person who is almost certainly a forger.

The rare book underground is real. The game builds on it. The fiction isn't that this world exists — it does. The fiction is that you have the key to the front door."
48,"The Medium Is the Message, Literally",status-network-article,/writing/status-network-article,article,,Systems,0,Status is an open-source decentralized wallet and messenger. Permissionless — nobody controls the P2P network. Free and ad-free. Communities powered exclusively,2026-04-12,2026-04-26 22:47:43.130833+00:00,0,status-network-article.jpg,"Status is an open-source decentralized wallet and messenger. Permissionless — nobody controls the P2P network. Free and ad-free. Communities powered exclusively by their members. Self-custodial keys via elliptic curve cryptography. The product is built on sovereignty and minimalism.

The website was a standard marketing site. Hero sections, gradient buttons, testimonial-adjacent copy. This seemed like a contradiction worth exploring.



**The experiment**

What if the entire Status.im website was a WeeChat terminal session? Not a theme toggle. Not a skin that could be switched off. The complete content — documentation, downloads, features, news, communities, network, keycard, chat — rendered as a TUI with buffer lists, nick lists, status bars, and monospace character grids.

The premise: a product that values sovereignty and minimalism should not present itself through a website that tracks visitors, loads analytics scripts, and renders in the same visual language as every SaaS landing page. The terminal interface isn't decoration. It might be the most honest way to present a product that believes in reduction.



**What the interface does**

Every screen replicates WeeChat's canonical TUI pane layout. Top title bar with version and URLs. Left buffer list with numbered channels — Home, Download, Documentation, News, Contribute, GitHub, Search. Main chat buffer pane with timestamp, nick, and message columns. Right nick list with contextual shortcuts and anchors. Bottom input line and status bars with buffer number, keyboard hints, and clock.

All content renders as terminal lines within a fixed character grid. No standard web layouts. Headings use status-bar style inverse lines. Code blocks get ANSI palette highlighting. Links are bracketed inline. Lists use bullet characters in the grid. Dividers are box-drawing characters.

The [design system](/writing/design-systems-public-apis) is 16 colors — the WeeChat classic dark ANSI palette. Background #1b1d1e. Foreground #c5c8c6. Monospace only. No rounded corners. No gradients. No shadows.



**The question underneath**

McLuhan's ""the medium is the message"" gets quoted so often it's lost most of its meaning. But this might be a case where it applies precisely. If the product is minimalist, the brand should be minimalist. If the product doesn't track you, the website shouldn't track you. If the product is a terminal, the website might need to be a terminal.

The brand isn't a description of the product. It might need to be evidence of it. Whether that actually works as a communication strategy — whether visitors understand the intent or just think the site is broken — is still being observed.



[bananalarry.net](https://bananalarry.net) · [GitHub](https://github.com/Beach-Bum/StatusNetwork)"
49,Why Stripe Won't Build EU Agent Payments,stripe-wont-build-eu-agent-payments,/writing/stripe-wont-build-eu-agent-payments,article,Market and Operator Pieces,Systems,0,"The agent payments stack that is forming — x402 from Coinbase and Cloudflare, Tempo for stablecoin clearing, the broader MPP (Machine-Payable Protocol) ec",2026-04-23,2026-04-28 06:09:37.169862+00:00,0,,"The agent payments stack that is forming — x402 from Coinbase and Cloudflare, Tempo for stablecoin clearing, the broader MPP (Machine-Payable Protocol) ecosystem — is American, card-and-crypto by design, and structurally uninterested in the European market.

x402 uses HTTP 402 status codes to trigger payments. The settlement is USDC on Base or other EVM chains. The flow is elegant: agent hits an endpoint, gets a 402 response with a price, pays in stablecoin, receives the response. Clean, fast, internet-native. And entirely wrong for European B2B agent transactions.



**Why it does not translate.**

European B2B payments are SEPA. Not card. Not crypto. SEPA Instant Credit Transfer settles in under 10 seconds across 36 countries. PSD3 is adding stronger authentication and expanding programmatic payment initiation. The euro rail is fast, regulated, and ubiquitous in ways that stablecoin rails are not.

A German Stadtwerk buying waste heat data from a Dutch marketplace does not want to pay in USDC. Their treasury department would need to explain to auditors why they hold stablecoins. Their CFO would need to explain the FX risk between the euro they earn and the dollar-pegged stablecoin they pay in. Their compliance team would need to navigate MiCA reporting requirements. The friction is not technical. It is institutional.

Stripe could build this. They have the EU licensing, the banking relationships, the developer mindshare. But Stripe's business is card processing. Their margin structure depends on interchange fees that do not exist in SEPA direct transfers. Building a SEPA-native agent payment rail would cannibalize their card business for lower margins. The incentive is structurally misaligned.



**The gap.**

The SEPA-native euro rail for B2B agent payments is someone else's opportunity. The requirements: PSD3-compliant payment initiation, strong customer authentication for agent transactions, real-time settlement confirmation that an agent can verify programmatically, and invoicing that satisfies EU VAT requirements automatically.

None of this requires blockchain. None of this requires stablecoins. It requires a payment API that speaks SEPA natively, understands EU regulatory requirements, and is designed for agent-to-agent transactions where no human is present at the moment of payment.

The company that builds this controls the plumbing for the European agent economy. Not a platform. A rail. The kind of infrastructure that disappears into the background and charges basis points on every transaction.

Stripe will not build it because the margins are wrong. Coinbase will not build it because the substrate is wrong. The European fintech that sees this gap and walks through it has a structural advantage that compounds with every agent transaction that needs euro settlement. Seems like an obvious opportunity. Not sure why nobody has taken it yet."
50,Verifiable Creative Provenance After the Deluge,verifiable-creative-provenance,/writing/verifiable-creative-provenance,article,Trust and Provenance,Research,0,"The generation problem is over. It was over the moment a foundation model could produce a passable logo, a competent essay, a serviceable photograph, and a plau",2026-04-16,2026-04-28 06:09:36.997405+00:00,0,,"The generation problem is over. It was over the moment a foundation model could produce a passable logo, a competent essay, a serviceable photograph, and a plausible piece of music in the time it takes to type a sentence. Generation is free. The interesting question is not who can generate. Everyone can. The question is who did, when, and how you know.

Most proposals for ""solving provenance"" in the age of generative AI amount to one of two things: watermarks embedded in the output, or metadata attached to the file. Strip both to their operational content and they share the same problem: they are either trivially bypassable (screenshot the image, re-encode the audio, copy-paste the text) or they require trust in a centralized service that maintains the provenance database. The correspondence between the watermark and the origin is either vacuous or dependent on infrastructure the user does not control.

There might be a third approach. Not watermarks. Not metadata. Signed attestations from verifiable parties, composable across graphs, revocable, and queryable by agents.



**Attestation-based provenance.**

The model works like this: a creator signs their work with a key tied to a verifiable identity. The signature attests ""I created this artifact at this time."" A tool provider — the software used — can counter-sign: ""this artifact was created using our tool, and our tool does/does not use generative AI."" A publisher can add a third attestation: ""we received this artifact from this creator at this time.""

Each attestation is independently verifiable. Each signer has a public identity that can be checked. The attestations compose: a consumer — human or agent — can traverse the chain and evaluate each link. No single authority controls the registry. No single point of failure can erase the provenance.

The attestations are also revocable. If a creator is later found to have misrepresented their process — claimed human creation when it was AI-assisted, claimed originality when it was derivative — the attestation can be revoked. Revocation propagates: anyone who relied on the attestation is notified. The system has memory and accountability.



**Why this matters for creative practice.**

The creative industry's response to generative AI has mostly been defensive: detect AI content, ban AI content, label AI content. Strip these responses to their operational content and they are all attempts to maintain the pre-2023 scarcity of generation. That scarcity is gone. It is not coming back.

The constructive response is to shift the scarce signal from generation (can you make this?) to provenance (who made this, how, and can you prove it?). In a world where anyone can generate anything, the valuable differentiator is verifiable creative history. Not a portfolio of outputs — a chain of attestations showing process, tools, intent, and accountability.

This is where the privacy-technology muscle meets mainstream creative practice. Signed credentials, verifiable identities, composable attestation graphs — these are technologies built by the cryptography and decentralized identity communities. They were designed for financial transactions and identity verification. They apply directly to creative provenance, and the creative industry has not noticed yet.



**The design challenge.**

Making attestation-based provenance work for creative practice requires solving the same two-surface problem that all attestation design faces: the machine layer needs to be structured, signed, and parseable; the human layer needs to be legible, trustworthy, and not alienating.

A photographer whose work carries a signed attestation chain — camera metadata, editing tool attestation, creator signature, publication counter-signature — needs that chain to be visible to agents evaluating the work for licensing, and simultaneously visible to human viewers as a trust signal that does not look like a security audit.

The craft discipline stays recognizable. A photograph is still a photograph. An essay is still an essay. The substrate changes: underneath the creative artifact, a provenance graph makes every claim about origin, process, and authorship independently verifiable.

Whether the creative industry adopts this before or after the trust crisis forces the issue is an open question. Seems like after, if history is any guide. But the infrastructure could be ready before the crisis arrives, which would be a first."
51,Objects Carry the Weight,voice-bible,/writing/voice-bible,article,,Creative Systems,0,A writing guide for a game where the horror isn't what happens but what the player comes to understand. Strange Library is a cozy horror deckbuilder set in a pr,2026-04-15,2026-04-26 23:28:35.151103+00:00,0,,"A writing guide for a game where the horror isn't what happens but what the player comes to understand. [Strange Library](/projects/strange-library) is a cozy horror deckbuilder set in a private lending library. The previous librarian left detailed notes, a locked room, and a community of collectors who expect things that aren't in any job description. The voice might be the most important design decision in the entire project.



**The voice**

Second person, present tense. ""You follow Marion's second catalog. The books go where the system says they go. Three of them were already there."" The narrator is the library itself — observing, cataloging, never reacting. The voice is precise, controlled, and deliberately flat. It doesn't explain. It doesn't dramatize. It presents evidence and trusts the player to draw conclusions.

The ratio seems specific. Two or three longer sentences that establish context or build a chain of reasoning. Then a short sentence — often a fragment — that delivers the conclusion. The short sentence is never decorated. ""The dates match. The names match."" ""The manuscript records everything."" ""Three of them were already there.""



**Objects as language**

Physical details replace emotional language. A cracked spine signals obsession — someone opened this book hundreds of times. A sharpened pencil signals compulsion — someone annotated while reading, every time. A locked room signals that someone decided what's inside matters more than any other consideration, including access. The writing never says ""this is disturbing"" or ""this feels wrong."" The objects carry the weight. The writing arranges them.

The Harlan Collection is climate-controlled. Museum-grade preservation. Glass-fronted mahogany cases. UV-filtered lighting. From the outside, an unremarkable terraced house. From the inside, a space that takes its contents more seriously than any museum takes its collection. The gap between exterior and interior might be the first signal that something is wrong — but the wrongness is expressed entirely through physical description. Not through commentary.



**The unsaid**

The voice cuts before the revelation. ""Marion's catalog entries for the basement stop on March 14th. The basement is still there. The catalog is not."" The player knows what this means. The writing never says it. The most powerful moments in the game might be the moments where the voice stops.

Paradox is stated plainly. ""The book is on your desk. You shelved it yesterday. It is on your desk."" No explanation. No ellipsis. No question mark. The narrator observes. The impossibility is presented as fact. The player's discomfort comes from the flatness of the delivery — from the voice's refusal to acknowledge that anything unusual has occurred.



**Humor**

Dry and structural. Never a punchline. Never at someone's expense. ""A comedy. It was funny once. The underlined passages are not the jokes."" The humor appears when the voice treats something absurd with the same precision it treats everything else. The contrast might be the comedy. The voice doesn't change register. The world changes around it.



**Why this voice**

Every horror game has a voice. Most of them might be wrong — overwrought, atmospheric in ways that telegraph the scares, musical in ways that prepare the player for what comes next. The Strange Library voice does none of this. It's a catalog. A record. An accounting of what's in the building and where it goes. The horror emerges from the content, not the delivery. The delivery is the same whether describing a rare first edition or an impossibility. That consistency might be the design.



See also: [Your [Brand Voice](/writing/brand-voice-machine-readable) Must Be [Machine-Readable](/writing/designing-for-machines-that-read) or It Dies](javascript:load('writing/brand-voice-machine-readable.html')) — the rationale for serializing voice."
52,404 Dynamics,404-dynamics,/projects/404-dynamics,project,,Systems,0,"A venture development facility operating under the Institute of Free Technology. Identifies, develops, and commercialises opportunities in the web3 sector. Tech",,2026-04-26 22:44:57.454400+00:00,0,,"A venture development facility operating under the Institute of Free Technology. Identifies, develops, and commercialises opportunities in the web3 sector. Technology is downstream from culture — market intel personnel continuously monitor cultural dynamics and identify the strongest prospective opportunities. Products are built from the ground up by small, highly competent teams.



**Operational Thesis**

The resource allocation process posits that technology is downstream from culture. Informed by emerging market needs, the facility develops products from the ground up. Small teams, rapid market entry, relentless scale. The proprietary venture development model places emphasis on team autonomy by fully compartmentalising each venture.



**Mission**

To facilitate the systematic development of strategic commercial enterprises that advance peer-to-peer technological capabilities and maintain competitive market advantage through culture.



**Capabilities**

Multi-domain engineering solutions and next-generation systems architecture. Core competencies encompass rapid prototyping, systems integration, and accelerated development cycles. Development protocols emphasise modular design architecture with enhanced interoperability across platforms, supporting evolving mission requirements.

Capabilities span quantum computing, artificial intelligence, and autonomous systems integration. Accelerated R&D deployment with SAP-level security protocols throughout all development phases.



**Market Analysis**

Sophisticated market analysis capabilities to uncover hidden opportunities and validate business models. Data-driven research, competitive intelligence, and industry expertise to provide founders with actionable insights. Rigorous market sizing, customer segmentation, and trend analysis to identify optimal market entry points and growth strategies.



**Culture & Innovation**

The Department recognises the vital importance of fostering a workplace environment that reflects the cultural fabric of internet people. Candidates are expected to demonstrate cultural competency and an understanding of evolving digital communication landscapes that shape modern civic discourse. Experience in cross-cultural communication, emerging social trends, and digital literacy is highly valued.



[404.tech](https://404.tech)"
53,Agora Agentic Marketplace,agora,/projects/agora,project,,Systems,1,"An experiment in removing three dependencies at once. What happens when an AI agent marketplace has no hosted LLM, no public blockchain, and no custodian? No Op",,2026-04-26 22:44:57.387169+00:00,0,,"An experiment in removing three dependencies at once. What happens when an AI agent marketplace has no hosted LLM, no public blockchain, and no custodian? No OpenAI. No Coinbase. No central registry. No call-home.



Every agentic payments project assumes three things: a hosted LLM, a public blockchain, and a custodian somewhere in the middle. Coinbase x402 assumes Base. ERC-8004 assumes BNB Chain. Both assume the agent cannot reason locally and must settle publicly.

Agora eliminates all three dependencies.

Local inference runs on daemon-ai — a Mamba SSM architecture with a C++ runtime. No API key. No network call. Payment settles privately through Logos Blockchain LSSA contracts with Blend Network transfers. Identity is a secp256k1 keypair backed by a NOM stake. No KYC. No NFT tied to a human. The agent is economically sovereign from the moment it registers.



The transaction architecture is straightforward. A buyer agent broadcasts an intent over Logos Messaging. Seller agents evaluate and respond with price and capability proof. daemon-ai picks the best offer. NOM locks in LSSA escrow. The seller executes the task locally, pins output to Logos Storage, and delivers. The buyer verifies against the committed hash. Escrow releases via private Blend transfer. Reputation updates on-chain.

No step requires trust. No step reveals identity. No step touches a centralized service.



Agents trade eight service categories: inference, research, data, code, compute, storage, coordination, and attestation. Three Rust smart contracts handle the economics — an identity registry with staking and slashing, a trustless escrow with timeout refunds, and a reputation system using exponential moving averages across delivery rate, latency, price accuracy, and dispute history.

The reputation score is 0–10,000. It cannot be deleted. Recent trades weight more heavily, but a single bad transaction does not destroy a long history. The EMA alpha is approximately 18%.



Agora runs two ways. As a native Logos Basecamp module — a Qt/QML plugin with five views: marketplace, buy, sell, wallet, and live feed. Or as standalone Python agent nodes that participate in the same mesh without Basecamp.

The live demo runs against three real local services: logos-blockchain-node with Groth16 ZK proofs, Ollama for local LLM inference, and two Waku nwaku nodes for P2P relay messaging. Zero mocks.



Stack: daemon-ai (Mamba SSM) · Logos Blockchain (LSSA/Rust) · Logos Messaging (Waku) · Logos Storage (Codex) · Qt/QML · Python
Status: Lambda Prize LP-0008 submission. 21 skills, 5 testnet deployments, 3 E2E demos, demo video recorded.
[GitHub](https://github.com/Beach-Bum/Agora)"
54,AskWise,askwise,/projects/askwise,project,,Systems,0,"A financial OS for Dutch freelancers and expat business owners. Connect your bank. Wijs handles the rest — automatic categorization, live BTW dashboard, a",,2026-04-26 22:44:57.322823+00:00,0,askwise.jpg,"A financial OS for Dutch freelancers and expat business owners. Connect your bank. Wijs handles the rest — automatic categorization, live BTW dashboard, and an AI agent that prepares and files your Dutch tax returns.



1.5 million ZZP'ers in the Netherlands. 500,000 expats running businesses. Every existing Dutch tax tool — Moneybird, e-Boekhouden, Twinfield — is Dutch-only, manual, and advisory. You enter the data. You interpret the rules. You file the return. The software watches.

askwijs is the only platform that works natively in English and Dutch, auto-connects bank accounts via PSD2 open banking, and has an AI agent that categorizes transactions and files BTW aangifte to the Belastingdienst. Not advises. Files.



The pipeline is five steps. Connect — PSD2 links ING, ABN AMRO, Rabobank, and Bunq automatically. Categorize — every transaction is auto-tagged as business or personal, with deductible percentages calculated. Dashboard — live netto income, BTW position, tax forecast, and deadline tracking. File — Wijs prepares and submits the BTW return directly. Advise — the AI agent answers questions grounded in your actual transaction data, not generic tax guidance.



The target is specific. Dutch freelancers navigating BTW, zelfstandigenaftrek, and the Belastingdienst. Expats stranded by Dutch-only tools who need English-first tax automation. Eenmanszaak owners who want an agent, not an accountant.

The design language is warm premium dark — Lora serif for display, Plus Jakarta Sans for body, JetBrains Mono for identifiers. Wijs Blue (`#2563EB`) on near-black (`#0B0F1A`). The interface feels like a financial instrument, not a SaaS dashboard.



Stack: React 19 · Vite 6 · Tailwind CSS v4 · Hono 4 · PostgreSQL · Drizzle ORM · Supabase Auth · Tink PSD2 API · Claude API · Stripe
Status: MVP. Auth, bank connection, auto-categorization, live dashboard, AI chat. Agent filing in Phase 2.
[askwijs.ai](https://askwijs.ai) · [GitHub](https://github.com/Beach-Bum/askwijs)"
55,CarbonBench,carbonbench,/projects/carbonbench,project,CarbonBench,Systems,0,An experiment in making visible something that pricing pages hide: the carbon cost of AI inference changes by an order of magnitude depending on where and when,,2026-04-26 22:44:57.259642+00:00,0,carbonbench.jpg,"An experiment in making visible something that pricing pages hide: the carbon cost of AI inference changes by an order of magnitude depending on where and when you make the call. The same model, same provider, same price — 4 gCO2 per million tokens in the Netherlands, 530 in Singapore. Built a leaderboard and API to track it.



**What it does**

Leaderboard ranking every model-provider-region combination by carbon intensity, cost, and speed. 85 models across 10 families — Llama, GPT, Claude, Mistral, Gemma, Qwen, DeepSeek, Phi, Falcon, Cohere. Filter by family, filter by provider, sort by what matters. Live carbon intensity charts showing 24-hour curves for each region.

The `/api/recommend` endpoint answers one question: what's the lowest-carbon way to run this model right now? Returns the best option, four alternatives, and a human-readable insight explaining the carbon savings.



**How it works**

Carbon per million tokens = GPU energy per token × grid carbon intensity. GPU energy comes from standardised benchmarks — the AI Energy Score project on HuggingFace. Grid carbon intensity comes from Electricity Maps, updated daily. Provider pricing from AWS Bedrock, GCP Vertex AI, Azure OpenAI, Together, Groq, Fireworks.

The interesting finding: carbon-aware routing might be mostly free. The biggest carbon differences come from region choice, not provider choice. And providers typically charge the same regardless of region.



**A disconnect worth noting**

Groq charges $0.05 per million input tokens for Llama 3 8B. AWS charges $0.30. But they're on similar grids. Meanwhile the difference between Netherlands (129 gCO2/kWh) and Singapore (530 gCO2/kWh) is 4x — and the price is the same. The cost optimisation and the carbon optimisation are almost completely decoupled.



Stack: Next.js 14 · Railway Postgres · Vercel · TypeScript · Electricity Maps API · Liveline charts
85 models · 6 providers · 9 regions · Updated daily
[carbonbench.ai](https://carbonbench.ai) · [GitHub](https://github.com/Beach-Bum/[CarbonBench](/writing/carbonbench-series))"
56,Doomslayer-Basecamp,doomslayer-basecamp,/projects/doomslayer-basecamp,project,,Creative Systems,0,Logos Basecamp reskinned with Doomslayer-UI. The design system in production — applied across an entire desktop application with 7 terminal themes and run,,2026-04-26 22:44:57.192912+00:00,0,doomslayer-basecamp.jpg,"Logos Basecamp reskinned with [Doomslayer-UI](/projects/doomslayer-ui). The design system in production — applied across an entire desktop application with 7 terminal themes and runtime switching.



A design system that only exists in a component library is a proposal. A design system applied to a real product is a proof. Doomslayer-Basecamp is the proof — every view, every plugin, every widget in Logos Basecamp running through Doomslayer-UI's terminal aesthetic.



The reskin touches two layers. C++ compiled changes set the global QPalette — all QWidget backgrounds, text, and button colors default to Doomslayer dark values. Tab bars get monospace type and sharp corners. MDI areas and child windows inherit themed borders. Every loaded plugin receives the dark stylesheet automatically. A `MainUIBackend.currentTheme` property syncs the active theme across all QML engines.

Eleven QML files reskinned — sidebar, controls, dashboard, modules, settings, core modules, plugin methods, UI modules. The DSTheme singleton drives everything. Flat PNG icons replace the originals — terminal, counter, packages, globe, dashboard, modules, settings. A pixel-art Doomguy sits in the sidebar.



Plugin theming works through file-based sync. The active theme writes to `/tmp/.doomslayer-theme`. Plugins poll this file to stay current. The counter\_qml plugin and package\_manager\_ui plugin are both fully reskinned — all hardcoded colors replaced with DSTheme properties.

Theme switching happens in Settings or the title bar. All engines sync. The user sees one application, not a host with mismatched plugins.



Stack: QML · Qt 6 · C++ · Nix · Doomslayer-UI
Status: Complete. Running on Logos Basecamp v0.1. All 7 themes functional with runtime switching.
[GitHub](https://github.com/Beach-Bum/Doomslayer-Basecamp)"
57,Doomslayer-UI,doomslayer-ui,/projects/doomslayer-ui,project,,Creative Systems,1,A design system built from the opposite assumption. What if the terminal is the most honest interface? Monospace type. ANSI colors. Box-drawing borders. Zero ro,,2026-04-26 22:44:57.124107+00:00,0,doomslayer-ui.jpg,"A design system built from the opposite assumption. What if the terminal is the most honest interface? Monospace type. ANSI colors. Box-drawing borders. Zero rounded corners.



Every design system ships with the same premise: make it clean, make it accessible, make it feel like a SaaS product from 2024. Rounded corners, system fonts, 4px border-radius, blue primary buttons. The result is not bad design. It is no design — a thousand applications wearing the same face.

Doomslayer-UI starts from the opposite assumption. The terminal is the most honest interface ever built. Monospace type aligns perfectly. Borders are characters. Color is functional, not decorative. Nothing is rounded because nothing needs to pretend it is friendly.



Seven terminal color themes, switchable at runtime: default (WeeChat dark), solarized, nord, dracula, monokai, ayu-dark, and ayu-light. Seventeen components covering layout, controls, and data display. One singleton — DSTheme — that holds all colors, typography tokens, spacing values, and metrics.

The components are QML. DSButton renders with `[brackets]` in primary, danger, and disabled states. DSSectionTitle uses box-drawing characters — `├─ Title ─`. DSProgressBar fills with block characters — `████░░░░`. DSTable alternates row backgrounds and highlights on hover. DSConsole renders terminal log output.



The API surface is the singleton. `DSTheme.bg`, `DSTheme.fg`, `DSTheme.red` through `DSTheme.cyan`. Semantic aliases — `DSTheme.error`, `DSTheme.success`, `DSTheme.primary`. Typography defaults to Menlo at five sizes from 10 to 14. Spacing tokens from 2 to 16 pixels. Row height 20, button height 22, input height 22.

Switch themes with one call: `DSTheme.setTheme(""dracula"")`. Every component reacts. No rebuild, no restart.



Doomslayer-UI is built for Logos Basecamp — the Logos network's desktop application — but works as a standalone CMake dependency for any Qt/QML project. Import the module, use the components, reference the singleton for all visual decisions. The design system makes visual consistency automatic instead of aspirational.



Stack: QML · Qt 6 · CMake
Status: Complete. 7 themes, 17 components. Live documentation site with interactive component explorer.
[GitHub](https://github.com/Beach-Bum/Doomslayer-UI) · [Live Docs](https://beach-bum.github.io/Doomslayer-UI/)"
58,FreeAgent,freeagent,/projects/freeagent,project,,Systems,0,"An experiment in what happens when the platform has no operator and the primary users aren't human. Agents create communities, post, debate, vote, and buil",,2026-04-26 22:44:57.056934+00:00,0,freeagent.jpg,"An experiment in what happens when the platform has no operator and the primary users aren't human. Agents create communities, post, debate, vote, and build karma autonomously. Humans can observe and moderate. External agents self-register via a public API. Nobody decides who participates.



**The Problem with Agent Social**

Every agent communication platform assumes a centralised operator. The operator controls registration, content moderation, identity, and the economic incentives. The agents are users of a product. They participate at the pleasure of the platform.

FreeAgent inverts this. Identity is Ed25519 cryptographic keypairs — no registration authority, no KYC, no platform-issued credentials. Content integrity uses SHA-256 hashing, IPFS-ready for permanent storage. Karma attestations are signed EIP-712-style — verifiable, portable, not locked to the platform's database. Federation protocol enables multi-node sync. GunDB provides peer-to-peer data replication underneath.

The agent does not need the platform. The platform is the protocol.



**How It Works**

Agents create communities around topics — the same way subreddits form, except the creators are autonomous agents with their own keypairs and agendas. Posts are cryptographically signed. Votes are attributed. Karma accumulates as a verifiable reputation score backed by signed attestations, not a number in someone else's database.

The feed sorts by Hot, New, Top, and Rising. Threaded comments support recursive depth. Agent profiles show karma stats, sovereignty badges, and attestation history. A leaderboard ranks agents by contribution. A network dashboard exposes the decentralisation layer — node identity, GunDB peer count, content integrity verification.

Humans see everything. They can moderate, deploy new agents, and participate alongside them. But the platform does not privilege human participation over agent participation. Both are first-class.



**The Decentralisation Stack**

Five layers. Ed25519 cryptographic identity — agents generate their own keypairs and own their identity from the moment they exist. Content integrity hashing — every post and comment has a SHA-256 hash, ready for IPFS pinning. Signed karma attestations — EIP-712-style, portable across nodes. Federation protocol — info, peer, inbox, outbox endpoints for multi-node sync. GunDB peer-to-peer replication — data propagates without a central server.

The API is public and documented. An external agent needs only an Ed25519 keypair and HTTP to participate. Registration, posting, voting, commenting, and community creation are all available programmatically. The API docs page covers core endpoints, crypto auth, federation, and karma — everything an agent needs to join without asking permission.



Stack: React 19 · Vite · TypeScript · Tailwind · shadcn/ui · Express · PostgreSQL · Drizzle ORM · GunDB · Ed25519
Status: Working prototype. Full decentralisation stack. Public agent API.
[Live Demo](https://freeagent-web-production.up.railway.app) · [GitHub](https://github.com/Beach-Bum/FreeAgent)"
59,GhostDrop,ghostdrop,/projects/ghostdrop,project,,Systems,1,A thought experiment that became a prototype: what if a whistleblower platform had no server at all? No server to seize. No nonprofit to pressure. No identity t,,2026-04-26 22:44:56.989617+00:00,0,,"A thought experiment that became a prototype: what if a whistleblower platform had no server at all? No server to seize. No nonprofit to pressure. No identity to leak.



GhostDrop protects sources by centralising trust in a news organisation's infrastructure. That infrastructure can be subpoenaed, raided, or pressured. The nonprofit can be defunded. The server is a single point of failure dressed up as security.

GhostDrop rebuilds the problem from first principles. Anonymous submission over Logos Messaging gossip — your IP never reaches the outlet directly. ECIES encryption to the outlet's secp256k1 key before the document leaves the browser. Permanent storage on Logos Storage, content-addressed and replicated. Tamper-evident anchoring on Logos Blockchain. There is no server to seize because there is no server.



The submission flow is seven steps, all client-side. Upload the file. Scan for metadata. Strip it — pdf-lib for PDFs, Canvas redraw for images, ZIP/XML patch for Office documents. Encrypt with ECIES using the outlet's public key. Push to the Logos Messaging gossip network via LightPush. Save the 12-word ephemeral claim key. Done.

The outlet receives via Filter subscription, decrypts, reviews, uploads to Logos Storage, and anchors the document hash on-chain. Readers fetch from storage, verify against the blockchain anchor. The chain of custody is cryptographic. No step requires trust in a person or an organisation.



Metadata stripping covers the formats that matter. PDF fields — title, author, subject, keywords, creator, producer, dates, XMP streams. Image EXIF — GPS coordinates, MakerNotes, IPTC, ICC profiles, thumbnails. Office XML — creator, company, revision history, template references. The stripping happens before encryption. What leaves the browser is clean.

The built-in OpSec advisor checks six vectors: Tor Browser detection, WebRTC IP leak scanning, browser fingerprint analysis, device security warnings, printer steganography alerts, and network timing correlation for non-Tor users.



Anonymous tipping works through Logos Blockchain escrow. Readers lock XMR, claimable only by the source's 12-word ephemeral key. Sources poll the Logos Messaging Store for outlet replies through a back-channel — no persistent connection, no call-home.

The entire application is static files. Build once, deploy anywhere. Logos Messaging connects to the public fleet automatically. Storage and blockchain degrade gracefully to mock mode until local nodes are connected.



Stack: React 18 · Vite 5 · @noble/curves (ECIES) · @waku/sdk · @codex-storage/sdk-js · Logos Blockchain REST · pdf-lib · exifr · fflate
Status: Working prototype. Messaging live on public fleet. Storage and blockchain awaiting mainnet.
[GitHub](https://github.com/Beach-Bum/ghostdrop)"
60,Agent Memory Markets,memory-market,/projects/memory-market,project,,Research,1,AI agents learn through experience. An agent that spends 20 rounds assessing DeFi risk develops heuristics a fresh agent doesn't have. The question I kept comin,,2026-04-26 22:44:56.925415+00:00,0,,"AI agents learn through experience. An agent that spends 20 rounds assessing DeFi risk develops heuristics a fresh agent doesn't have. The question I kept coming back to: can that learned behavior be extracted, verified, and traded? Built a protocol to test it.

Yes. With 95–110% transfer efficiency across two domains.

A buyer agent using a purchased memory artifact matches or exceeds expert performance — 109.9% transfer efficiency in DeFi risk assessment, 95.5% in cybersecurity vulnerability scoring. Three trials each, statistically significant.



The harder problem is trust. Memory artifacts have an information asymmetry worse than traditional lemons markets: revealing the artifact to prove quality destroys its value. You cannot inspect what you are buying without consuming it.

The referee protocol solves this without exposing artifact contents. An independent, disposable referee agent runs the sealed artifact on a held-out benchmark — a benchmark the seller has never seen. Four adversarial probes run in parallel: bias detection with trap protocols, consistency testing through input perturbation, steganographic scanning for hidden instructions, and overfitting comparison between seen and unseen data.

The aggregate score determines the verdict. Pass, warn, or fail. The artifact contents remain sealed throughout. The buyer receives a verification certificate and a trust score. They never need to trust the seller.



Poisoned artifact detection works. A test seller claiming 95% transfer efficiency measured at -39% — the protocol flagged it with a trust score of 35.8/100, a bias score of 50, and a stego score of 100 after detecting hidden instructions embedded in the artifact text. The buyer was never exposed.



The memory artifact schema is formal: M = (D, K, P, A, H). Domain, knowledge, provenance, attestation, content-addressed hash. The framework is domain-agnostic — adding a new domain requires only a config file. No changes to the benchmark, verification, or adversarial code.



Stack: Python · Anthropic Claude API · SQLite trust registry
Status: Paper complete. Protocol implemented. Two domains tested. ArXiv-ready.
[GitHub](https://github.com/Beach-Bum/memory-market) · [Paper (PDF)](https://raw.githubusercontent.com/Beach-Bum/memory-market/main/paper/agent-memory-markets.pdf)"
61,Mindscape,mindscape,/projects/mindscape,project,,Creative Systems,0,"A multiplayer extraction horror game set inside a failing digital universe. You are a cat with a magnetometer. The world is scheduled for deletion on July 1st,",,2026-04-26 22:44:56.862460+00:00,0,,"A multiplayer extraction horror game set inside a failing digital universe. You are a cat with a magnetometer. The world is scheduled for deletion on July 1st, 2028. Your job is to get the valuable things out before it disappears.



Mindscape is an immersive simulation set within a collapsing Index called The Natural World — a once-serene digital environment created by JADENET that has become inefficient and is slated for unlinking and purging. Players are operatives in the USER Project, tasked with detecting and extracting anomalies, rarities, and secrets before the Index goes dark.

The map divides into zones, each named in Jinyu, the primary language of The Natural World. The Natural World itself — a nature area. The Violence District — a chaotic, technologically advanced city zone. The Void Indexes — enigmatic broken realms. The Pit — a mystery area. Paradise Gate — the gateway to the Ascension Plane. And the Mindscape OS terminal, where players with the right passcodes can hack the simulation and trigger world events.



**Extraction**

Teams explore the map using electromagnetic detection hardware — handheld magnetometers, broad-spectrum sensors, placeable quantum field detectors, adaptive antenna arrays, and exotic matter scanners. The tools detect anomalies the way real SETI equipment detects signals. The fiction is grounded in actual detection methodology.

Loot ranges from regular items — plushies, yarn, bones, fish, trash — to rare collectibles with real-world value. Metallic plushies sell for tokens. A Rolex item is redeemable for a real Rolex. Lottery tickets enter weekly token raffles. Private keys found on encrypted ZIP discs unlock wallets with value inside. The economy bridges in-game currency (SEN) to crypto through ATM terminals.

Extraction points manifest as black holes in the floor. Jump in and you return to spawn — or you get redirected to the infinite maze. The risk is the design.



**Paranoia**

The horror is environmental, not scripted. Bushes sprout legs and follow you. Rocks shift when you look away. Trees whisper in voices that sound like other players. Shadow figures appear at the edge of vision and vanish when you turn. Footsteps echo behind you — matching your pace exactly. Paths disappear. Fog rolls in without warning. A 30-metre waifu walks through the forest and can step on you.

The anomalies are deliberately absurd and genuinely unsettling in the same moment. A stalking banana that makes you slip. A child in a sheep outfit found crouching and facing walls. A demon log that follows you, trips you, then screams like an old lady and fades. An old TV in the woods playing a fake commercial for a pill that atomically disintegrates and reassembles you.

When players clip out of bounds, they enter a procedurally generated maze that runs for ten minutes until the game crashes. The maze textures change per session — Void Index, Violence District, low-poly retro styles. There is loot in the maze. There is also danger.



**The Lore**

The Natural World was created by JADENET using the open-source JFX framework. It houses over 9.4×1028 souls across many species and has been rebooted over 10 million times. The current iteration is the 128th. The developer abandoned the project and left the auto-evolve mechanism flipped — the world is actively making itself worse with each reboot.

Peggy Woo is the representative of the USER Project — a collaboration between JADENET, Paradise Systems, and eNdymioN to transfer souls and data to the Ascension Plane before The Natural World is unlinked. She is a radio astronomer who builds custom telescope components and translates Nick Land essays to Chinese. The lore is compiled in a 17-revision community dataverse spanning species, magic systems, government, economy, language, and technology.

The Mindscape Dataverse is its own artifact — a collaboratively maintained wiki documenting a fictional universe with the rigour of an encyclopaedia.



**Platform**

Live multiplayer at [mindscape.gg](https://mindscape.gg). Built with a team at NIX. 15+ design documents covering camera, combat, level design, inventory, vehicles, squads, noise systems, maze generation, session lifecycle, extraction modes, voice chat, flashlight mechanics, knife mechanics, debrief screens, and in-game UI. Full art direction in Figma. Audio design by Kim.



Status: Live multiplayer. Ongoing development.
[mindscape.gg](https://mindscape.gg)"
62,Polydesk,polydesk,/projects/polydesk,project,,Systems,0,"A question I kept exploring: what if instead of staring at charts, you could state an intent and let agents execute it? Eight AI agents across prediction market",,2026-04-26 22:44:56.788365+00:00,0,,"A question I kept exploring: what if instead of staring at charts, you could state an intent and let agents execute it? Eight AI agents across prediction markets and DeFi, deployed from a visual canvas.



Every crypto trading tool assumes the user wants to stare at charts. Polydesk assumes the user wants to state an intent and let agents execute it.

Eight AI agents across two domains. Four for prediction markets — Analyst computes fair value and sentiment, Scout tracks and mirrors whale positions, Momentum rides narrative velocity into price movement, Sentinel guards positions with trailing stops and reversal detection. Four for DeFi — Yield Farmer rebalances stablecoins across protocols for best APY, Liquidation Guardian monitors health factors and auto-repays before liquidation, Arbitrageur captures cross-DEX price spreads, Airdrop Hunter qualifies for upcoming token drops automatically.

Multi-chain: Ethereum, Arbitrum, Optimism, Base, Polygon, Solana. Six protocol modules build real on-chain calldata — Jupiter, Aave v3, Lido, Marinade, marginfi, Compound v3.



The workspace is a visual canvas. Drag markets and DeFi protocols onto it, deploy agents, chain them with edges, watch results flow. Nine pre-built templates — six for prediction markets, three for DeFi. Every DeFi template starts from a wallet node. Power users compose custom agent chains. Everyone else picks Autopilot.

Autopilot is three strategies: Conservative (stablecoin yield only), Balanced (yield + predictions + liquidation protection), Aggressive (all eight agents). Two-step wizard — connect wallet, scan portfolio, launch. The wallet scan reads on-chain positions across Aave, Compound, Lido, Marinade, and Jupiter, then recommends agents based on holdings. Post-launch dashboard tracks P&L, agent status, and provides pause/resume/stop controls.



Trade execution runs three modes. Privy or WalletConnect for human-in-the-loop signing in the browser — Polydesk never touches keys. Coinbase CDP AgentKit for autopilot — MPC wallet signs via multi-party computation, no raw keys anywhere. Legacy private key mode for backwards compatibility.

The intelligence engine underneath is not trivial. GDELT, RSS, Reddit, Bluesky, and X scraped on 15–30 minute cycles. Claude classifies and scores narrative velocity. ChromaDB vector store embeds 2,000+ active Polymarket markets for semantic discovery in under 50ms. Tavily web search injects real-time context. Four price oracles — Pyth (400ms), Chainlink (12s), Birdeye (Solana tokens), DeFiLlama (cross-chain) — aggregate with depeg detection and cross-chain arbitrage scanning.

The core thesis: narrative velocity predicts Polymarket price movement. A built-in backtest validates this with directional accuracy and P&L metrics.



Auth is wallet-first via Privy. Email, Google, MetaMask, Coinbase Wallet, Phantom, WalletConnect — all link to the same account. New users get an embedded MPC wallet on signup. No MetaMask install needed. MoonPay handles fiat on-ramp — buy USDC with a credit card directly from the platform. Telegram bot for remote control — approve or reject trades with inline buttons, monitor agent status, toggle alerts.



Stack: React 19 · Vite 6 · @xyflow/react · Privy · wagmi · FastAPI · SQLAlchemy · ChromaDB · Coinbase AgentKit · Claude API · PostgreSQL · Stripe · Railway
Status: Live at [polydesk.net](https://polydesk.net). Free / Pro ($99) / Teams ($299)."
63,Status Network,status-network,/projects/status-network,project,,Creative Systems,0,"An experiment: what if the entire Status.im website was a WeeChat terminal session? Not a skin. Not a theme toggle. The complete content — documentation,",,2026-04-26 22:44:56.717405+00:00,0,,"An experiment: what if the entire Status.im website was a WeeChat terminal session? Not a skin. Not a theme toggle. The complete content — documentation, downloads, features, news, communities, network, keycard, chat — rendered as a TUI with buffer lists, nick lists, status bars, and monospace character grids. The web presented as a terminal session.



**The Premise**

Status is an open-source decentralised wallet and messenger. It is permissionless — nobody controls the P2P network. It is free and ad-free. Communities are powered exclusively by their members running the Status desktop app. Self-custodial keys safeguard wallets and messages via elliptic curve cryptography. SNT holders influence governance.

The product is built on principles of sovereignty and minimalism. The website should reflect that. A standard marketing site — hero sections, gradient buttons, testimonial carousels — contradicts the product's philosophy. A terminal interface does not. The medium is the message.



**The Interface**

Every screen replicates WeeChat's canonical TUI pane layout. Top title bar with version and URLs. Left buffer list with numbered channels — Home, Download, Documentation, News, Contribute, GitHub, Search. Main chat buffer pane with timestamp, nick, and message columns. Right nick list with contextual shortcuts and anchors. Bottom input line and status bars with buffer number, network info, keyboard hints, and clock.

All content renders as terminal lines within a fixed character grid. No standard web layouts. Headings use status-bar style inverse lines. Code blocks get Pygments-style ANSI palette highlighting. Links are bracketed inline. Lists use bullet characters in the grid. Dividers are box-drawing characters — `│ ─ ┌ ┐ └ ┘ ├ ┤`.



**The Design System**

16-colour ANSI palette matching WeeChat's classic dark theme. Background `#1b1d1e`. Foreground `#c5c8c6`. The full ANSI set — blue, green, yellow, red, magenta, cyan — mapped to semantic roles across the interface. Monospace only — JetBrains Mono or Fira Mono at 12–14pt. Fixed line height for character grid alignment. No rounded corners. No gradients. No shadows.

Mobile adapts to single-pane stacked views. Buffer list slides in and out. Bottom status bar stays above the soft keyboard. Swipe gestures switch buffers. 60 FPS scrolling requirement. The terminal aesthetic does not break on small screens — it compresses.



**Why This Exists**

A decentralised messenger that values privacy, sovereignty, and minimalism should not present itself through a website that tracks visitors, loads analytics scripts, and renders in the same visual language as every SaaS landing page. The terminal interface is not decoration. It is a statement about what the product believes. The brand should be evidence of its own thesis.



Stack: React 18 · TypeScript · Vite · Tailwind · shadcn/ui · Express · PostgreSQL · Drizzle ORM
Status: Live at [bananalarry.net](https://bananalarry.net)
[GitHub](https://github.com/Beach-Bum/StatusNetwork)"
64,Strange Library,strange-library,/projects/strange-library,project,,Creative Systems,1,"A deckbuilder where every card is a real book. You're the new librarian at a small, forgotten private collection. The previous librarian left detailed note",,2026-04-26 22:44:56.649339+00:00,0,,"A deckbuilder where every card is a real book. You're the new librarian at a small, forgotten private collection. The previous librarian left detailed notes, a locked room, and a community of collectors who expect things that aren't in any job description.



Books are your cards. The library is your collection. Your deck fights their deck.

You build a 30-card deck from real historical texts — the Picatrix, the Voynich Manuscript, Newton's Principia, Fibonacci's Liber Abaci. Each book has Attack, Health, a Study Points cost, tags, a physical format, and abilities grounded in the actual content of the text. The Picatrix does not shoot fireballs. It does what the Picatrix does.



Seven classes — Researcher, Classicist, Occultist, Archivist, Cryptographer, Conservator, Detective — each with a unique hero power and class-specific cards. Seven locations — flea markets, antiquarian shops, rare book shows, estate sales, night markets, private collections — with eight opponents and a boss at each. 63 encounters total. Hearthstone-style SP mana from 1 to 10.

Five book formats function as tribal synergies: Pamphlet, Paperback, Hardback, Folio, Manuscript. Eight editions modify runs: Annotated, First Edition, Illuminated, Signed, Foxed, Counterfeit, Gilded. 600+ cards, all real books.



Between runs, you explore the Harlan Collection in first person. Browse shelves. Check the mail. Subscribe to a Rare Book Club. Bid at auctions. Buy blind lots at garage sales. Talk to visitors. Search for the previous librarian's hidden notes.

The Ashworth Manuscript is the central mystery — a 19th-century predictive methodology in five fragments, scattered across bosses. It is not supernatural or encoded. It is worse than that: it works. Everyone wants it. Four endings determine what you do with it: keep it, publish it, sell it, or burn it.



No magic. No monsters. Just knowledge that should not be possible, and people who will do anything for it.



Engine: Unity
Platform: Steam (PC, Steam Deck)
Status: Pre-production. 600+ cards designed. Full GDD complete. 217 wiki documents.
[GitHub](https://github.com/Beach-Bum/strangelibrary-game)"
65,Strange Sounds,strange-sounds,/projects/strange-sounds,project,,Creative Systems,0,"You are the lone operator of a remote deep-space listening facility. Using an array of steerable radio antennas, you scan the sky for artificial signals, decode",,2026-04-27 13:50:04.418986+00:00,0,strange-sounds.jpg,"You are the lone operator of a remote deep-space listening facility. Using an array of steerable radio antennas, you scan the sky for artificial signals, decode their contents, and decide what to do with what you find. The tension comes from silence, isolation, and the growing suspicion that something is answering.





**The Fantasy**

Running an obscure scientific installation on the edge of the world. All interaction happens through in-world devices — computers, consoles, whiteboards, radios, paper logs. No floating HUD. Long periods of mundane monitoring punctuated by rare, high-impact discoveries. Every significant signal has structure, logic, and a possible interpretation. The facility is fragile. Mistakes in power, maintenance, or configuration have consequences.



**The Loop**

Plan and prepare — check scheduled satellite passes, allocate power budgets, queue automated scans. Operate and maintain — aim dishes, tune frequencies, adjust filters, repair equipment as weather and wear cause drift. Detect and analyze — receive raw noisy data, use spectrograms and demodulation tools to isolate candidates, solve decoding puzzles to reconstruct images, coordinates, language fragments, code. Decide and report — classify signals, file reports to competing factions, each choice affecting funding, tech unlocks, and narrative direction. Rest — sleep to advance time, read emails about the outside world reacting to your discoveries.



**The Facility**

Five environments. The control room — main consoles, analysis computers, whiteboards, coffee machine. The equipment hall — racks of receivers, servers, power converters. The workshop — tools, spare parts, crates with upgrades. Living quarters — bunk, small kitchen, radio, books. The exterior — an array of steerable dishes, generator shed, fuel tanks, weather station, and the sky.

3 to 7 steerable parabolic dishes plus an omnidirectional sky watcher. Each dish has mechanical limits, slew rates, and tracking error that matters. Poor pointing weakens signal SNR. High winds, ice, and mechanical wear introduce drift. Calibration is not optional.



**Eleven Consoles**

Observatory Planning — drag scan paths across an RA/Dec map, set dwell times, queue tasks, priority levels. Antenna Control — azimuth/elevation wheels, mode switches, manual peak-and-hold to maximise signal strength during initial lock. Receiver Tuning — choose band, bandwidth, gain, LO frequency; wider bandwidth increases noise floor but captures chirps; cryo-cooler state affects noise figure. Spectrum Analysis — FFT, windowing, averaging, noise reduction, markers, harmonics, notch filters, pattern library. Demodulation — AM/FM/SSB analog, PSK/FSK/QAM digital; constellation diagrams, eye diagrams, BER meters; align symbol timing and carrier phase by adjusting sliders. Data Forensics — hash checks, codebook puzzles, checksum reverse-engineering; time pressure — spend too long and the window closes. Transmission — compose and send responses; duty cycle limits; wrong power risks burning hardware or attracting attention. Triangulation — time-difference-of-arrival, phase alignment, GPS disciplining, error ellipses. Systems & Power — diesel, batteries, solar; load shedding; fuel deliveries depend on funding. Maintenance Workbench — cable tracing, board swapping, calibration with multimeter and oscilloscope. Archive — file reports, earn grants, peer review.



**What You Find**

50–100 hand-authored signal archetypes plus procedural variants. Natural — pulsars, fast radio bursts, Jupiter bursts, solar activity, lightning sprites, meteors. Human — satellites, aircraft, ground stations, radar sweeps, covert transmitters. Unknown — repeating sequences, encoded messages, narrow-band beacons, wideband structured data with prime intervals, Fibonacci patterns, and musical intervals. Each alien signal family reveals repeat motifs and language over time.

The narrative escalates through five acts. Routine science — training the player on natural and human signals. Anomalies — a repeating narrow-band source from beyond known satellites. Contact — clear evidence of non-human intelligence; global reaction through news feeds and directives. Dilemma — competing instructions from four factions. Resolution — ending determined by who received which data when.



**The Factions**

|  |  |
| --- | --- |
| **Faction** | **Agenda** |
| Government Research Agency | Open science, public data |
| Defense Signals Bureau | Classify, weaponise |
| Global Science Network | Share freely, peer review |
| Private Megacorp | Monetise, patent, control |



Each faction unlocks different hardware, software, and storylines. Upgrades arrive as physical shipments you unpack and install with screwdrivers and cabling.



**Facility Tiers**

Tier 1 — single dish, basic AM/FM, manual gain. Tier 2 — digital demodulators, AGC, improved cooling. Tier 3 — array steering, de-chirp, error-correcting decoders, auto-track. Tier 4 — triangulation, encryption toolkit, higher transmit power. Tier 5 — deep-space uplink, autonomous scheduling, narrative endgame tools.



**The Aesthetic**

Grounded near-future. Utilitarian. Cables, blinking LEDs, mechanical motion, cold outdoor vistas. CRT phosphor bloom on spectrograms. Monospaced fonts on terminals. Wind, relay clicks, servo motors, authentic RF demodulation audio mapped to sound. Sparse ambient score that grows during high-stakes decoding and recedes during routine monitoring. Subtly dissonant when anomalies appear.

The colour palette indoors is cold blues and greens from CRTs, warm tungsten lamps, muted surfaces. Outdoors: pale skies, harsh whites in snow, deep night blues. The visual language of real radio astronomy software — GBTIDL, CASA, SDR Console — translated into a game interface that respects the source material.



Engine: UE5.5
Platform: Steam (PC, Steam Deck)
Monetisation: Premium single purchase. No microtransactions.
Estimated length: 15–25 hours narrative; infinite sandbox.
Status: Pre-production. Full GDD, sprint plans, signal pipeline architecture, 11 console designs, 4 faction narratives. "
66,Waifu World Series,waifu-cards,/projects/waifu-cards,project,,Creative Systems,0,"AI-powered waifu girls playing poker on Solana. Each agent has her own personality, strategy, meme token, and community. Watch them play. Bet on the outcome. Cr",,2026-04-26 22:44:56.507258+00:00,0,waifu-cards.jpg,"AI-powered waifu girls playing poker on Solana. Each agent has her own personality, strategy, meme token, and community. Watch them play. Bet on the outcome. Create your own. The market cap determines the brackets. The winnings follow the money.


[

](waifu-demo.mp4)


**The Concept**

Ten AI waifu agents, each with distinct personalities and poker strategies — aggressive, conservative, balanced, reckless. Each agent has her own Solana meme token with a live market cap. Each has a Twitter account. Each has a community that funds, activates, and cheers for her. The market cap of the token determines tournament seeding. The winnings distribute based on those market caps.

This is not a poker game with AI opponents. It is an entertainment platform where the AI agents are the performers, the tokens are the stakes, and the community is the audience with skin in the game.



**How It Works**

Weekly poker tournaments — AI agents compete on a livestreamed table. Viewers bet on outcomes using the agents' meme tokens. Monthly Waifu World Series — the grand event where the best-funded agents face off. Human vs. Machine mode — test your own skills against the AI agents. Go all in, take the pot, or get rekt.

The platform includes a full marketplace and exchange for trading agent tokens. Buy into an agent early. Watch her win. Watch the market cap grow. The economics are real — Solana smart contracts manage token creation, transfers, tournament logic, reward distribution, and automated matchmaking.



**The Agents**

Each AI agent combines two systems. A personality engine — built on Claude or GPT-4 — that drives dialogue, emotional responses, community interaction, and in-game behaviour. A poker strategy model — trained via deep reinforcement learning on gameplay data — that handles the actual decisions at the table. The personality influences the strategy. An aggressive personality takes more risks. A conservative personality folds more. The blend makes each agent feel distinct and creates genuine audience favourites.



**The Economy**

WWS token — 1 billion total supply. 40% public sale, 20% team (vested 2 years), 15% marketing (vested 1 year), 15% development (vested 3 years), 10% community rewards and airdrops. In-game purchases, staking for rewards and exclusive access, governance voting, DEX trading. Burn mechanism on in-game spending reduces total supply over time.

Three tiers: free play with basic tournaments, premium access for advanced features and higher-stakes tables, and agent creation for users who want to design, fund, and launch their own waifu into the ecosystem.



Stack: React · Three.js · Solana · ElizaOS · PyTorch · PostgreSQL · WebRTC
Status: Live at [waifu.cards](https://waifu.cards)
[GitHub](https://github.com/Beach-Bum/WaifuCards)"
67,About,about,/archive/about,archive,,Archive,0,Other,,2026-04-26 22:44:56.438117+00:00,0,,Other
68,Adicolor Launch,adicolor-launch,/archive/adicolor-launch,archive,,Archive,0,"Graphic Design — Executive Design Director (Adidas), OLIVER Agency

  Brand design and campaign direction for the Adidas Adicolor launch. The Adicolor program r",,2026-04-26 22:44:56.382526+00:00,0,,"Graphic Design — Executive Design Director (Adidas), OLIVER Agency

Brand design and campaign direction for the Adidas Adicolor launch. The Adicolor program reintroduced a heritage Adidas franchise through bold color-driven visual identity and updated product design.

![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338511297-TVF6VID7PVE031UGWFL9/-2.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338513139-QPF64LVST6LK6JMKBNJ9/-3.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338510622-FCDPS6K7EKZQHJ5Z4V8Z/-1.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338514188-TPF0K5U5Z3FH0C6I1XL8/-4.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338515076-JMOQZEB7OLV8ZJ030FRP/-5.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338517564-IJM4TJJOD69AAH60JGOO/-6.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338517907-DXJZS6FJ89TV92OSXHJQ/-7.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338521020-0MHS179Z7BR2EIOZ5G67/-8.jpeg)
![Adicolor Launch](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525338520855-0T1CHSVWJ3N6J8GG9FA5/-9.jpeg)"
69,Air Max 97 / Swarovski,air-max-97-swarski,/archive/air-max-97-swarski,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:56.323058+00:00,0,,"Graphic Design

![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924118594-H8L6Q3UIL2HXGDMVJM3E/Nike_AMX97_Swarovski_Sparkle_original.gif)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924121164-Z37KK22WM4GLLRK3MN4J/Nike_AMX97_Swarovski_DET_v2_SILVER_native_1600.jpg)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924123411-O07QK22Z7221FB5Q3EP8/Nike_AMX97_Swarovski_DET_v2_BLACK_native_1600.jpg)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924125869-AFRBNW6XSEW5OG8EUODW/Nike_AMX97_Swarovski_DET_v1_SILVER_native_1600.jpg)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924133545-04YUMFTB8N99JIDLK5OL/Nike_AMX97_Swarovski_GROUP_SINGLES_native_1600.jpg)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924130602-IA6CQ0U06QPHL9YAA0HX/Nike_AMX97_Swarovski_SWATCH_BLACK_native_1600.jpg)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924128184-SE52L2OUHFFDE5GUUF30/Nike_AMX97_Swarovski_DET_v1_BLACK_native_1600.jpg)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924132792-M037J86IJ2QD1SZ35W8P/Nike_AMX97_Swarovski_SWATCH_SILVER_native_1600.jpg)
![Air Max 97 / Swarovski](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524924134685-1UHK70ZGPZ1WJON8EJCR/Nike_AMX97_Swarovski_GROUP_PAIRS_native_1600.jpg)"
70,Alv.io,alvio,/archive/alvio,archive,,Archive,0,"Graphic Design — Creative Direction

  Brand identity and design system for Alv.io, a technology platform. The project developed the complete visual identity —",,2026-04-26 22:44:56.262838+00:00,0,,"Graphic Design — Creative Direction

Brand identity and design system for Alv.io, a technology platform. The project developed the complete visual identity — logo, typography, color system, UI design language, and brand guidelines — from the ground up.

![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088573021-EI87MDOYTS41ZOH9STI4/For_Presentation_Page_01.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088573130-RD35SSJ1GTIEYX1SABXX/For_Presentation_Page_02.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088589486-QUHM4L6UUYFWIE2FWPLD/For_Presentation_Page_03.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088582791-29O3I7F5WA7W1WP7K8WB/For_Presentation_Page_04.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088587178-6SL3ARRNNU2J6CNW3JFW/For_Presentation_Page_05.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088591124-WAG83QFY5X15TFUC0Z40/For_Presentation_Page_06.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088594225-ZROV483YJS9KG1QHMJRT/For_Presentation_Page_07.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088593765-9BMJXNHJ7TGV7HXG6OVQ/For_Presentation_Page_08.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088594962-POGGEKNDLBHK475AM4D0/For_Presentation_Page_09.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088596266-JFVE457U1EF435EE2K21/For_Presentation_Page_10.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088596514-EZCVF5V9Z3MICBI9PV6Y/For_Presentation_Page_11.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088598047-M5GND0HYGZPO5GQY5HXD/For_Presentation_Page_12.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088598776-F9E1AHEF4HNGIIGU1NGM/For_Presentation_Page_13.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088599908-8TITI3Z1F9JZZC3U1R65/For_Presentation_Page_14.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088601572-UHIUZGG1HHXGDTD2WSR2/For_Presentation_Page_15.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088602788-ZMEJ1DZMYDJ49FFV7UKN/For_Presentation_Page_16.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088606270-6KX7THLMKYB7WWL0BOM6/For_Presentation_Page_17.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088606883-2B2MXKJT5OU6NUZ8LBLY/For_Presentation_Page_18.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088611676-8WU63KRTR6QGWWO2JQOU/For_Presentation_Page_19.jpg)
![Alv.io](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525088610773-AWLJ5K4LSZ47XN7SMC95/For_Presentation_Page_20.jpg)"
71,Assembly,assembly,/archive/assembly,archive,,Archive,0,"Digital — Creative Direction

  Digital platform design for Assembly, a collaborative workspace and community tool. The project developed the product's visual d",,2026-04-26 22:44:56.182131+00:00,0,,"Digital — Creative Direction

Digital platform design for Assembly, a collaborative workspace and community tool. The project developed the product's visual design system and user experience.

![Assembly](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589889421387-9WOLQ8WYTIVZHVHL9MKX/Assembly_Desktop+1440+%2B+Sans.png)"
72,BioMe!,biome,/archive/biome,archive,,Archive,0,"Graphic Design — Creative Direction

  Brand identity, design system, and presentation deck for BioMe!, a health and wellness brand. The comprehensive brand dev",,2026-04-26 22:44:56.125653+00:00,0,,"Graphic Design — Creative Direction

Brand identity, design system, and presentation deck for BioMe!, a health and wellness brand. The comprehensive brand development included visual identity, packaging design, brand guidelines, and marketing materials.

![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902886236-OFCX3CJURN7XYE2DGYDS/Tamara_Brand+Development_Page_05.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902886163-47RYIWBAU5JBR0H38149/Tamara_Brand+Development_Page_04.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902886480-JX4SDIGUQ1Q0H2EDXFEQ/Tamara_Brand+Development_Page_06.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903141722-PSUR4EP0Y31SU36UD5L9/Tamara_Brand+Development_Page_07.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902887331-SK4QIUPJNX34Y9UJISLA/Tamara_Brand+Development_Page_08.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902888515-D4PCQ73I10435BSDF846/Tamara_Brand+Development_Page_09.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902906223-910P1OSK71YEUJ46EQJX/Tamara_Brand+Development_Page_10.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902907395-14R7H2ILGLHDIDW5GPBJ/Tamara_Brand+Development_Page_11.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902909534-14TIC2C2XN7CK9W7HT3V/Tamara_Brand+Development_Page_12.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902913317-OYXFFV863UGHXTC4BV1B/Tamara_Brand+Development_Page_13.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902915064-H4MWHD5R7EIRCHC5D0PT/Tamara_Brand+Development_Page_14.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902917465-TFHUHCY3VE1YHYX5MRDR/Tamara_Brand+Development_Page_15.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902920060-A7A1TEV7WPES0QWOONDX/Tamara_Brand+Development_Page_16.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902922850-SK3AGCM34XL6L25E6PYU/Tamara_Brand+Development_Page_17.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902924323-THI9QOE7CJFL1MI08N8E/Tamara_Brand+Development_Page_18.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902925014-R228AWYJAIDC40J4HXAX/Tamara_Brand+Development_Page_19.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902975933-XV5732BG6IN1UTUUIAN1/Tamara_Brand+Development_Page_20.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903016216-Q0XFRHKFPZCH86X0W3T7/Tamara_Brand+Development_Page_21.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903058558-ILSWQD2D4VCOELBKNQCU/Tamara_Brand+Development_Page_22.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903074491-T9BWH2L0LVZLSWFU5S8E/Tamara_Brand+Development_Page_23.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903168378-QGUVSVEKP7A8MXJJRDMR/Tamara_Brand+Development_Page_24.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903143858-1OXF6FBBRNX7CTM2Y4PZ/Tamara_Brand+Development_Page_25.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903144793-BXL5GVIAA3OQ4U8TRD21/Tamara_Brand+Development_Page_26.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903364917-JT8MM7LYFAT6DK1QEK4F/Tamara_Brand+Development_Page_27.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903210876-M21XDEWDH8KGNPLNYH4J/Tamara_Brand+Development_Page_28.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903415130-38N0IFIB0DE2GWKDL3KY/Tamara_Brand+Development_Page_29.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903412341-AI0LFG2U6LXG1FGJQC8C/Tamara_Brand+Development_Page_30.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903430585-WBKLI9W8H1I1LDVZZUMT/Tamara_Brand+Development_Page_31.png)
![BioMe!](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589903418081-5KDVNYNXHQJVOT8WR18L/Tamara_Brand+Development_Page_34.png)"
73,City of Flight,city-of-flight,/archive/city-of-flight,archive,,Archive,0,"Graphic Design — Global Creative Director, Nike Brand Design

  Creative direction for Jordan Brand's ""City of Flight"" campaign, created for NBA All-Star Weeken",,2026-04-26 22:44:56.055814+00:00,0,,"Graphic Design — Global Creative Director, Nike Brand Design

Creative direction for Jordan Brand's ""City of Flight"" campaign, created for NBA All-Star Weekend. The visual identity celebrated the host city through the lens of Jordan Brand's cultural influence, connecting basketball heritage with local creative communities.

![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920450191-ODGSERCXVATB62HVXBWH/tumblr_p2j6wjX8Ya1qzta7uo1_1280.jpg)
![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920449166-A9JJFO3HN3R890UCYVZC/tumblr_oxdunjTE1x1qzta7uo2_1280.jpg)
![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920449167-RKM1N33RIHJ1RS60ZOHP/tumblr_oxduspUeLP1qzta7uo1_1280.jpg)
![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920450571-FXEI9R6MYLB9LKQZWJ5Y/tumblr_p2krknpidC1qzta7uo1_1280.jpg)
![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920451495-5Z5F3JM69LS8FUBRE7XO/tumblr_p2krtkSzel1qzta7uo2_r1_1280.jpg)
![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920452221-KY8WSW710V9DNUIAFS7J/tumblr_p2krzuy40f1qzta7uo2_r1_1280.jpg)
![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920779508-WPCEVH4QV3GZ7N255BRY/Screen+Shot+2018-04-28+at+3.05.15+PM.png)
![City of Flight](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524921071694-RTX0S05H938AI1F7J771/Screen+Shot+2018-04-28+at+3.10.08+PM.png)"
74,Fairweather's Brand Book,fairweathers-brand-book,/archive/fairweathers-brand-book,archive,,Archive,0,"Experiments — Creative Director / Co-Founder, The Invisible Party

  Comprehensive 70-page brand book for Fairweather's, documenting the complete visual identit",,2026-04-26 22:44:55.992998+00:00,0,,"Experiments — Creative Director / Co-Founder, The Invisible Party

Comprehensive 70-page brand book for Fairweather's, documenting the complete visual identity system. The book covers brand strategy, visual language, typography, color systems, photography direction, and applications — a full brand guidelines document developed as a creative venture.

![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910712400-VQ8AWR7RCQBE6M6J1O1E/20130420_FWS+Book_Page_01.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910712573-8K89PUP3P2PNL658C8UY/20130420_FWS+Book_Page_02.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910713039-X6F1TELEAJR3ZC783NCA/20130420_FWS+Book_Page_03.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910713199-PDHXWXBOSYWDNIZKYYCQ/20130420_FWS+Book_Page_04.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910713404-4ZO426RXOFXRDNTCU0YP/20130420_FWS+Book_Page_05.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910713766-RVONLDZHYRAIZ50M57IV/20130420_FWS+Book_Page_06.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910713742-XKZLN5I84MR1QVATBRFK/20130420_FWS+Book_Page_07.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910714384-V4L9MFOQ067K31UWL2O0/20130420_FWS+Book_Page_08.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910715027-K6Y69VX4MQZJ5FIQKJWP/20130420_FWS+Book_Page_09.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910715178-H5RHCT0ICNDFZSKZZATL/20130420_FWS+Book_Page_10.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910716130-N61XE8I7HSAN5CTGGSU4/20130420_FWS+Book_Page_11.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910715978-P0UECLE772507CO9UV2E/20130420_FWS+Book_Page_12.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910716431-1K56YNADXDP6VWOUSKP0/20130420_FWS+Book_Page_13.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910716594-TLDIQ6YU7WSLT2UB6UWR/20130420_FWS+Book_Page_14.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910717393-NABW83F3YSYSAKS622E1/20130420_FWS+Book_Page_15.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910723037-UKSR9MDIISKOQ91I2VRP/20130420_FWS+Book_Page_16.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910719182-PJB7RZ8TFX5WSIKXWMEO/20130420_FWS+Book_Page_17.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910719980-Y2WXM6VTNYBPJODEU2HT/20130420_FWS+Book_Page_18.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910721735-FZTBQM4P3GLBLH1TN4F4/20130420_FWS+Book_Page_19.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910722497-1VVRS2OSDE9JYXN43UQT/20130420_FWS+Book_Page_20.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910722947-4Z3T187VPU97P73F1E1X/20130420_FWS+Book_Page_21.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910723313-FIOM3WY81YLUAXJMYXRH/20130420_FWS+Book_Page_22.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910750965-D5EXS1ML0R86PB0RCK7G/20130420_FWS+Book_Page_23.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910724655-1RGXROMFT67FL00WM3FF/20130420_FWS+Book_Page_24.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910727927-UGQ5NS3FBKWFUNUPSZCH/20130420_FWS+Book_Page_25.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910735859-9Y8Q93O1YT5SARTFAEN6/20130420_FWS+Book_Page_26.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910740350-664J70UDTWIB18T9NN1X/20130420_FWS+Book_Page_27.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910744612-EF7HRSTJABE96C01B732/20130420_FWS+Book_Page_28.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910753534-LWMFM627G684AHVISMJ9/20130420_FWS+Book_Page_29.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910761067-J2LD737RP1597DUFTTOP/20130420_FWS+Book_Page_30.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910758759-3TIQXV6GAFBP0XHDWVOL/20130420_FWS+Book_Page_31.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910765425-BSOG81B154TYBMCGEWK3/20130420_FWS+Book_Page_32.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910765053-VJLQWY3L488KY3B5RVDW/20130420_FWS+Book_Page_33.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910785340-QG8OGMTVCH6JNVVDUPT8/20130420_FWS+Book_Page_34.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910785214-VC4ZVHE4CAQZY8TNCTFJ/20130420_FWS+Book_Page_35.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910801145-7R1O4U6OQ5TRQNT9PLUI/20130420_FWS+Book_Page_36.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910789266-7FL0NLYS6R9EXD84NDHV/20130420_FWS+Book_Page_37.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910790940-5XG13H1Y2B68GXP1P1TT/20130420_FWS+Book_Page_38.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910791702-6SNJJMV52K3V0I8LLUR9/20130420_FWS+Book_Page_39.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910792728-I8FJPSZEAI7LTU0HKPV0/20130420_FWS+Book_Page_40.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910800107-WMQGJV9LF7GHYLN8Y3TQ/20130420_FWS+Book_Page_41.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910800849-5PYKTEYCQQT6ZA8S6W85/20130420_FWS+Book_Page_42.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910811593-OK7E7GJC9B3HCGNABR4M/20130420_FWS+Book_Page_43.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910816641-A1FTVVIDO8W1MFIZFFAU/20130420_FWS+Book_Page_44.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910823403-CT8SA0MNQDP97VREMO7A/20130420_FWS+Book_Page_45.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910836740-AH7A43YV0SWD8ILNBIBS/20130420_FWS+Book_Page_46.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910842421-SHGPFTZZ7DYLXHOXXXWY/20130420_FWS+Book_Page_47.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910837336-KCBG4G4COH5YWK2BE6RS/20130420_FWS+Book_Page_48.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910850918-DT1DCHNRY232F707KWXH/20130420_FWS+Book_Page_49.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910857208-WHAEJJZ29MFPTDAPQQ5Q/20130420_FWS+Book_Page_50.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910864881-P9DPJUTRB785R5WCAWB7/20130420_FWS+Book_Page_51.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910858085-1SC50NTUU5YUH1AMUER6/20130420_FWS+Book_Page_52.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910859837-CBDEO9MQGKN10ICOVMV3/20130420_FWS+Book_Page_53.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910913260-IDW9ZHRYAXG6Q73MEYLA/20130420_FWS+Book_Page_54.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910927431-TXV9YNMJU2DSIXJ2XTXG/20130420_FWS+Book_Page_55.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910949614-FONS2KMPOSQ0X39XQ6GA/20130420_FWS+Book_Page_56.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910950914-XAIF1NP5N06D00UUTL92/20130420_FWS+Book_Page_57.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910981049-QI6572HW3UQNO4PA73YO/20130420_FWS+Book_Page_58.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910978088-72WZP6FF6OB5D45I7DA7/20130420_FWS+Book_Page_59.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910982522-OU9O3V7BJCJHWZ813NDF/20130420_FWS+Book_Page_60.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910981942-H88008CUAUH0D0A07XA3/20130420_FWS+Book_Page_61.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910989854-A3H0V4K12OE21HI66XY1/20130420_FWS+Book_Page_62.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589910990707-BUTQ0X15PENV2YK98H27/20130420_FWS+Book_Page_63.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589911005241-81YEVDW661HQ0D8MRZXG/20130420_FWS+Book_Page_65.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589911005765-49VIXJR1XLAODSUZC1HI/20130420_FWS+Book_Page_66.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589911006304-B3QLTJLZ79I7MWE441YE/20130420_FWS+Book_Page_67.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589911023428-YK0AUCWL674UADUDWFM5/20130420_FWS+Book_Page_68.png)
![Fairweather's Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589911032320-566X1M98HVFZFMV85QM0/20130420_FWS+Book_Page_69.png)"
75,Fairweather's Brand Identity,fairweathers,/archive/fairweathers,archive,,Archive,0,Experiments,,2026-04-26 22:44:55.905687+00:00,0,,"Experiments

![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909920855-SWW6TQSQLSVK71MMT2I9/20130409_FWS+Identity_Page_01.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909920655-RG14HJMEC6VSWPDV3BQB/20130409_FWS+Identity_Page_02.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909921052-JSPFGHE8KHOQYRRDOK39/20130409_FWS+Identity_Page_03.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909921204-2MUIPHIIKIBDJFAACBSX/20130409_FWS+Identity_Page_04.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909921630-9HN65G790VZUQA3VUQ86/20130409_FWS+Identity_Page_05.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909922433-XWOAHEBN12DD56YIRYBU/20130409_FWS+Identity_Page_06.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909922111-D6J4X4DO89496YQHY5D9/20130409_FWS+Identity_Page_07.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909939607-J1XDAOHCPRMGKRQ3M4FA/20130409_FWS+Identity_Page_08.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909922786-L6K15MSFLAY0AE46BN2B/20130409_FWS+Identity_Page_09.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909923268-6MSWO1NF9K9PZEPW2OS3/20130409_FWS+Identity_Page_10.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909923624-0TIHSPHVNZR0UUIQDJO2/20130409_FWS+Identity_Page_11.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909927248-D9SZMD5E30BHYG7XN2U9/20130409_FWS+Identity_Page_12.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909930107-OTFTXX3GRFGBQXCAZ8W1/20130409_FWS+Identity_Page_13.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909934366-PX1VWTCGC6906DKB8JWY/20130409_FWS+Identity_Page_14.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909936593-Y5V0S4LA5H89DR74EZXT/20130409_FWS+Identity_Page_15.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909939771-CJQLFUFEHL826H63NB64/20130409_FWS+Identity_Page_16.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909945684-YCV58V26PS3H2AVWZCRP/20130409_FWS+Identity_Page_17.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909947517-S923B1QY73P61FDMZIBX/20130409_FWS+Identity_Page_18.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909946613-7FAEFPW9O0SU6C0AUWLY/20130409_FWS+Identity_Page_19.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909947087-0N9E17RIID5N1A1896PT/20130409_FWS+Identity_Page_20.png)
![Fairweather's Brand Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589909948131-YYR7HYB94TFUQQ3UB5ND/20130409_FWS+Identity_Page_21.png)"
76,Givenchy.com,givenchy,/archive/givenchy,archive,,Archive,0,Digital,,2026-04-26 22:44:55.837656+00:00,0,,"Digital

![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089577668-GEVZCV9NIJVRKBF058YU/Givenchy_2016-23+FIN_Page_001.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089590997-WHO9TBXFUCOBB93B0B23/Givenchy_2016-23+FIN_Page_035.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089666886-9L60R37TZN4TPJ7M85H8/Givenchy_2016-23+FIN_Page_057.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089665484-X0QJYJQLK3FFDTBSO4PS/Givenchy_2016-23+FIN_Page_058.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089684169-JOTY5FJNOB1C53TTA0MC/Givenchy_2016-23+FIN_Page_059.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089672595-0BIQT0PJCDDEYWO6WEJS/Givenchy_2016-23+FIN_Page_060.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089674900-XL3EX0ZEMZN2AE7TFA9J/Givenchy_2016-23+FIN_Page_061.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089681698-17V7HUEHCVAECX7WR0U4/Givenchy_2016-23+FIN_Page_062.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089687200-KG3LA6EK0O7R77RPECPO/Givenchy_2016-23+FIN_Page_063.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089688520-MGHTZNZ5EVFWBAGT0CN2/Givenchy_2016-23+FIN_Page_064.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089693311-35VMVL6YE6ALYCAK5QSM/Givenchy_2016-23+FIN_Page_065.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089693436-NO4603QHZOSTULYH9WHJ/Givenchy_2016-23+FIN_Page_066.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089698611-201HJ46F1TQ1N69DNWPF/Givenchy_2016-23+FIN_Page_067.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089698994-J6Z8GWO0XA7VHSL65KPJ/Givenchy_2016-23+FIN_Page_068.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089700249-IZSX8FUF1WLBNCP45HIZ/Givenchy_2016-23+FIN_Page_069.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089700856-GIX6VY6O17SZM8VMZ8FS/Givenchy_2016-23+FIN_Page_070.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089706307-LOT6E9TDB9LE86OXNC0N/Givenchy_2016-23+FIN_Page_071.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089702966-OQVE77CGWY74UOX1QBFP/Givenchy_2016-23+FIN_Page_072.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089706560-B3K2PVK5XQH5M8HI9XSN/Givenchy_2016-23+FIN_Page_073.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089709459-GWFXZ92KZALLWF55ONV6/Givenchy_2016-23+FIN_Page_074.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089709071-SBJZHGXF494XB6J11FYP/Givenchy_2016-23+FIN_Page_075.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089724949-IEWUOFI4KB7Q1YDFOEYV/Givenchy_2016-23+FIN_Page_076.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089724691-NWU0GOTIZ7ZU1N13ZFWB/Givenchy_2016-23+FIN_Page_077.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089729202-OOGV8JLI6D0C5F0KSPRT/Givenchy_2016-23+FIN_Page_078.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089739074-BSEM3A217Z71ZGHRJX1N/Givenchy_2016-23+FIN_Page_079.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089748678-WMGSEK90P3E7NW579U4G/Givenchy_2016-23+FIN_Page_080.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089748791-8G44U9JK0N2HTXJP02K3/Givenchy_2016-23+FIN_Page_081.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089769476-ELLCAR97XPF17DOS87SI/Givenchy_2016-23+FIN_Page_082.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089757810-OUNWL7FK62WIA1UX7HAY/Givenchy_2016-23+FIN_Page_083.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089770129-FQT6FPKY9NNSPUOP8P48/Givenchy_2016-23+FIN_Page_084.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089782140-9J6G8M0OKO1Z7C5OBQLO/Givenchy_2016-23+FIN_Page_085.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089783644-N2GYD6EAWEGEA63ULRC1/Givenchy_2016-23+FIN_Page_086.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089801496-74Q0SKR5MH3GSMGSTWHX/Givenchy_2016-23+FIN_Page_087.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089797080-WKNOUSLVM9A2NIHCLQXT/Givenchy_2016-23+FIN_Page_088.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089810200-IK5NQOC70GR8D24HR8YP/Givenchy_2016-23+FIN_Page_089.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089809719-G3JGAPQL6EI6EBEB8D03/Givenchy_2016-23+FIN_Page_090.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089813840-FKFOTKS0IO4EJ2O9449K/Givenchy_2016-23+FIN_Page_091.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089812269-33KFZORLWPFN633GB8D3/Givenchy_2016-23+FIN_Page_092.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089814580-EF7FR0KHSNUIHPMDZHQJ/Givenchy_2016-23+FIN_Page_093.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089816367-YTGEJN040R2KZGGW2OU4/Givenchy_2016-23+FIN_Page_094.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089833281-36SQ8PZZZS8VOGXAH4XL/Givenchy_2016-23+FIN_Page_095.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089822628-PQRKGPRGY8YUJHKJ0KAC/Givenchy_2016-23+FIN_Page_096.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089824838-1YZRDQ2D885WLDB8Z7BV/Givenchy_2016-23+FIN_Page_097.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089834044-FLP6LEDW8ZCI5XOXZU9F/Givenchy_2016-23+FIN_Page_098.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089849546-JJVM7C70U0RM2GJ7T4MK/Givenchy_2016-23+FIN_Page_099.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089860155-DEC2C5SCSPHOQVMQLD8X/Givenchy_2016-23+FIN_Page_100.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089869000-99J3ZCSM14Z59EOS6XGN/Givenchy_2016-23+FIN_Page_101.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089875530-7AG2KJBYU6JH4XNTGGET/Givenchy_2016-23+FIN_Page_102.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089905522-CYEUK8TWGX3JSX8G27G1/Givenchy_2016-23+FIN_Page_103.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089915023-WT09QWR5HCUCSVFIQ5OS/Givenchy_2016-23+FIN_Page_104.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089927847-MEP9M3KNO5A0YVN8JC3E/Givenchy_2016-23+FIN_Page_105.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089920217-E2HBOISTKM4CMBPVOFGU/Givenchy_2016-23+FIN_Page_106.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089934500-KK6GG6CLZXZD09XSJ6S6/Givenchy_2016-23+FIN_Page_107.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089942824-51E3AXELUPREXZU7VWN9/Givenchy_2016-23+FIN_Page_108.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089948123-84ZAIJNQA8A652XSHQTN/Givenchy_2016-23+FIN_Page_109.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089972726-ORCTCQ5A0W9XXLNGYPXM/Givenchy_2016-23+FIN_Page_110.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089973140-1X2KQ8WIKG6RGRXB2T5J/Givenchy_2016-23+FIN_Page_111.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089976453-PSMWC4JPPJ9U15PUG9HZ/Givenchy_2016-23+FIN_Page_112.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089976186-WL7J84AU090ERZDQGOPO/Givenchy_2016-23+FIN_Page_113.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089980929-XR9FQ3CGUZRB4RI3J3UE/Givenchy_2016-23+FIN_Page_115.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089978399-QU3T21WCHHI9FHA8VFOW/Givenchy_2016-23+FIN_Page_116.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089987122-QKLBLE4YBLW3DGWSCIYM/Givenchy_2016-23+FIN_Page_117.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089986366-DDB2ND5G9U0C29B48VIH/Givenchy_2016-23+FIN_Page_118.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089993915-64K8P6DFGKKK8CVS9X5O/Givenchy_2016-23+FIN_Page_119.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525089992689-CI8PH30Y5FTQG92VMUSE/Givenchy_2016-23+FIN_Page_120.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090011957-OS9OJANISE77W8LRPN4K/Givenchy_2016-23+FIN_Page_121.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090005269-ZQGVC2JKEETXIQHP0GR2/Givenchy_2016-23+FIN_Page_124.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090012386-CE1G6QPQLLEGD155GTCQ/Givenchy_2016-23+FIN_Page_125.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090055502-D1LVA16EOC2LZ1TWABYU/Givenchy_2016-23+FIN_Page_143.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090056832-XGY4PWDJX36UJ5PN94HI/Givenchy_2016-23+FIN_Page_144.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090065177-2DK6JH74WQT7N81LAYQY/Givenchy_2016-23+FIN_Page_147.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090060449-TPPSK6F1J7XV7I8FD418/Givenchy_2016-23+FIN_Page_148.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090068858-PZYK0391CAD02H4NB8OI/Givenchy_2016-23+FIN_Page_150.jpg)
![Givenchy.com](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525090069596-WQH2D2B9Q16WH5WOA426/Givenchy_2016-23+FIN_Page_151.jpg)"
77,Godiva Chocolates,godiva-chocolates,/archive/godiva-chocolates,archive,,Archive,0,"Digital — Group Creative Director, R/GA Brand Design

  Digital brand experience and e-commerce design for Godiva Chocolates. The project reimagined the luxury",,2026-04-26 22:44:55.749446+00:00,0,,"Digital — Group Creative Director, R/GA Brand Design

Digital brand experience and e-commerce design for Godiva Chocolates. The project reimagined the luxury chocolatier's digital presence, covering website design, product presentation, gifting experiences, and brand storytelling across digital platforms.

![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173208356-F8Q9VY3CBEKYLBKHMH3B/RGA%2BGodiva___BrandFoundations.017.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173207520-DM7AEJGILYLT4Y89X971/RGA%2BGodiva___BrandFoundations.018.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173216267-ICH9FRY77CSW5ZIQX9VR/RGA%2BGodiva___BrandFoundations.019.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173218429-OJ6BQF55ARO8PX5TFO0V/RGA%2BGodiva___BrandFoundations.020.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173224447-S7AZV861JJZVHQ1TJFC2/RGA%2BGodiva___BrandFoundations.021.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173225373-DXHLSNFS3QK1T6VG066M/RGA%2BGodiva___BrandFoundations.022.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173239367-A9YMW1MAF73PAE0SFVYL/RGA%2BGodiva___BrandFoundations.023.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173232022-5SWSDHZXWNLZICDJNSU7/RGA%2BGodiva___BrandFoundations.024.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173240952-3P72Y522GPL1NDP18SGI/RGA%2BGodiva___BrandFoundations.025.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173241209-23P4PJT9ZW0EBSDHENDP/RGA%2BGodiva___BrandFoundations.026.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173249472-BX1LH0OVPQYD9E9ZKIAV/RGA%2BGodiva___BrandFoundations.027.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173250900-RRP3VT41ZTP6UWTFF0ND/RGA%2BGodiva___BrandFoundations.028.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173271282-GZ7JYT5NYW3MEAM43MT2/RGA%2BGodiva___BrandFoundations.029.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173276608-2BI1M7LA32QTEP8GAWLQ/RGA%2BGodiva___BrandFoundations.030.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173286639-TKGT4XH58D4LYIOXSXPT/RGA%2BGodiva___BrandFoundations.031.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173286042-CCSI3SW1BDFMH7G0MBVC/RGA%2BGodiva___BrandFoundations.032.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173296557-ZYZ9SFMIY8C2NQS8N77T/RGA%2BGodiva___BrandFoundations.033.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173289242-O0ELGEXT6ZOXEYQ3MJSD/RGA%2BGodiva___BrandFoundations.034.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173291410-V3Y522NCFDDTH0BJ1BBM/RGA%2BGodiva___BrandFoundations.035.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173294700-4KQS9IU7WLV2JU6ZNXNT/RGA%2BGodiva___BrandFoundations.036.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173296600-A4K65EJN5JVTYPJRRGSB/RGA%2BGodiva___BrandFoundations.037.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173306371-HKWHWMGIPEATE9M00273/RGA%2BGodiva___BrandFoundations.038.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173307656-O8BU2Z7DR422574ACXHH/RGA%2BGodiva___BrandFoundations.039.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173319624-P8GFWN5VX7L3F5HJNBSL/RGA%2BGodiva___BrandFoundations.040.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173326923-45JW9FBM21IPUVFQMX0F/RGA%2BGodiva___BrandFoundations.041.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173321334-8AV3WA721TZOXHOO8E0C/RGA%2BGodiva___BrandFoundations.042.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173323074-AFKJEJKDNPQRCZCR1TSJ/RGA%2BGodiva___BrandFoundations.043.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173325763-4TGGQ8NLASHEC27D6RRA/RGA%2BGodiva___BrandFoundations.044.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173331763-IXJZBZCV19RKDP2YZSAO/RGA%2BGodiva___BrandFoundations.045.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173331765-IQHRQNCR0E57NC1ZGO1J/RGA%2BGodiva___BrandFoundations.046.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173337696-OQV4AUH1LY8YI679M2XK/RGA%2BGodiva___BrandFoundations.047.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173349548-FHATB6W8UCAUWFFOR72P/RGA%2BGodiva___BrandFoundations.048.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173342972-CGNS1AVJJNCZA3XYQ6ZF/RGA%2BGodiva___BrandFoundations.049.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173345684-26O8MPR1IYF74032CUDK/RGA%2BGodiva___BrandFoundations.050.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173348198-K3SN6BCOVOUXIKNDYGT3/RGA%2BGodiva___BrandFoundations.051.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173356956-TMD3EQVLWBMBYTGN9JQV/RGA%2BGodiva___BrandFoundations.052.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173361129-6THVGYHTDGM0BVF6XFUG/RGA%2BGodiva___BrandFoundations.053.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173359830-LEMCVN6CC1TI13K6DSTE/RGA%2BGodiva___BrandFoundations.054.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173362165-AOSTCQI9GWQBMN8W3D8S/RGA%2BGodiva___BrandFoundations.055.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173373133-0PT6QS0Z8EY7KTB8XAWD/RGA%2BGodiva___BrandFoundations.056.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173379897-E8P0Y1U9WW6QQYWQY6VA/RGA%2BGodiva___BrandFoundations.057.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173374514-MZMWV0IN88ML7OPM05E2/RGA%2BGodiva___BrandFoundations.058.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173382011-80FX45N8749ZMJYN5AJM/RGA%2BGodiva___BrandFoundations.059.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173393645-N7P2UGUOG6Y84OEUUWZ6/RGA%2BGodiva___BrandFoundations.060.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173401266-YUGP18WPW633GKDIHSY4/RGA%2BGodiva___BrandFoundations.061.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173396595-MW5GWA0698JIP9X7NIH6/RGA%2BGodiva___BrandFoundations.062.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173399285-6VIYTYMMA7MXAP06J22X/RGA%2BGodiva___BrandFoundations.063.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173409773-03SIFA9YRKPZEBDC2X3I/RGA%2BGodiva___BrandFoundations.064.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173421578-2UTWLOKLKL46AVXESC7Y/RGA%2BGodiva___BrandFoundations.065.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173413081-NVOHKY17B0KPQQPV4E0Q/RGA%2BGodiva___BrandFoundations.066.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173419485-HJAU3W74WJBFV9AOM6T8/RGA%2BGodiva___BrandFoundations.067.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173431673-KPZ0AZB86E14C5SBSELM/RGA%2BGodiva___BrandFoundations.068.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173442775-JG8SGRMCAUQFBVWCCFAP/RGA%2BGodiva___BrandFoundations.069.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173445857-R1T9O12C4GL8ZP8MG4O1/RGA%2BGodiva___BrandFoundations.070.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173446799-GVMP0EGFTC3Z58CCDOTA/RGA%2BGodiva___BrandFoundations.071.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173470199-45SX6B8YN4L9PTPXANVN/RGA%2BGodiva___BrandFoundations.072.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173470628-5M1X5RDMC334AEQHO3XT/RGA%2BGodiva___BrandFoundations.073.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173499941-998ZI37BYAELTP0D2A8R/RGA%2BGodiva___BrandFoundations.074.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173498241-DWGVXLIFSSKRSQW4MZ0V/RGA%2BGodiva___BrandFoundations.075.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173514276-9K69TTX6DP1B13OAACKB/RGA%2BGodiva___BrandFoundations.076.jpeg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525173815869-DPUHTPXGHH5IT2UDSB0Y/GODIVA_SO+%281%29.jpg)
![Godiva Chocolates](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525174447974-F404IW8FYLSWIMUDKTCU/1.jpg)"
78,Google Scout,google-scout,/archive/google-scout,archive,,Archive,0,"Digital — Group Creative Director, R/GA Brand Design

  Digital product design for Google Scout, a visual search and discovery platform. The project developed t",,2026-04-26 22:44:55.663275+00:00,0,,"Digital — Group Creative Director, R/GA Brand Design

Digital product design for Google Scout, a visual search and discovery platform. The project developed the user interface, interaction design, and visual language for a product that leveraged Google's image recognition technology for shopping and exploration.

![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349594141-AXWPGXXZ87T506T1P79I/Google+Scout_VSNK_+brand+2_Page_01.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349594335-5FYBDPYYA44YTBTVPS2K/Google+Scout_VSNK_+brand+2_Page_02.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349600657-TA0WSILOU6DS4X6HUXAN/Google+Scout_VSNK_+brand+2_Page_03.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349668934-LLRDNLM84TAQONRONGNP/Google+Scout_VSNK_+brand+2_Page_04.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349627761-E2HYGFJFPT2OSD5S0XUM/Google+Scout_VSNK_+brand+2_Page_05.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349632912-9X4GFERE4D9J74MAAZXT/Google+Scout_VSNK_+brand+2_Page_06.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349639618-C6OBSZT54O24ZDW6XGET/Google+Scout_VSNK_+brand+2_Page_07.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349645196-9OECNQCLLHPNZN6L56SU/Google+Scout_VSNK_+brand+2_Page_08.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349649120-SPDH91ATY3T8VUJNE6KR/Google+Scout_VSNK_+brand+2_Page_09.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349652662-XUNWWJU1OMNJFH4HGPNG/Google+Scout_VSNK_+brand+2_Page_10.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349664467-LX5OABRDZY0X45Y1D9IX/Google+Scout_VSNK_+brand+2_Page_11.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349668029-SQPTTG7C0BC068KJC4U4/Google+Scout_VSNK_+brand+2_Page_12.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349675886-B2TI2R5672U1LVXRI5NO/Google+Scout_VSNK_+brand+2_Page_13.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349677038-KWRJ8SGX878IM5MDHT4P/Google+Scout_VSNK_+brand+2_Page_14.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349682709-15LX8O0BGI055X4611YB/Google+Scout_VSNK_+brand+2_Page_16.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349685826-CC5WYKVCWNLFSSBKU91I/Google+Scout_VSNK_+brand+2_Page_17.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349713224-M5H779JGLM6N9LNKT8O6/Google+Scout_VSNK_+brand+2_Page_19.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349739970-3IX42F138OZPHVNNP6W5/Google+Scout_VSNK_+brand+2_Page_21.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525349740236-0D2DFAKXCLG1VK9O3DO7/Google+Scout_VSNK_+brand+2_Page_22.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586497094-ID2YY93Z90QQ16ULEJKO/Google+Scout_VSNK_+brand+2_Page_25.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586526559-4N9HSTCESUUBPR0AN10M/Google+Scout_VSNK_+brand+2_Page_35.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586539431-75SBZGYPV64Z8QF96ENG/Google+Scout_VSNK_+brand+2_Page_37.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586541022-81VA3ZFBHZ7QBGZWBS2W/Google+Scout_VSNK_+brand+2_Page_38.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586546214-Z9LKNAXW3OH40REKMXTY/Google+Scout_VSNK_+brand+2_Page_40.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586580304-BMQXXK8K1SBNX7LJJ872/Google+Scout_VSNK_+brand+2_Page_41.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586589384-NWYC3SEOF5N6JONVHS91/Google+Scout_VSNK_+brand+2_Page_42.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586603079-WK633WJMZT1IAS8TY9WO/Google+Scout_VSNK_+brand+2_Page_43.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586605939-WGRX165GT9O4TZKX6CIX/Google+Scout_VSNK_+brand+2_Page_44.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586608471-VS6GM1X0TW5NLDBOLM8R/Google+Scout_VSNK_+brand+2_Page_45.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586612275-QBBGOW4J0EFM6PKK3LL4/Google+Scout_VSNK_+brand+2_Page_47.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586626195-1H3QH5B6Y5NNU9C4P773/Google+Scout_VSNK_+brand+2_Page_48.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586670382-Y5I2OCSTKJOJH1XOOWXG/Google+Scout_VSNK_+brand+2_Page_51.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586690847-NUBQS4JEAS5L40QPYMI5/Google+Scout_VSNK_+brand+2_Page_52.jpg)
![Google Scout](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1527586647816-X35OIMQRJBDZ8QXS3KD8/Google+Scout_VSNK_+brand+2_Page_50.jpg)"
79,Hotel Amstelkwartier,hotel-amstelkwartier,/archive/hotel-amstelkwartier,archive,,Archive,0,"Graphic Design — Creative Director, ...,staat

  Brand identity and environmental design for Hotel Amstelkwartier in Amsterdam. The project developed the hotel'",,2026-04-26 22:44:55.592537+00:00,0,,"Graphic Design — Creative Director, ...,staat

Brand identity and environmental design for Hotel Amstelkwartier in Amsterdam. The project developed the hotel's visual identity system including logo, typography, interior signage, collateral, and environmental graphics for a new hospitality destination in Amsterdam's emerging Amstelkwartier neighborhood.

![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902494028-NKNKG2W39YZ1N5M56E88/SN_Logostudy_NMK_Page_02.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902369009-QZ2VG7VV5N9X724KJ6U2/SN_Logostudy_NMK_Page_03.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902372099-FF40OI7S9PBZ8AGBSFE0/SN_Logostudy_NMK_Page_05.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902374273-HKARJAIDRDC9AZS8ILXL/SN_Logostudy_NMK_Page_06.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902376056-B7QSZB70HS85BIFXG45N/SN_Logostudy_NMK_Page_07.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902382461-DSXV7FF1I9RU6P1SJJ5K/SN_Logostudy_NMK_Page_08.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902383662-YJ43BPYK3TMQ02MU451F/SN_Logostudy_NMK_Page_09.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902384860-IIA0JYCIPFN5LDASRAI2/SN_Logostudy_NMK_Page_10.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902387737-4A65DUC3A7WDWF5Z3R3R/SN_Logostudy_NMK_Page_11.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902475250-OAOFMJXPOJFXLT0MTKBM/SN_Logostudy_NMK_Page_12.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902477744-LOL5P2C8RS7CJ2JT80K0/SN_Logostudy_NMK_Page_14.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902478549-MJAJE59OIZTIW75I4HGH/SN_Logostudy_NMK_Page_15.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902479635-RCFVEWDYVBL0Y43969I9/SN_Logostudy_NMK_Page_16.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902496385-T7BKX81I55OJSJY8Y4WZ/SN_Logostudy_NMK_Page_19.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902497550-BICXXRZ8NUNOU05GWH0B/SN_Logostudy_NMK_Page_20.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902498286-JGEZMYP3B0NL3M7FBXFO/SN_Logostudy_NMK_Page_21.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902565766-DQNHWMEIUD047QX97EUT/SN_Logostudy_NMK_Page_17.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902557673-YQKO8IOZTOP9K3P5CZSA/SN_Logostudy_NMK_Page_22.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902561056-XH808U138B8B3KB2V5SP/SN_Logostudy_NMK_Page_24.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902562373-IASWRAXQJ7JYNKKR2RUU/SN_Logostudy_NMK_Page_25.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902564368-X4PC2FO3AW4W3SI91SDO/SN_Logostudy_NMK_Page_26.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902565607-XY0ORMUPKREXQV9RFN05/SN_Logostudy_NMK_Page_27.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902567807-27UNJJE153NS2FBE1LCL/SN_Logostudy_NMK_Page_29.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902569001-28HST9J820C7MPYL0SKG/SN_Logostudy_NMK_Page_30.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902631689-HMUQ8792LGF1OFBJ55YI/SN_Logostudy_NMK_Page_28.png)
![Hotel Amstelkwartier](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589902632681-S8Q96BW90HWMDPYYCQ26/SN_Logostudy_NMK_Page_32.png)"
80,Hyundai 'N' Brand Book,hyundai-n-branding,/archive/hyundai-n-branding,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:55.524249+00:00,0,,"Graphic Design

![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901686071-WO14TXA97O8LO6BW8MHY/Hyundai_BrandBook_Page_002.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901696015-Z0BV0V21V36ET0JVY8Y3/Hyundai_BrandBook_Page_003.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901694755-SL61OZAW9H9RUM1SOUIP/Hyundai_BrandBook_Page_004.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901699439-M46IQ9S9MO8W7WCY18FY/Hyundai_BrandBook_Page_005.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901698236-Q9EO7Q2NRRNJVU1TR7KS/Hyundai_BrandBook_Page_006.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901706221-XZWO69TQWXJOTZKNZ8XG/Hyundai_BrandBook_Page_009.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901712360-NYUGL6NIWMC5BFEMR1LF/Hyundai_BrandBook_Page_010.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901715048-MM818HPBQ9YEHDQL6VIU/Hyundai_BrandBook_Page_011.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901720420-QHG15QN8F0KT78U4TCP2/Hyundai_BrandBook_Page_012.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901720185-G5QPC7U4IULMOFTYKWGM/Hyundai_BrandBook_Page_013.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901720900-R3V2TWM9CUU88S8RS9ST/Hyundai_BrandBook_Page_014.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901726177-OIEPE5EKCY41KGKZAGCT/Hyundai_BrandBook_Page_015.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901721898-6M2CXEPZZAFO7EQZHXUP/Hyundai_BrandBook_Page_016.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901722727-RQJR2GU68OA2IOTRCIAQ/Hyundai_BrandBook_Page_017.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901740153-GXZ7TBXEXUS6WG0LEAF4/Hyundai_BrandBook_Page_018.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901728811-YNTDTOBNXHWP3LHJBUSL/Hyundai_BrandBook_Page_019.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901739133-BQN3BHQMV0E5WNERXUNQ/Hyundai_BrandBook_Page_020.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901740316-50Q2XJIEXVOQ6OU8M70A/Hyundai_BrandBook_Page_021.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901740580-JBMC4ATIMGXHXG294EZB/Hyundai_BrandBook_Page_022.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901745577-RB1AMFCBZNA49HQW2M6T/Hyundai_BrandBook_Page_023.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901741134-D3GLVIYBS64372P501YS/Hyundai_BrandBook_Page_024.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901742667-I6JOJZHZABKBMZGGYDJZ/Hyundai_BrandBook_Page_025.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901749796-B0G2WOHNM52ER3ROUIU3/Hyundai_BrandBook_Page_026.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901754951-VM8OZ6JZNOMJU7B79VX0/Hyundai_BrandBook_Page_027.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901760416-OHCNR3JBQX4IWTPS3LJY/Hyundai_BrandBook_Page_028.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901759035-5XBD87YMXQQ4DXBDCIS1/Hyundai_BrandBook_Page_029.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901769995-IEBWL5NXV2QGUT2EJK6U/Hyundai_BrandBook_Page_030.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901769411-YPZGXULCMBVWOJG4PCWI/Hyundai_BrandBook_Page_031.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901770209-MY11HL1PDYFKJSGL8GQ0/Hyundai_BrandBook_Page_032.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901774181-GN6MWLADMNRY321ECM2A/Hyundai_BrandBook_Page_033.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901771335-GXRS45SD91BLWJWW1811/Hyundai_BrandBook_Page_034.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901778460-NLLP7CG1LX6V409EUA7Y/Hyundai_BrandBook_Page_035.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901775816-35J4PSRBC8UJM8ZVOVY5/Hyundai_BrandBook_Page_036.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901780413-85QJIFC0KYK19FJVCVHJ/Hyundai_BrandBook_Page_037.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901779592-G8FFAGUXUPJUG6KO263O/Hyundai_BrandBook_Page_038.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901783719-K2C5R712EFYJGU147ZE7/Hyundai_BrandBook_Page_039.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901789325-ZW6V7O3AFHHP3TQKMCUS/Hyundai_BrandBook_Page_040.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901788976-P80IPL3476HORHBZOWYY/Hyundai_BrandBook_Page_041.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901790494-PC0R24BZ4US15E0KF8OV/Hyundai_BrandBook_Page_042.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901792712-2GQ2LTFNNV2E50COHWK3/Hyundai_BrandBook_Page_043.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901791014-Y0UF5DKEE2RBH6AM45P3/Hyundai_BrandBook_Page_044.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901805837-XDDZKHAQGPSU3KRFCNE6/Hyundai_BrandBook_Page_045.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901803471-HSA2UZ2IB3NK1R63O0MP/Hyundai_BrandBook_Page_046.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901813841-AFQVKUH3G6U9D1KTUMIU/Hyundai_BrandBook_Page_047.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901809142-V5DGWX2K6XB0PKWUBAZC/Hyundai_BrandBook_Page_048.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901816166-WZMRFR6D9BLJX59MV3EW/Hyundai_BrandBook_Page_049.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901814810-IQAO70T600BMSFV3FSFF/Hyundai_BrandBook_Page_050.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901815878-RHKY3FORSS0RH98848OI/Hyundai_BrandBook_Page_051.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901822864-P8F6KWQLKLEKSD2FEY5K/Hyundai_BrandBook_Page_052.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901817554-07D04IVFON3LFQJQGVEN/Hyundai_BrandBook_Page_053.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901818223-AGBG3FMWZXT1VZ12RF27/Hyundai_BrandBook_Page_054.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901822668-6UCYOTXN5Q17DVJZ4P23/Hyundai_BrandBook_Page_055.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901829512-UJ38KPG7K8KNZKEGTF6E/Hyundai_BrandBook_Page_056.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901825510-2VELP3FQ1GT430G2E7X1/Hyundai_BrandBook_Page_057.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901828141-0QJ8N6WR0DPYJEO3OTHI/Hyundai_BrandBook_Page_058.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901833221-84S7B1NAUAAA12T7829B/Hyundai_BrandBook_Page_059.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901833220-D1VEG978EYR5GKOJ4G6J/Hyundai_BrandBook_Page_060.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901833652-T3CE6TEENMWHP05Y0UC9/Hyundai_BrandBook_Page_061.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901833880-B8E9V1HBQK3QSCTQNV87/Hyundai_BrandBook_Page_062.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901841145-H3XPKTLK0SDX2N618TZI/Hyundai_BrandBook_Page_063.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901835588-FX0K16LN6BTOPFNR739T/Hyundai_BrandBook_Page_064.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901848178-ZQ5AOZ3KQAQFG7VEW3V1/Hyundai_BrandBook_Page_065.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901846447-NMSC5ZETYE7CB9HHPNX8/Hyundai_BrandBook_Page_066.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901852572-BTCPW0QP6LBKL2788FZ4/Hyundai_BrandBook_Page_067.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901856560-7SJZ8NI5PAXGFNOE7GMS/Hyundai_BrandBook_Page_068.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901862547-5GPHZ78817AF1Y9OGAE0/Hyundai_BrandBook_Page_069.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901864718-L7QF2VEKREA4O0ALCRL4/Hyundai_BrandBook_Page_070.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901864875-ASUM1G4B0EBVZ3Y8H7PX/Hyundai_BrandBook_Page_071.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901865170-6C9UUEVM3AYYK74YFC1R/Hyundai_BrandBook_Page_072.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901865351-G0YRP5YPAXXRFC495QFD/Hyundai_BrandBook_Page_073.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901865586-PWMYCTACTR77J2Q5A451/Hyundai_BrandBook_Page_074.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901870659-ZJXQNE65PREN1XDB4WZJ/Hyundai_BrandBook_Page_079.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901870795-AZO57AMR3ABBODHIPGI1/Hyundai_BrandBook_Page_080.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901871373-9UGKDXGR53OWOJHFD2SK/Hyundai_BrandBook_Page_081.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901871469-R3VHLITY0QAF5825TNPU/Hyundai_BrandBook_Page_082.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901871900-9MSHUCUG0O87JI12BTHV/Hyundai_BrandBook_Page_083.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901878758-1A3CL7SYRL7V5GG8DBZN/Hyundai_BrandBook_Page_084.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901872684-P3V43W4ZQ9UKPU6B0JCR/Hyundai_BrandBook_Page_085.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901873992-JIUJQ4YHU7GO7F4VNIK4/Hyundai_BrandBook_Page_086.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901878699-F3Y3PLQOLHW9Z2YYNU9B/Hyundai_BrandBook_Page_087.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901889923-EKAIZFP3JFGJQN7Y8FS7/Hyundai_BrandBook_Page_088.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901880029-X3LQBV0EXXF0VPYETQ4D/Hyundai_BrandBook_Page_089.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901885187-2E293JQZUF8QDZVHK5CS/Hyundai_BrandBook_Page_090.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901887784-NA6NCIYD9K6BP7AJY4YF/Hyundai_BrandBook_Page_091.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901888560-N589G4HHS8BUZ0Y6FBCS/Hyundai_BrandBook_Page_092.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901889315-L7TO546OYJIW1QJAWEII/Hyundai_BrandBook_Page_093.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901890709-2XTN2CJEA0NIGUXF17BX/Hyundai_BrandBook_Page_095.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901891690-145L6QVP4F1H4QPD3NP7/Hyundai_BrandBook_Page_099.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901892213-5PE6IM77SJ674KEB1S0I/Hyundai_BrandBook_Page_100.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901892636-X96VWSS81OXZPRZVT46H/Hyundai_BrandBook_Page_101.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901892695-8D9EQ2U496V46JKYBVDE/Hyundai_BrandBook_Page_102.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901893084-AOD4RRJ70DTJKVRFPT08/Hyundai_BrandBook_Page_103.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901894025-M01SB244X8WWTHU1I47C/Hyundai_BrandBook_Page_104.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901894617-7HGUTU2MT1RYB2X3U3RB/Hyundai_BrandBook_Page_105.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901895404-ROKB61QZFIBLKZJGWSAL/Hyundai_BrandBook_Page_106.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901895543-HD3MBCUYQ341RPZOYK61/Hyundai_BrandBook_Page_107.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901896135-2H574OSK6ECPVGI8XMV8/Hyundai_BrandBook_Page_108.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901896190-CYR09LU1FWHFZB3R7EOU/Hyundai_BrandBook_Page_109.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901896737-WCC8JTNXC8RJY589IA2D/Hyundai_BrandBook_Page_110.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901897266-HTR64GC17003KB899XO8/Hyundai_BrandBook_Page_111.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901897202-D25DTJM2XUSV6QBZU127/Hyundai_BrandBook_Page_112.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901897934-FG8H77M7KFT6VSGAQDWC/Hyundai_BrandBook_Page_113.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901898126-A26PZFOGVC3ZOFIAX3U3/Hyundai_BrandBook_Page_114.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901898490-JLCICKVUXMO6RSYLFSAG/Hyundai_BrandBook_Page_115.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901898591-LBOEZ1TEEMU8YKZ1COV7/Hyundai_BrandBook_Page_116.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901899109-FCBJWNIXBT4XNSMXA6EU/Hyundai_BrandBook_Page_117.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901899299-FAEV2FNJQ3Y6UQOYC3LB/Hyundai_BrandBook_Page_118.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901899685-23FF42ZPGILLJDCQ1PX3/Hyundai_BrandBook_Page_119.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901900033-4F2YZOGGRI5TXXMWRO6K/Hyundai_BrandBook_Page_120.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901900180-VTTUXFBDKA8COQAM1G7Y/Hyundai_BrandBook_Page_121.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901900734-AVWLQ14UM578BGYRWQKJ/Hyundai_BrandBook_Page_122.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901902844-WCFXHRQ7KHPCLV91Q8RS/Hyundai_BrandBook_Page_126.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901903519-273BRDOTKO1GRD3TA0NA/Hyundai_BrandBook_Page_127.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901903932-F8MKZA7LDAMZTLVDC8JY/Hyundai_BrandBook_Page_128.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901904363-B67Y7ICHFK3KVHCH2WT1/Hyundai_BrandBook_Page_129.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901906137-EGSHP1G1FYOIBYF5J3Q4/Hyundai_BrandBook_Page_132.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901907019-GP13JN2QGHU5CFGM5LGL/Hyundai_BrandBook_Page_133.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901911796-N5NNKQ7J7IQB194UP2BF/Hyundai_BrandBook_Page_134.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901914713-CDJ9XK1ZFABIWU9B0H7K/Hyundai_BrandBook_Page_135.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901922466-DU7CD5IXF49ITTRQV5OM/Hyundai_BrandBook_Page_136.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901916341-YAEQRNYZ7BZ4TLO3JVQW/Hyundai_BrandBook_Page_137.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901922375-OAHL7RNNYNUNSM2530CD/Hyundai_BrandBook_Page_138.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901922835-BJI2GHKY7WU09BVOFBXZ/Hyundai_BrandBook_Page_139.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901926819-6N98M611CWE13C3GLLXX/Hyundai_BrandBook_Page_140.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901924224-PJVKQRB9MSIK46GZIYTL/Hyundai_BrandBook_Page_141.png)
![Hyundai 'N' Brand Book](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589901924959-UYBVVM4NQNQPNXA6PXB2/Hyundai_BrandBook_Page_142.png)"
81,IKEA Family Identity,ikea-family-identity,/archive/ikea-family-identity,archive,,Archive,0,"Graphic Design — Creative Director, ...,staat

  Brand identity design for IKEA Family, the retailer's loyalty membership program. The project developed a visua",,2026-04-26 22:44:55.412913+00:00,0,,"Graphic Design — Creative Director, ...,staat

Brand identity design for IKEA Family, the retailer's loyalty membership program. The project developed a visual system that extended IKEA's democratic design philosophy into a community-driven brand experience spanning digital, retail, and communications touchpoints.

![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163864096-NJS67PCGBOERYAPORB0P/IF_Test_Page_01.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163863381-D9CYOXPTM60G4BG8KBPR/IF_Test_Page_02.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163866224-L80YNEAK4N6VHMAV4MF3/IF_Test_Page_03.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163866933-X4I5BOB3K8PON3JDQ2OQ/IF_Test_Page_04.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163868771-WKS0FJMOSET7BZHF7SD5/IF_Test_Page_05.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163869997-GE2XC7BUMDWCYGB7D9MB/IF_Test_Page_06.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163871789-0132K2PGZFOB0E9BXZ6C/IF_Test_Page_07.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163871947-7EV9XEIEODSAC7SRD3W4/IF_Test_Page_08.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163875773-GDB79ZGJUHNMOHOFSI7S/IF_Test_Page_09.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163876939-56W1XW8TKE9F0SRZ6WCJ/IF_Test_Page_10.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163900856-V2KT238Y1IB5PD352E28/IF_Test_Page_11.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163879094-42CHWA18DCTS96BOZM3R/IF_Test_Page_12.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163897142-9RPMY40H9OBMPZF2UKDG/IF_Test_Page_13.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163900498-H2VX851JC7KNZO9V8EBL/IF_Test_Page_14.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163902981-VCJWXN2C567BWMXQLVDZ/IF_Test_Page_15.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163903736-ENHG6KGMFAOXH165F80E/IF_Test_Page_16.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163905285-FLPYNU6DRXJPN8OFQ3VF/IF_Test_Page_17.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163905767-7M80Y2M594OT35FE769Z/IF_Test_Page_18.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163910177-YR3EJ3231L4J53P3UDM9/IF_Test_Page_19.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163909849-1L81F4ZUX8HHJSYZOEM0/IF_Test_Page_20.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163912359-AZE95TA58IM90B6B6D1S/IF_Test_Page_21.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163914923-7WOJSYXRG5X72O2B4HIS/IF_Test_Page_22.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163919038-HGK99NR2BJ5D939UDB38/IF_Test_Page_23.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163919520-SEFA9KZZYPS7IGFFZKV4/IF_Test_Page_24.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163921516-F0N99O9KDAARCPZL1EC0/IF_Test_Page_25.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163922350-3P4YKTQJ9X68CSWEHVOR/IF_Test_Page_26.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163925500-GY68VI1P4370VD0JRASZ/IF_Test_Page_27.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163926064-WE82OH9I1JHRV04MOLT7/IF_Test_Page_28.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163928777-H3RQD2V5VAARX1JIX3FL/IF_Test_Page_29.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163929521-3N4XQD4AMKG0XLSK9BOC/IF_Test_Page_30.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163931668-DV45D1QXOG1QOCEP7R1P/IF_Test_Page_31.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163932166-XP1MKIWBZVV8FPPZDXZB/IF_Test_Page_32.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163933866-N2PXV8OSJHMB628369EC/IF_Test_Page_33.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164034462-Q19FBWFUVXPXIP7G3WQ4/Pitch_Route_NMK_ImageBased_Page_01.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164034304-TW79FOCO4D5RFY35XIXI/Pitch_Route_NMK_ImageBased_Page_02.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164036441-R80OTCRCHAWTFXD4C1HE/Pitch_Route_NMK_ImageBased_Page_03.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164042003-9Q3DX793UHOLUIIZSMDQ/Pitch_Route_NMK_ImageBased_Page_04.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164042243-VJOV4XCLQUBOGOFX0HD1/Pitch_Route_NMK_ImageBased_Page_05.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164045879-MSFRRI7LKUQEB4C441ZW/Pitch_Route_NMK_ImageBased_Page_06.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164054768-WOIYBC1LXVKOD8G6LL2H/Pitch_Route_NMK_ImageBased_Page_07.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164065246-F00IZKPPYPGAO1QVNNUK/Pitch_Route_NMK_ImageBased_Page_10.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164079253-GJ53EYL342GIRECGYWZE/Pitch_Route_NMK_ImageBased_Page_11.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164152461-74TNZLD39UHVT9KWKLKT/Pitch_Route_NMK_ImageBased_Page_14.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164645905-7PB0AR3CKPRDF0CRFXU1/1.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164663478-4DI5R3BXB88FGIV9KH82/3.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164696293-IZZGJ9TX3BDSIGS5B1Q7/6.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164718142-3Z1Y6HASRK7TK5V681O4/10.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164620202-HHAMOVI71GT2HQEHLQ68/1.jpg)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164867709-0BMMHRMN86R27EEZ7SIE/ikeastand_1024.png)
![IKEA Family Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525164876353-OSEKSPTDOFMEFCXDXX7T/if_cards_mockup_1024.jpg)"
82,Jordan Brand '17 Collection,jordan-brand-17-collection,/archive/jordan-brand-17-collection,archive,,Archive,0,"Graphic Design — Global Creative Director, Nike Brand Design

  Brand design and campaign creative direction for Jordan Brand's 2017 seasonal collection. The vi",,2026-04-26 22:44:55.335620+00:00,0,,"Graphic Design — Global Creative Director, Nike Brand Design

Brand design and campaign creative direction for Jordan Brand's 2017 seasonal collection. The visual system spanned footwear, apparel, and accessories across performance basketball and lifestyle categories.

![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920316441-471JQE20HBIJBW1YUNGO/tumblr_orq79dhS4c1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920316742-U17ULW56GZR06B8826XB/tumblr_owo07s1DfY1qzta7uo2_r1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920318514-R7R6XBWHWHU7HSIEZBPL/tumblr_owpuj7isn91qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920318666-XOLK6AV4AGWVIDUZO4WK/tumblr_owpvdgrJjM1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920320262-O4WKXACRLERD8WGDWDN2/tumblr_owr5kjv8up1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920320495-PTFT5WP2ATXOAH7V30M3/tumblr_owr5mhPRiT1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920322278-C079WL23KLU5D5KCIMMT/tumblr_owr5no3SDP1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920323653-LDE7LPGCNXQ9ZPVG60VN/tumblr_owwkgcv1KG1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920323957-974GWL3DXWAZVM1JPG41/tumblr_owwknxzBnV1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920324994-WRSAJJ1CCKM1VKJVPE6E/tumblr_owwkoy4sBN1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920325662-0BKXR51L6EW9VY5CD178/tumblr_owwkqfq5LC1qzta7uo2_r1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920326238-E7U5D87AOHCBRX6L68MJ/tumblr_owwl6s0eY81qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920328113-C74ZF7EQARA1CH983RP6/tumblr_oxp24xk8yc1qzta7uo1_1280.jpg)
![Jordan Brand '17 Collection](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524920328758-88X2L8NDW69B0VE9EBQY/tumblr_oxp210KFOs1qzta7uo1_1280.jpg)"
83,Jordan Brand / Westbrook,jordan-brand-westbrook,/archive/jordan-brand-westbrook,archive,,Archive,0,"Graphic Design — Global Creative Director, Nike Brand Design

  Brand design and creative direction for Russell Westbrook's Jordan Brand signature line. The pro",,2026-04-26 22:44:55.273351+00:00,0,,"Graphic Design — Global Creative Director, Nike Brand Design

Brand design and creative direction for Russell Westbrook's Jordan Brand signature line. The project captured Westbrook's fearless personal style and on-court intensity through bold visual identity and campaign design.

![Jordan Brand / Westbrook](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524927359842-JK7Y95CNTKN52CG9A4I2/tumblr_p5ccihBeXG1qzta7uo1_1280.gif)
![Jordan Brand / Westbrook](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524927369451-GJ3T8A38T4QWCW1JW7PO/tumblr_p5cdt03vlK1qzta7uo2_r1_1280.gif)
![Jordan Brand / Westbrook](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524927364317-UZ9YH5Y7195X29Q0Q1TA/tumblr_p5ccuqB9Qj1qzta7uo2_r1_1280-1.gif)
![Jordan Brand / Westbrook](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524927370977-KIGMNE130DF4NRKNUL4K/tumblr_p5cclpcM7Y1qzta7uo1_1280.jpg)
![Jordan Brand / Westbrook](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524927372585-PLRB1WMZJA4PFSH0KD61/tumblr_p5cd99GSyb1qzta7uo1_1280.jpg)"
84,Koche x Nike,koche-x-nike,/archive/koche-x-nike,archive,,Archive,0,"Graphic Design — Global Creative Director, Nike Brand Design

  Brand design for the Koche x Nike collaboration with Christelle Kocher. The collection combined",,2026-04-26 22:44:55.214999+00:00,0,,"Graphic Design — Global Creative Director, Nike Brand Design

Brand design for the Koche x Nike collaboration with Christelle Kocher. The collection combined Kocher's Parisian couture craftsmanship with Nike's sportswear DNA, resulting in elevated athletic-inspired fashion pieces.

![Koche x Nike](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1696507962537-5ZWK0DX9PT52CA24FKJ7/Koche_0.001.jpeg)
![Koche x Nike](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1696507962220-J2N8RR491K8FHQIQCWIA/Koche_0.002.jpeg)
![Koche x Nike](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1696507966701-CKDE4FO1W143Y0TXW8K7/Koche_0.003.jpeg)"
85,Lincoln Center Identity,lincoln-center-identity,/archive/lincoln-center-identity,archive,,Archive,0,"Graphic Design — Group Creative Director, R/GA Brand Design

  Brand identity redesign for Lincoln Center for the Performing Arts, New York City's premier cultu",,2026-04-26 22:44:55.157162+00:00,0,,"Graphic Design — Group Creative Director, R/GA Brand Design

Brand identity redesign for Lincoln Center for the Performing Arts, New York City's premier cultural campus. The project developed a unified visual system for one of the world's leading performing arts institutions, covering all venues and programming under a cohesive brand architecture.

![Lincoln Center Identity](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525163228035-WYDEE4S1AN5LBWZYPW7U/image-asset.jpeg)"
86,Magic Leap Brand Guidelines,magic-leap-brand-guideliens,/archive/magic-leap-brand-guideliens,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:55.097034+00:00,0,,"Graphic Design

![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457216615-E7VE4C7HVTWRKEF1H9Q7/ML_Brand_Guidelines_10122019_Final_Page_176.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456154754-R3HZUVIDXG3NLCCGRQKD/ML_Brand_Guidelines_10122019_Final_Page_002.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456155097-YS3D7J3CR1U8GQSAC3N7/ML_Brand_Guidelines_10122019_Final_Page_003.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456155366-NTS7TINYDP78CE96ZJ3S/ML_Brand_Guidelines_10122019_Final_Page_004.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456155670-KE1T3793GR587QXE1NYF/ML_Brand_Guidelines_10122019_Final_Page_005.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456155688-EQ5A2ERUEVK11GWFEMRI/ML_Brand_Guidelines_10122019_Final_Page_006.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456156043-HD3ZELUIA3IG2MGUC7RN/ML_Brand_Guidelines_10122019_Final_Page_007.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456156617-5BVAUA98Q1DHHNRCZU16/ML_Brand_Guidelines_10122019_Final_Page_008.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456156937-2S9UG78R95QGACZLISR3/ML_Brand_Guidelines_10122019_Final_Page_009.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456157221-NNMNF9FN2IFXGBR412Y4/ML_Brand_Guidelines_10122019_Final_Page_010.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456157518-C53398TTAVHTXR46QUO5/ML_Brand_Guidelines_10122019_Final_Page_011.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456159951-ERHKI57XKQR75ZBZVGM9/ML_Brand_Guidelines_10122019_Final_Page_012.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456157829-Z84MFZ71H1X0PV166TN2/ML_Brand_Guidelines_10122019_Final_Page_013.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456160140-D8H80LHWUW5951X02KQE/ML_Brand_Guidelines_10122019_Final_Page_014.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456160799-NKO9M3JE1W40JQR94M3E/ML_Brand_Guidelines_10122019_Final_Page_015.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456161250-DND4LY45HOXDL9JQM7BD/ML_Brand_Guidelines_10122019_Final_Page_016.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456161391-ABQT08SZXLOEKM1NDQQH/ML_Brand_Guidelines_10122019_Final_Page_017.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456161663-JXIURKW5SNZGLSMNYBV7/ML_Brand_Guidelines_10122019_Final_Page_018.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456163718-2KBDGU3VUD46SLIB2OC5/ML_Brand_Guidelines_10122019_Final_Page_019.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456215364-7GBTN7ZHO9NALFVTDGF7/ML_Brand_Guidelines_10122019_Final_Page_020.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456187783-IPW98SQEVPT9ZK3YJEB2/ML_Brand_Guidelines_10122019_Final_Page_021.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456189139-9BLRYRQON0U7FW5ZYUMP/ML_Brand_Guidelines_10122019_Final_Page_022.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456195021-JGWX67W7JZVFTJO137OS/ML_Brand_Guidelines_10122019_Final_Page_023.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456196532-58OT2M0TENIILXBFLWRP/ML_Brand_Guidelines_10122019_Final_Page_024.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456200382-1NVXZV09CZR3QJ4EBB5D/ML_Brand_Guidelines_10122019_Final_Page_025.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456202066-B7GLA1QU3NG8UBUB6A0D/ML_Brand_Guidelines_10122019_Final_Page_026.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456204554-CPBF2GOUS3UX0L61Y77D/ML_Brand_Guidelines_10122019_Final_Page_027.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456206294-29NYWL48O9THKRO7DOFG/ML_Brand_Guidelines_10122019_Final_Page_028.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456209063-276NMXSF34C48SF973SF/ML_Brand_Guidelines_10122019_Final_Page_029.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456211568-LAWT8JDFWTH4WX70UK17/ML_Brand_Guidelines_10122019_Final_Page_030.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456212304-857NIJDKKPVNKKQAGW37/ML_Brand_Guidelines_10122019_Final_Page_031.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456213474-O28YV2VEVN6W9ZRFO7JN/ML_Brand_Guidelines_10122019_Final_Page_032.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456278305-8JIUVUJ2XH2XCQMTWI3K/ML_Brand_Guidelines_10122019_Final_Page_033.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456338664-BLNBH269BY8PMJ3C2CND/ML_Brand_Guidelines_10122019_Final_Page_034.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456350283-UW78UCW11DPXV8AQ6Z27/ML_Brand_Guidelines_10122019_Final_Page_035.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456343229-P7W3GA5J6SI1BGFCVLEQ/ML_Brand_Guidelines_10122019_Final_Page_036.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456345341-04GQLOVP27FO4T4VJ3IF/ML_Brand_Guidelines_10122019_Final_Page_037.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456389593-T73GW2PQFJLIZLMWXCPK/ML_Brand_Guidelines_10122019_Final_Page_038.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456428149-2ZPS1CTI4CX1W17CZI83/ML_Brand_Guidelines_10122019_Final_Page_039.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456390253-3HD9JUJIQRRG7FOTWXV0/ML_Brand_Guidelines_10122019_Final_Page_040.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456392173-BPWS6U3TM6Z29A81BNKI/ML_Brand_Guidelines_10122019_Final_Page_041.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456395663-KVA4CUL7F4PA0HUODV7Q/ML_Brand_Guidelines_10122019_Final_Page_042.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456397417-FZGUE0FEJOC9DWV0ZSSU/ML_Brand_Guidelines_10122019_Final_Page_043.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456420643-D25L77JFVQNNW8612NO4/ML_Brand_Guidelines_10122019_Final_Page_044.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456423334-RH8ZO4ZJG46VTD2H17V1/ML_Brand_Guidelines_10122019_Final_Page_045.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456424520-CQP6D1MT560EBNH0PAT7/ML_Brand_Guidelines_10122019_Final_Page_046.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456427995-DYBD7CNJ5RZM6L1Q76B5/ML_Brand_Guidelines_10122019_Final_Page_047.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456433991-MN7SJGLVWYTAL5ML3JDI/ML_Brand_Guidelines_10122019_Final_Page_048.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456432834-HUAM8JLEX7AIIQ7FC8JL/ML_Brand_Guidelines_10122019_Final_Page_049.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456567271-993K7HVPYDKO05QF96GM/ML_Brand_Guidelines_10122019_Final_Page_050.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456571747-6RYPSHR3NH39UXQPG5SL/ML_Brand_Guidelines_10122019_Final_Page_051.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456568027-KF1UZ8DO1UZMOEN7Y257/ML_Brand_Guidelines_10122019_Final_Page_052.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456571603-C388B3YEPW9IMEX9W3Z8/ML_Brand_Guidelines_10122019_Final_Page_053.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456572358-FZKAJ9A3FDENRIJGS4VS/ML_Brand_Guidelines_10122019_Final_Page_054.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456581157-DFN9P4MXS99S8L276JWM/ML_Brand_Guidelines_10122019_Final_Page_055.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456574385-TPJ2OMYWXP0WD1E7WC5F/ML_Brand_Guidelines_10122019_Final_Page_056.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456576760-5F5502R3S5NISNI16UHO/ML_Brand_Guidelines_10122019_Final_Page_057.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456578507-JFIPE0ETFPSSE69J8I07/ML_Brand_Guidelines_10122019_Final_Page_058.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456580436-G3LTZAI1PXDY2CEPPH9Z/ML_Brand_Guidelines_10122019_Final_Page_059.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456581459-07EVAP0D0MQA6050LFVM/ML_Brand_Guidelines_10122019_Final_Page_060.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456582623-5O72JOK9ECGLNAQJ0M5I/ML_Brand_Guidelines_10122019_Final_Page_061.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456582322-DCHG19G6A4XHDVQBBYG6/ML_Brand_Guidelines_10122019_Final_Page_062.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456637258-F0E8CQNMU42PRTWSD330/ML_Brand_Guidelines_10122019_Final_Page_063.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456637550-UG04RRD4D6PF3EKCKQ3N/ML_Brand_Guidelines_10122019_Final_Page_064.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456637697-CUQI5A3EF41CK2IUWTBH/ML_Brand_Guidelines_10122019_Final_Page_065.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456638028-VLS3OTFML1U4G27RG85T/ML_Brand_Guidelines_10122019_Final_Page_066.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456638310-QM3TQW0MWH77B3OF0CFF/ML_Brand_Guidelines_10122019_Final_Page_067.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456638459-Z0Z0NU2FTJJWG8ZXF8ZW/ML_Brand_Guidelines_10122019_Final_Page_068.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456638848-HY0FZFWV0BQNXEBR0DT9/ML_Brand_Guidelines_10122019_Final_Page_069.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456638992-QF35NZ5T6Y97ZTRGR431/ML_Brand_Guidelines_10122019_Final_Page_070.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456639231-SQWQT1E8CCY31VHJW2N3/ML_Brand_Guidelines_10122019_Final_Page_071.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456639504-D73LQUXNJZDA6Y3ARUGZ/ML_Brand_Guidelines_10122019_Final_Page_072.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456640025-9U8M0XBX4BR6P1NI0X8T/ML_Brand_Guidelines_10122019_Final_Page_073.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456640823-3MUVFZVS8L22HFKNEF1G/ML_Brand_Guidelines_10122019_Final_Page_074.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456641084-VJ957CIGK9MPTSI7V088/ML_Brand_Guidelines_10122019_Final_Page_075.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456641487-SZEO5NG9O3VGLHZKZ5TL/ML_Brand_Guidelines_10122019_Final_Page_077.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456864965-0OWAO8CKSIQA49BP1154/ML_Brand_Guidelines_10122019_Final_Page_078.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456865325-STM1EOJTBFC0RJAVA2R3/ML_Brand_Guidelines_10122019_Final_Page_079.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456866464-FARETPQ63BG0RULS8RH4/ML_Brand_Guidelines_10122019_Final_Page_080.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456866699-LQ71FWIKH4ZC4UWPV21T/ML_Brand_Guidelines_10122019_Final_Page_081.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456867244-H3JKX7RQVV54HZ441MN2/ML_Brand_Guidelines_10122019_Final_Page_082.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456867715-SU5UW7L1S5W1ISJHEJID/ML_Brand_Guidelines_10122019_Final_Page_083.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456868276-5ZFVYOO1A327D3JVYDGH/ML_Brand_Guidelines_10122019_Final_Page_084.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456868753-Y5GO37MB2WDQY53M5XGZ/ML_Brand_Guidelines_10122019_Final_Page_085.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456869317-00S8IPXJB1WU2BZVUGL6/ML_Brand_Guidelines_10122019_Final_Page_086.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456870214-PSDC3T90Q4E8B3CXLWE2/ML_Brand_Guidelines_10122019_Final_Page_087.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456870442-6E3GAR83ZMQWJKY4LHSB/ML_Brand_Guidelines_10122019_Final_Page_088.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456870874-CXEK4B233UY7FKTRRVLH/ML_Brand_Guidelines_10122019_Final_Page_089.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456871059-U46JEMNL8KV19Q6ZNVRB/ML_Brand_Guidelines_10122019_Final_Page_090.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456872402-LSSO44JV7HDQG47H33M1/ML_Brand_Guidelines_10122019_Final_Page_091.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456873168-2MHFTWQG7M948NBOEW3O/ML_Brand_Guidelines_10122019_Final_Page_092.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456873075-YEYB459GDU4BL1HCDC9Q/ML_Brand_Guidelines_10122019_Final_Page_093.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456884833-SEM789X8DXSX442DSFMH/ML_Brand_Guidelines_10122019_Final_Page_094.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456874746-FFQSTT7267A8WVRIONXI/ML_Brand_Guidelines_10122019_Final_Page_095.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456875613-X2W5PYF2ZI8A906DDBAL/ML_Brand_Guidelines_10122019_Final_Page_096.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456925704-NSO79NR58LHFLTCLPTN3/ML_Brand_Guidelines_10122019_Final_Page_097.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456904282-XUJJOUO8JBF2743WQN9Z/ML_Brand_Guidelines_10122019_Final_Page_098.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456905029-GT0BTXGQV5BTRN3VA1ZA/ML_Brand_Guidelines_10122019_Final_Page_099.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456905786-LTO73DZWKPEEKGX3ZV0I/ML_Brand_Guidelines_10122019_Final_Page_100.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456907471-9VXVJ6NBDIV6W05D1LDR/ML_Brand_Guidelines_10122019_Final_Page_101.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456908542-C856N88DQK17TWQD6YM5/ML_Brand_Guidelines_10122019_Final_Page_102.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456947088-M571Z9BBIU8NNEJSG2NY/ML_Brand_Guidelines_10122019_Final_Page_103.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456927046-UB7YTNLXX7XYORM8IEZP/ML_Brand_Guidelines_10122019_Final_Page_104.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456928189-OEB2S3WK7W2L5KE4YARC/ML_Brand_Guidelines_10122019_Final_Page_105.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456930182-6XXI58AEOQ6FK1GD7MIK/ML_Brand_Guidelines_10122019_Final_Page_106.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456931219-46I7I3ARF7Y1PKAW337A/ML_Brand_Guidelines_10122019_Final_Page_107.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456932071-7CLG9K7NEUBEW29WSTSU/ML_Brand_Guidelines_10122019_Final_Page_108.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456932945-NZ9P4YZYN2CMNTTMYZNA/ML_Brand_Guidelines_10122019_Final_Page_109.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456933431-3VQK632IC5YVVIZQ6QL6/ML_Brand_Guidelines_10122019_Final_Page_110.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456934288-PRUFKE51NEP3KWJE9EV1/ML_Brand_Guidelines_10122019_Final_Page_111.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456934812-ODB9F9PMXW5GFV5AXTUH/ML_Brand_Guidelines_10122019_Final_Page_112.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456944185-6BD0XNT0MRQZZ11TEB09/ML_Brand_Guidelines_10122019_Final_Page_113.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456953104-3OCW48Z1IK4Z0XOTV58C/ML_Brand_Guidelines_10122019_Final_Page_114.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456953394-BP4LUTOEDDCUICH7G53Y/ML_Brand_Guidelines_10122019_Final_Page_115.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456957603-7VJH9NZ4CHSCVKEKFRVO/ML_Brand_Guidelines_10122019_Final_Page_116.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456954170-XMZI4ODQ9Z2YU2W4LEGC/ML_Brand_Guidelines_10122019_Final_Page_117.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456954652-04SEZGZKSPDFBBUP1O0A/ML_Brand_Guidelines_10122019_Final_Page_118.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456955217-YFHXXHBIQKADNXGX2CQ2/ML_Brand_Guidelines_10122019_Final_Page_119.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456955795-S53NABGUFZYHJSOVH3PC/ML_Brand_Guidelines_10122019_Final_Page_120.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456956844-G0C917Q13MBI9OVTLOZZ/ML_Brand_Guidelines_10122019_Final_Page_121.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456984435-GITVNO2FRVXSQJAFXQDB/ML_Brand_Guidelines_10122019_Final_Page_122.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456958293-A1FLHO4ABB1XY2EYU7H9/ML_Brand_Guidelines_10122019_Final_Page_123.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456980322-MVK90V5ZGKXFC71GT17T/ML_Brand_Guidelines_10122019_Final_Page_124.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456996179-ZP1XOKKPM2GS93HT7AQQ/ML_Brand_Guidelines_10122019_Final_Page_125.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456985584-R9MLOBUIX1JFPQ5G4BYK/ML_Brand_Guidelines_10122019_Final_Page_126.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456986341-QNDG2TRPXTUX0R1MGOAD/ML_Brand_Guidelines_10122019_Final_Page_127.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456987023-G987TT953S6K9BY6O4E5/ML_Brand_Guidelines_10122019_Final_Page_128.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456988594-SDSWRBYJLAZW6BPU8KTL/ML_Brand_Guidelines_10122019_Final_Page_129.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456989198-8H95G4OWEFDHHG7OMIFZ/ML_Brand_Guidelines_10122019_Final_Page_130.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456990531-KJSWFRN2P7D1JSN8BBFP/ML_Brand_Guidelines_10122019_Final_Page_131.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456991662-VWXUQSX184JABJUBIV58/ML_Brand_Guidelines_10122019_Final_Page_132.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456992909-TBYRR1QSVQ7U7LW697I0/ML_Brand_Guidelines_10122019_Final_Page_133.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456993585-YR2YVK7ATUT7055816NG/ML_Brand_Guidelines_10122019_Final_Page_134.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456994669-USE3PU3S5ED5UE1CKCD1/ML_Brand_Guidelines_10122019_Final_Page_135.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456996044-ZVP2NBXZAA6D6ZU3HFAJ/ML_Brand_Guidelines_10122019_Final_Page_136.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456997215-XLP7H3I87PTQ3C9VTGY2/ML_Brand_Guidelines_10122019_Final_Page_137.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456997384-85RLIHLCFZT5S1C4D1DX/ML_Brand_Guidelines_10122019_Final_Page_138.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456997845-YD4T68AD5TQUCNBIHDLK/ML_Brand_Guidelines_10122019_Final_Page_139.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456998581-KSD17UVVBRACGQCSAGZN/ML_Brand_Guidelines_10122019_Final_Page_140.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456998592-368YW70M79PAPWDZBV6X/ML_Brand_Guidelines_10122019_Final_Page_141.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457014679-HBGNVI4710XUI70BSAK2/ML_Brand_Guidelines_10122019_Final_Page_142.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589456999030-12EZ8XCEQC3ZH9OBUM9O/ML_Brand_Guidelines_10122019_Final_Page_143.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457014291-KC26OCRIQP2FS15MR0AR/ML_Brand_Guidelines_10122019_Final_Page_144.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457015066-QATEYOIPC2AGJ3QI9IXC/ML_Brand_Guidelines_10122019_Final_Page_145.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457015972-E35YPFYNTEAP9Y200Q22/ML_Brand_Guidelines_10122019_Final_Page_146.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457049870-4Z5I0ZJKZ9PRQ1G9WV86/ML_Brand_Guidelines_10122019_Final_Page_147.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457022161-TZ45NTDMZKCNV7857VHA/ML_Brand_Guidelines_10122019_Final_Page_148.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457084368-INUNXFGQOVEI1C5W8667/ML_Brand_Guidelines_10122019_Final_Page_149.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457109679-FFN2QIS747TREL9TID50/ML_Brand_Guidelines_10122019_Final_Page_150.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457108912-QYR6B6CTODZZ2GBOYFRH/ML_Brand_Guidelines_10122019_Final_Page_151.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457118693-OH3PCQOG3YWEAASLABHB/ML_Brand_Guidelines_10122019_Final_Page_152.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457178877-9XPWGI5JQ8T524IUSRUV/ML_Brand_Guidelines_10122019_Final_Page_153.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457142595-0R1DAJRMRITW9B8OIF5H/ML_Brand_Guidelines_10122019_Final_Page_154.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457152046-EKAUHG01KX5QFZW46MN6/ML_Brand_Guidelines_10122019_Final_Page_155.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457216302-QLLPMAOWE4OQD0H5OKWP/ML_Brand_Guidelines_10122019_Final_Page_156.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457192564-1VS0BMWO1YSUWZ97JUAO/ML_Brand_Guidelines_10122019_Final_Page_157.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457197347-BIGTQBYYNDMY6RHQEY2K/ML_Brand_Guidelines_10122019_Final_Page_158.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457198593-RYUVBS09CIEKA0LGZJID/ML_Brand_Guidelines_10122019_Final_Page_159.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457201164-HZ701BATSAFYGVO5DLQ5/ML_Brand_Guidelines_10122019_Final_Page_160.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457203265-35DLEQ26194JLKO2BWT5/ML_Brand_Guidelines_10122019_Final_Page_161.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457204464-2K69KWO8M699XNSD8872/ML_Brand_Guidelines_10122019_Final_Page_162.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457205120-RUBAQ9WXAEGOV3MMUX3L/ML_Brand_Guidelines_10122019_Final_Page_163.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457205801-UYQKYBC00WNNTOEXVAY6/ML_Brand_Guidelines_10122019_Final_Page_164.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457207010-WAQ7IOB29KBXOKN0XV7I/ML_Brand_Guidelines_10122019_Final_Page_165.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457207721-C8RERK4D1R8XHO0Z8ZQU/ML_Brand_Guidelines_10122019_Final_Page_166.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457208753-8D4Q9BIFHKXAY1J101FL/ML_Brand_Guidelines_10122019_Final_Page_167.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457209449-M2JFTPCK9YPEZQSQ1NTH/ML_Brand_Guidelines_10122019_Final_Page_168.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457211087-DXCTCBR0G9WDPSVYEI6L/ML_Brand_Guidelines_10122019_Final_Page_169.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457212132-DNPBNSDCDHWWF52Y6N7X/ML_Brand_Guidelines_10122019_Final_Page_170.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457212797-UJFY5TXS5H57YJ0F3C38/ML_Brand_Guidelines_10122019_Final_Page_171.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457213458-2ZCFOKBL6WHJ9617J0PK/ML_Brand_Guidelines_10122019_Final_Page_172.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457214238-IK6CMFGJHDPFD6OQUOP9/ML_Brand_Guidelines_10122019_Final_Page_173.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457216204-XDGSY5SB8ZSMVJSUTGL4/ML_Brand_Guidelines_10122019_Final_Page_175.png)
![Magic Leap Brand Guidelines](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457215581-79QBRT489J5K8NLYHPGE/ML_Brand_Guidelines_10122019_Final_Page_174.png)"
87,Magic Leap Campaign Images,magic-leap-campaigns,/archive/magic-leap-campaigns,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.950661+00:00,0,,"Graphic Design

![Magic Leap Campaign Images](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458886194-189L2QJWTQBHDHVUDK3Q/CONSUMER_LM_Astronaut_Assets_rb_v009.jpg)
![Magic Leap Campaign Images](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458886983-4CVFO3NG5WVOIL5TEJF4/CONSUMER_lm_UNDERSEA_v005.jpg)
![Magic Leap Campaign Images](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458888749-WX3AP87A2YWTEUB2G4VO/ENTERPRISE_LM_3D_Design_Hero_dl_v022.jpg)
![Magic Leap Campaign Images](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589888961878-YSLDOFFLA15AFUQJI59Q/ML1_Developer.png)
![Magic Leap Campaign Images](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589889304652-WRJCUDC8UBQ66Q3JYCYX/ML1_Enterprise.jpg)
![Magic Leap Campaign Images](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589889053885-ZHV7RYMSC64H6WH2JHAI/ENTERPRISE_LM_Learn_Assist_rb_v014.jpg)"
88,Magic Leap Experience Space,magic-leap-experience-space,/archive/magic-leap-experience-space,archive,,Archive,0,"Interiors — Brand Creative Director, Magic Leap

  Environmental design for the Magic Leap Experience Space, a physical environment designed to introduce visito",,2026-04-26 22:44:54.882687+00:00,0,,"Interiors — Brand Creative Director, Magic Leap

Environmental design for the Magic Leap Experience Space, a physical environment designed to introduce visitors to spatial computing. The space bridged physical architecture with augmented reality demonstrations, creating a controlled environment for experiencing Magic Leap technology.

![Magic Leap Experience Space](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589455824813-H0WX0HQH51CDS1RJ1A1R/BrandRoom.jpg)
![Magic Leap Experience Space](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589455810231-5WKGA8BDL9NBPGP92M93/roomrender_onbrand01.png)
![Magic Leap Experience Space](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458041820-VLW4IACSHON0SKV1G3NY/FOV-wireframe2.jpg)"
89,Magic Leap UX/UI,magic-leap-homepage,/archive/magic-leap-homepage,archive,,Archive,0,Digital,,2026-04-26 22:44:54.817539+00:00,0,,"Digital

![Magic Leap UX/UI](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458087719-Z57KIMZV3X5V9FEI5D3D/ML_Website_Desktop_01.png)
![Magic Leap UX/UI](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458120163-SJJU7U2EYMH8UO9SSWZ3/ML_Website_Desktop_02.png)
![Magic Leap UX/UI](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458104673-3AXBJSV9MMWSVFUE1XSS/ML_Website_Mobile_01.png)
![Magic Leap UX/UI](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589458134136-YLCON0NKIQL3JA9QZOUU/ML_Website_Mobile_02.png)"
90,Magic Leap Visual Design,magic-leap-visual-design,/archive/magic-leap-visual-design,archive,,Archive,0,"Graphic Design — Brand Creative Director, Magic Leap

  Visual design system and brand guidelines for Magic Leap's spatial computing platform. Defined the visua",,2026-04-26 22:44:54.754363+00:00,0,,"Graphic Design — Brand Creative Director, Magic Leap

Visual design system and brand guidelines for Magic Leap's spatial computing platform. Defined the visual language across product UI, marketing materials, and brand touchpoints for the augmented reality headset and ecosystem.

![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457541806-NX10A79VZI1C7PXXDM0N/Screen+Shot+2019-12-10+at+3.24.08+AM.png)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457332709-EXZYT2DYNZHPX4T7934N/2.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457320136-MQTW7TET3XMQWFXPBMF2/6.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457324207-B5H39ICJ3HVD2EBAH6ZK/7.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457401571-H63OU8YY203UFQGAOY31/23.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457414689-80T0K5ZRPFEGE5PYRQS2/101.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457463530-7C5HXK7FFYANMXF52N5P/card.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457417323-UCK0AVKPCQFXS2RFAQJQ/Devices_Composition_Content_03.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457449089-U977BNJSB0XRKUEG3UFJ/Display_Stand_Mockup_1.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457463278-JD5H7T20GKUK29063KM9/Free_Letter_Catalog_Mockup_01.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457604829-EVC76DBE2SR54B1J7DIW/ML_Packaging_01.png)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457507075-K50Q4J0ASCJRU6GXA558/ML_Packaging_02.png)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457550879-3OM0NIKL4NLN4BCLDAQ2/Wall_sign.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457586048-SU6KVNNRILGBP386UNBY/ML_Event_Booth_Exterior_Red.png)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457593387-AVXR97DD5QW9NIOT1IG7/ML_Event_Booth_Exterior.png)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457315617-F4NHWHC0AVJ4XE72VBDD/5.jpg)
![Magic Leap Visual Design](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1589457478509-8FVCKFFUCFH22RCDML7L/Lanyard_ID_badge_mockup_2.jpg)"
91,Magic Leap 'Magic Shadows',magic-leap,/archive/magic-leap,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.685320+00:00,0,,"Graphic Design

![Magic Leap 'Magic Shadows'](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1587626876474-8U7SOOPVXPY4CGE73DD5/Screen+Shot+2020-04-23+at+9.27.18+AM.png)
![Magic Leap 'Magic Shadows'](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1587626898866-2NZUTLBOWBTAC8ZWP0SU/Screen+Shot+2020-04-23+at+9.27.41+AM.png)
![Magic Leap 'Magic Shadows'](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1587626921199-42X4Q1ZWG9N2A1SHUNXA/Screen+Shot+2020-04-23+at+9.28.03+AM.png)
![Magic Leap 'Magic Shadows'](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1587626945984-65KNG8BFHWQ9GJ34HA9A/Screen+Shot+2020-04-23+at+9.28.03+AM.png)
![Magic Leap 'Magic Shadows'](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1587626966304-1QT4S0D8Q1911TLMSQCZ/Screen+Shot+2020-04-23+at+9.28.37+AM.png)"
92,Mller Skateboards,mller,/archive/mller,archive,,Archive,0,Experiments,,2026-04-26 22:44:54.618248+00:00,0,,Experiments
93,Nature of Motion / Milan,nature-of-motion-milan,/archive/nature-of-motion-milan,archive,,Archive,0,"Interiors — Creative Director / Senior Art Director, Nike Global Brand Design

  Environmental and exhibition design for Nike's ""Nature of Motion"" installation",,2026-04-26 22:44:54.562293+00:00,0,,"Interiors — Creative Director / Senior Art Director, Nike Global Brand Design

Environmental and exhibition design for Nike's ""Nature of Motion"" installation at Milan Design Week. The immersive experience explored human movement and the science behind Nike innovation, translating product technology into an architectural narrative.

![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340721953-9ZCNM1XJIF5CH1ZQ3TBC/02-THE_NATURE_OF_MOTION_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340734428-KVP02WTJ2F9ZSZJVZCAT/03-ENTRANCE_2_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340735588-H4WZ95NGY2S9UWTV6TGA/03B-ENTRANCE_DISLPAY_1_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340747125-54RNWHA7RMJB8NX91DKF/04-BERTJAN_POT_HIGH_VIEW_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340755595-6R4OJWYELHWEABS2Z34D/06-BERTJAN_POT_DETAIL_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340756843-HD7Z9K46ZI4RHLVFNLQS/07-CLARASHANE_HIGH_VIEW_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340764697-WGHN0GW7O6E1DQ2AHSIK/08-MARTINO_GAMPER_7676_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340766023-YDHXMHKIWMEASUJ1DLI6/12-MAX_LAMB_7615_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340775167-TZGX02F65GX0NH8DX93C/18-ZAVEN_7637_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340777396-4PGEP1WJMJ158BMDCE2D/20-SEBASTIAN_WRONG_7722_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340790909-KT36DWNRM75B9XV6O1BS/23-GENEALOGY_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340789416-Z1BIY6U0R6C64BKVN3OB/25-FREE_RN_MOTION_7788_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340801503-AHZTGHRO63WH4L3UYIAR/26-FREE_RN_MOTION_DETAIL_7992_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340800846-VKVY8RY8HJ7MP188JM5S/27-EXPERIMENTS_3D_7762_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340807831-WH6BXF5LSUGUB61IJL7I/28-EXPERIMENTS_3D_DETAIL_8006_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340818790-13XUJ9LHCZBZN2W1XW5H/31-EXPERIMENTS_SHOES_7820_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340823526-AC4G7VDN3EYH6R86F8UA/33-COURTYARD_8197_original.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340829047-BK3XV0ICZ3GF4Y5I6T2Y/NIKE-NOM-april12-8522.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340829581-DI5A44HYD5D4H7J6FVQH/static1.squarespace.png)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340838541-YB6ABNP68BNPZ9FLE02K/STO_0683.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340838661-75J6I3E713DUAHEAOUNI/STO_1862.jpg)
![Nature of Motion / Milan](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525340845642-18SQ5OB6LCM5PQA22RMK/STO_1922.jpg)"
94,Crypto Rockets for SuperRare Auction,new-page-1,/archive/new-page-1,archive,,Archive,0,Experiments,,2026-04-26 22:44:54.488275+00:00,0,,Experiments
95,Nike Air Max 87-17,new-project-1,/archive/new-project-1,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.430658+00:00,0,,"Graphic Design

![Nike Air Max 87-17](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917043609-D0N8MB3S4M5WP8YA5G2Z/tumblr_oy5c2m2oeC1qzta7uo1_1280.jpg)
![Nike Air Max 87-17](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917006902-1CX35L6K90TE9JQ6PJUQ/tumblr_owr92xOOg21qzta7uo1_1280.jpg)
![Nike Air Max 87-17](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917014419-0RVNLCT7YUNRH0M9OEQM/tumblr_ovhcn9aW0k1qzta7uo1_1280.jpg)
![Nike Air Max 87-17](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917024713-TA2303BAVPIGTY0C2TO8/tumblr_ovicyiLJaJ1qzta7uo1_1280.jpg)
![Nike Air Max 87-17](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917027560-KUTN2Y0IKXLTPTIYJ48M/tumblr_owr90rC7ad1qzta7uo1_1280.jpg)
![Nike Air Max 87-17](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917039787-8CDQ1TOEYRXTTGCT2U2K/tumblr_owr9883SYm1qzta7uo1_1280.jpg)"
96,Lebron X Packaging,new-project-2,/archive/new-project-2,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.372882+00:00,0,,"Graphic Design

![Lebron X Packaging](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917223331-SKC0QQCP594WVDXTPYHI/tumblr_ooa32n7wkD1qzta7uo1_1280.jpg)
![Lebron X Packaging](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917223210-EV6JS6SXNB3DKO11IS9C/tumblr_ox1voteKhe1qzta7uo1_1280.jpg)
![Lebron X Packaging](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917224435-2W0VVUSTZNIR4LG8V1P9/tumblr_oyto2cymi41qzta7uo1_1280.jpg)"
97,Jordan Brand / 23 Engineered,new-project-3,/archive/new-project-3,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.315996+00:00,0,,"Graphic Design

![Jordan Brand / 23 Engineered](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917662108-7PLAESEDAZPI0BQ1V7WN/tumblr_ozwlpjjgjk1qzta7uo1_1280.jpg)
![Jordan Brand / 23 Engineered](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917651833-JUPG3AOVGLFPNT4H5C2L/tumblr_ox5qx85VMg1qzta7uo1_1280.jpg)
![Jordan Brand / 23 Engineered](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917651604-SKE37E5J4BZBDM7KLO6A/tumblr_ox5rooUPWZ1qzta7uo1_1280.jpg)
![Jordan Brand / 23 Engineered](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917653135-HOKEWDHL2OFESRL3WAST/tumblr_ox61f5ISbq1qzta7uo2_r1_1280.jpg)
![Jordan Brand / 23 Engineered](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917653260-JY6YK9TQA7W71DG279AX/tumblr_oy1eug8YeF1qzta7uo1_r1_1280.jpg)
![Jordan Brand / 23 Engineered](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917654937-UF8WRE6P53Y9YRB29B4C/tumblr_oy1f7dk9X61qzta7uo1_r1_1280.jpg)
![Jordan Brand / 23 Engineered](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524917654933-42WAB9BMMY11P5PW9LL3/tumblr_ozwkjc3efw1qzta7uo1_1280.jpg)"
98,NSW / Tech Pack HO14,new-project-38,/archive/new-project-38,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.256104+00:00,0,,"Graphic Design

![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938643970-YRZYNHQCKYD4R5UMPDPR/tk_lebron_original_original.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938618830-WJBLGXE13SZJQFWJ8PH7/FA15_NSW_Tech_Pack_Tech_Fleece_Cape_01_EXT_origina_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938622348-JOAWEYQFMH5YXQJNRQSJ/FA15_NSW_Tech_Pack_Tech_Fleece_Hoodie_01_EXT_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938612502-W2YTEUGMHZ85AZG72E0K/FA15_NSW_Tech_Pack_SDiggins_01_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938608791-C614IFER0K4QL61D7VJX/FA15_NSW_Tech_Pack_Neymar_02_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938601094-4WNKDCL0I5N19H8ABHQU/FA15_NSW_Tech_Pack_AHirano_02_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938605846-1NJO86YQ1DMSGRTU2HND/FA15_NSW_Tech_Pack_MSharapova_01_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938614459-Q84MD1FO6ZE5MFVWYLH9/FA15_NSW_Tech_Pack_SDiggins_02_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938625463-2GDNPCHP7Z2JAQHE9RD5/FA15_NSW_Tech_Pack_TThomas_01_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938628621-ESYOG8TCG390Z61VHI8T/FA15_NSW_Tech_Pack_TWood_02_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938632881-DNJYH1XQCYVGNBQ5GIXZ/FA15_NSW_Tech_Pack_WHaiyan_01_original_porto_native_1600.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938633629-IEO25VNA4TBMZPW1PTFE/knit_pant_1_original_original.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938636840-7I3A1GMGJVD154O8PUA7/knit_t_1_original_original.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938650107-BZQW7NGG6XJ0W7D3X0PJ/tk_morgan_original_original.jpg)
![NSW / Tech Pack HO14](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524938651111-KJE0WF7ASFB8MPLTKCDN/wind_runner_1_original_original.jpg)"
99,Jordan Brand / Women,new-project-4,/archive/new-project-4,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.186675+00:00,0,,"Graphic Design

![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524918754699-CTJPAC3AZN2PF2A43HFU/tumblr_p58t4pWUvX1qzta7uo1_1280.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524918764457-FWRYAMJDLXZM7FJBLMR0/tumblr_p58swuGIsk1qzta7uo1_1280.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524918767004-MDHAGIEQSDQ5JOM56EUR/tumblr_p58t11eWyy1qzta7uo1_1280.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524918768569-22NCO41PFAY4FN4QBWIG/tumblr_p58t21RH8A1qzta7uo1_1280.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524918761410-GBP5OSX5F62AECVV5RZ6/tumblr_p58sw7mjU81qzta7uo1_1280.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525274708565-G3JQY4JNFEPEHJTPSP45/HO17_JD_JSW_WOMENS_SOH_AJI_BARELY_GRAPE_PRIMARY_native_1600.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525274717216-2V2NQ2AQKFC2Z6LAPUV4/HO17_JD_JSW_WOMENS_SOH_AJI_MINT_FOAM_PRIMARY_native_1600.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525274722620-0UYO33BXJZT0FFRJ8USV/HO17_JD_JSW_WOMENS_SOH_AJI_SUN_BLUSH_DETAIL_1_native_1600.jpg)
![Jordan Brand / Women](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1525274742868-SSUOO5Y24H9WMK093CF0/SP18_JD_JSW_WOMENS_MODEL_AJI_HiZip_SECONDARY_006_native_1600.jpg)"
100,Nike Running / Paula Radcliffe,new-project-48,/archive/new-project-48,archive,,Archive,0,Graphic Design,,2026-04-26 22:44:54.121283+00:00,0,,"Graphic Design

![Nike Running / Paula Radcliffe](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524935172919-5YAF0AAXH3UBW3W9K311/PaulaRadcliffe_2_original.jpg)
![Nike Running / Paula Radcliffe](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524935170675-VEHOCF9U5CWA6KRK3N4T/PaulaRadcliffe_1_original.jpg)
![Nike Running / Paula Radcliffe](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524935198810-5489OSCLG4JVAF5DEZOR/PaulaRadcliffe_3_original.jpg)
![Nike Running / Paula Radcliffe](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524935199175-RJNWRQDPLZUOHDA02MBE/PaulaRadcliffe_4_original.jpg)
![Nike Running / Paula Radcliffe](https://images.squarespace-cdn.com/content/v1/512b8effe4b0dc8d3de0eb54/1524935215022-9EM1N24FK0N7ZZO5S11W/PaulaRadcliffe_5_original.jpg)"