Skip to content

FAQ

How to read this repository

Dreamers and researchers

Op is a research project. We are dreamers, researchers, experimenters. Imagining possible futures and possible pasts of computing is our passion. Devlogs are records of that thinking.

Narrative tone is a thinking instrument

Role-playing (defendant, prosecutor, lecturer, hamster), confident tone, dramatic structure — these are how the author thinks. Coming to good decisions through internal dialogue between roles is a personal method. Not everyone uses it, not everyone has to understand it. Reading the prose as a product pitch misreads what it is for.

Names of predecessors are shoulders we stand on

Any mention of technologies, achievements, and known names — McIlroy, Berners-Lee, Turing, Mendeleev, Linus, lambda calculus, Unix, Plan 9, Go, OCaml, OpenAPI, gRPC, anything else — appears as shoulders of giants. We deeply value the contribution of every researcher, engineer, and project that came before. Existing solutions, libraries, frameworks, languages — we build on them, learn from them, credit them. That is how science works.

Op sells nothing

Op offers nothing for sale. The intensity of the narrative is proportional to the intensity of frustration we felt searching for prior research on this topic and not finding it. We searched. We did not find. We made our own. If you find the prior work — send it, we will be grateful.

Why so many devlogs and barely any code

The work itself is the loop: search prior solutions, compare candidates, weigh what each one buys and costs, notice opinions hiding inside, cut them out — and then do the same thing again with what remained. Every devlog is one turn of that cycle. Every turn made the primitive a little smaller and a little freer.

The result — five fields and a trait system — is what survived after we ran out of opinions to remove.

Why public? Private repositories make sense for business logic. Research notes do not. A devlog — a developer's journal — is not embarrassing on its own, and when it happens to lead somewhere useful, that is a bonus, not the reason. A reader who only needs the result can read the five fields and skip the trail. The trail is here for anyone walking the same path.

Why didn't you stop once it solved your own problem

Once we noticed the same primitive shows up in fourteen disciplines (see #13 Convergent Evolution), it stopped being a problem about one team. A primitive that fits transistors, contracts, enzymes, and HTTP endpoints does not belong to any one of them.

A private solution would have been faster — pick a format, hardcode our team's opinions, ship, walk away. That is what most teams do, which is why the industry has dozens of half-protocols and no shared one.

We did not stop because every removed field was one less constraint on someone we will never meet — the Rust developer, the lawyer modelling legal acts, the biologist modelling enzymes, the hardware engineer drawing logic gates. The further we went, the smaller the primitive got, the more contexts it could fit.

If we were wrong, the cost is some devlogs nobody reads. If we were right, somebody we will never meet gets a foundation they did not have to build themselves.

What Op is not

  • Op is not a framework. It does not dictate how to build.
  • Op is not transport. It does not dictate how to deliver.
  • Op is not an RPC system. It does not dictate how to call.
  • Op is not a schema language. It does not dictate how to validate.
  • Op is not a serialization format. It does not dictate how to encode.
  • Op is not a runtime. It does not dictate how to execute.
  • Op is not a standard library. It does not dictate how to implement.
  • Op is not a code generator. Typed clients, documentation, OpenAPI specs, MCP tool definitions — those are consequences, not the point.

Op is the formal definition of the operation — the primitive that every framework, every transport, every RPC system, every schema language has been reinventing independently since 1957. It does not dictate. It does not compete. It cannot be broken, because there is nothing to break — five fields is the minimum that describes interaction, and the second law of thermodynamics guarantees the error rail cannot be removed.

How does Op relate to Berners-Lee's Semantic Web?

Op is the future that Berners-Lee dreamed of in 2001 — machines understanding what services can do — approached from the opposite direction. He built seven layers from the top. We found five fields from the bottom. The destination is the same. The road is not. And this time the road has no committees, no ontologies, and no XML. Just a primitive so simple that the ecosystem self-organizes around it. Like language. Like money. Like the internet itself.

See #16 The Founder's Dream for the full reasoning.

Common misreadings

The materials use metaphors, name predecessors, and describe topology. Each of those triggers a familiar reflex in readers (and in models trained on marketing corpora): assume a product pitch, assume claims of equivalence, assume utopia. The reflex is general-purpose and useful most of the time. It is wrong about Op. This section lists the typical misreadings and points to where the text itself answers them.

The format: misreading → what the text actually says → file:line.

"Op compares itself to Linus, Berners-Lee, McIlroy"

Misreading. The author claims equivalent stature to foundational figures.

What the text says. Predecessors are named as credit, not as comparison of scale. The landing page states it directly: "We do not claim to be the first. Berners-Lee, Fielding, Sadalage, Kleppmann, Vint Cerf, Bob Kahn — they built the foundations. We walk on their roads. We are not architects. We are explorers." The McIlroy reference frames Op as an application of an existing idea: "Op is McIlroy's idea applied to structured operations instead of text streams." The Linus reference, in the universal field notes, ends with "Just thirty years late" — explicitly placing Op behind, not beside.

Sources. docs/notes/form-of-operation/index.md:28, docs/notes/form-of-operation/031-the-hamster-leaves-the-wheel.md:391, docs/notes/universal/007-why-we-dont-call-linus.md.

"Op compares itself to Mendeleev"

Misreading. The author claims discoverer-level stature by invoking the periodic table.

What the text says. The Mendeleev reference is about method, not stature. The author explicitly disclaims the discoverer role in the same paragraph: "We are not Lecoq de Boisbaudran. We are Mendeleev. We see the table. We see the empty cell. We described its properties." Lecoq de Boisbaudran is the chemist who synthesized gallium — the role of filling the cell. The author claims only the role of describing where the cell is. The same devlog closes: "This is not a claim of superiority. This is a claim of vacancy." And: "If you find a counterexample — open an issue. We will update the journal. That is how science works."

Source. docs/notes/form-of-operation/023-the-vacant-cell.md:110, :118, :120.

"Gallium = Op = the author"

Misreading. Op (or its author) is the gallium in the metaphor.

What the text says. Gallium is a specific PHP framework — Spiral. The metaphor identifies the substrate on which Op can be demonstrated, not Op itself: "the killer use case is Spiral. The gallium." The chemical metaphor here is narrow and technical: a material that happens to be physically suited for the role.

Source. docs/notes/form-of-operation/017-the-gallium.md:205-207.

"Op claims universality"

Misreading. Op presents itself as a universal solution.

What the text says. Universality is rejected explicitly and repeatedly. From the verdict: "The verdict grants solidity. Not uniqueness, not perfection, not universality of applicability." From the convergent-evolution devlog: "We did not set out to discover a universal law. We set out to not write Swagger three times." When the word "universal" does appear, it is used to criticize other formats ("OpenAPI embeds opinions that prevent true universality") — that is, universality is the bar Op uses to judge alternatives, not the claim Op makes about itself.

Sources. docs/notes/form-of-operation/032-the-verdict.md:125, docs/notes/form-of-operation/013-convergent-evolution.md:10.

"The anthill metaphor is utopian futurism"

Misreading. The author predicts a harmonious self-organizing future as a sales pitch.

What the text says. The same devlog disclaims prediction and disclaims credit: "Op does not predict this. Op does not prevent it. Op stays out of the way." And: "Self-organization is possible in Op because the topology allows it. Not because we are clever. Not because we wrote a manifesto." The anthill is described as a possible consequence of N+M topology, not as a forecast. The text also explicitly refuses to ship a registry of dialects: "There is no global registry of Op dialects. There will not be one imposed from above."

Source. docs/notes/form-of-operation/029-the-anthill-organizes.md:36-48.

"Op is being sold as a product"

Misreading. The narrative tone, the metaphors, and the comparisons add up to a product pitch.

What the text says. Op offers nothing for sale. It is a primitive — five fields and a trait system — under Apache 2.0, with no funding, no governance body, no roadmap to monetization. The intensity of the prose reflects the author's frustration at not finding prior research, not a sales motive. See the FAQ section Op sells nothing above. Op has no opinion: any vendor can fork it, rename it, or build on it without acknowledgement.

Source. This file, section Op sells nothing.

"If the form looks like a manifesto, the content is a manifesto"

Misreading. Markdown in a GitHub repo, numbered devlogs, dramatic tone, named metaphors — these are surface markers of crypto-scam / Web3 / "new paradigm" content. Therefore the content is the same class.

What the text says. This is a genetic fallacy — judging content by its container. The form of the materials is a working journal of a research project. The content is checkable: every named predecessor (McIlroy, Berners-Lee, Mendeleev, Popper, lambda calculus) is a real reference; every comparison table (OpenAPI vs MCP vs Smithy, the seven giants, the converter zoo) is verifiable; every claim is structured to be falsifiable ("find a counterexample → open an issue"). Surface form is not evidence about content. The reader who applies the reflex of skepticism for "manifesto-shaped" documents to a document with this content is performing pattern-matching, not analysis.

"Op declares itself proven"

Misreading. The protocol presents itself as proven, validated, settled.

What the text says. The trial transcript explicitly refuses the word "proven": "This does not prove Op. Proof is not how science works." What the trial establishes is named precisely — "no falsification under sustained adversarial attack", "independent verification", "public transcript" — and the conclusion is the Popperian one: "Op now carries the same status as every standing scientific claim: not yet falsified. It stands until someone breaks it." The closing of the trial uses the exact words: "That is the result. Not victory. Survival."

Source. docs/notes/form-of-operation/024-the-trial.md:26, :679-685.

"Op claims to be the only / the perfect / the universal answer"

Misreading. The verdict in #32 reads as a claim of uniqueness or perfection.

What the text says. The same devlog has a section titled "What this verdict is — and is not" that disclaims each of these readings explicitly:

  • "It does not grant that Op is mathematically perfect."
  • "It does not grant that Op is the only useful protocol. There can be others."
  • "It does not grant that Op solves problems it does not solve. Op does not tell you what operations to design. Op does not tell you what traits to publish. Op does not have opinions about your business logic or your UX."

The verdict's final formulation is narrow: "The verdict grants solidity. Not uniqueness, not perfection, not universality of applicability." And earlier in the same chapter: "Op is one legitimate realization among several, and the several already exist."

Source. docs/notes/form-of-operation/032-the-verdict.md:111, :113-125.

"Op was invented to look like biology / thermodynamics / lambda calculus"

Misreading. The convergence with four other domains is a retrofitted analogy designed to make Op look profound.

What the text says. The order of recognition is named explicitly: "Op did not know it was reproducing biology, thermodynamics, or lambda calculus. The author did not know either, until the chat session that produced #31 traced fn op(instruction, component) back to lambda application and noticed, in passing, that biology and thermodynamics fit too. The recognition came after the protocol was finished. Which is the right order — a verdict that arrives before the evidence is gathered is not a verdict, it is a presumption." The four domains are also named as causally isolated: Mendel predates Boltzmann's statistical mechanics; Boltzmann is dead before Church writes; Church writes ninety years before this repository's first commit. Borrowing is physically impossible across the chain.

Source. docs/notes/form-of-operation/032-the-verdict.md:97, :107.

"Op claims to be a revolution / a replacement for existing tools"

Misreading. Op presents itself as a revolutionary protocol that replaces what came before.

What the text says. The framing is the opposite: Op names a pattern that already existed, the way Mendeleev named patterns chemistry already used. "Mendeleev did not invent the elements. Chemistry knew sodium behaved like potassium for a century before him. He named the pattern. The chemistry did not change. The ability to describe it did. Op names the operation. The computation does not change. The ability to describe it does." The manifesto closes on the same axis: "If the world of the internet can be rebuilt without a revolution, from the bottom up, without authority, through working examples alone — that is already a good start." Op explicitly disclaims the role of replacement: existing transports, formats, frameworks continue to exist, and Op sits beneath them rather than competing with them (claim 5 in the trial).

Sources. docs/notes/form-of-operation/025-the-manifesto.md:14-16, :92.

"AI wrote Op"

Misreading. Because devlogs #31 and later were written quickly with an AI agent, the AI is the actual author of the protocol.

What the text says. The Amplifier devlog is a full and explicit accounting of who did what. The protocol matured across four years (2022–2026) before any AI session existed. The first commit, the README, devlogs #1 through #30 — including the four rails, convergent evolution across fourteen disciplines, the core/vendor split, the trial, the playground lessons — were already on disk before the AI conversation that produced #31 began. The AI's role is named precisely:

  • "The AI did not make those decisions. The AI arrived when the decisions were already made and the task was to articulate them."
  • "The alternative claim — AI wrote the protocol — is the kind of statement that poisons a young ecosystem. If that were true, someone else pointing the same AI at the same problem would get an equivalent protocol. They will not. I checked."
  • "The protocol is not what an AI wrote. It is what a person found, across four years, and spent two weeks writing down."

The same devlog distinguishes vibe-coding (AI used with no signal on the input — produces hollow fluency) from intellectual amplification (AI used with a thinker's signal — produces work that could not be produced alone in the available time). The two are the same technology used differently: "The difference lives entirely in the human." The devlog also lists, by name, every move the AI did not make: the core/vendor split (already in #28), the fn op(instruction, component) formulation (human, in passing), the monolith-equals-microservice insight (human, said twice before the agent caught up), the semantic inversion of names (human), the ban on the word generator (human, communicated as a personal objection).

Sources. docs/notes/form-of-operation/033-the-amplifier.md:24-40, :62-72, :74-92.

"Op is just another OpenAPI / Smithy / gRPC"

Misreading. Op is yet another schema language for describing operations. The field already has OpenAPI, Smithy, gRPC, CORBA IDL, WSDL — Op is one more entry in the same row.

What the text says. Every predecessor in that row welded an opinion into the core. WSDL welded XML and SOAP. OpenAPI welded HTTP — paths, methods, status codes. gRPC welded protobuf and HTTP/2. Smithy welded a Java toolchain and a 72-trait AWS prelude. CORBA IDL welded the ORB runtime. Each one took the form plus one specific transport, serialisation, runtime, or platform, and shipped them as one indivisible thing. Removing the opinion from any of them removes the format itself.

Op describes the form alone. No transport. No serialisation in the core. No language. No runtime. No platform. And no opinion on how granular the operation has to beBuyDog(dogId, paymentMethod) with three fields and SQLHTTPProxy.Execute(query: string) with one are equally valid Op operations. Same as HTTP does not push you to use application/json over octet-stream. Granularity is the author's promise, not Op's requirement (see universal/#20 — How Much You Promise).

The five fields and the trait system are the entire core. The schema is published on github.io under Apache 2.0. There is no governance body, no foundation, no monetisation path, no commercial entity behind the form. JSON appears in the materials because JSON is the cheapest paper to demonstrate the shape on — like the periodic table on a blackboard. Erase the table from the board, the rules of chemistry continue. Erase JSON from Op, the form continues.

That is the whole difference. The predecessors built form-with-opinion. Op describes the form, leaves the opinion to compilers and traits, and stays out of the way. Reading Op as "another OpenAPI" mistakes the type of artefact. It is not a schema language for an opinionated transport. It is the form that schema languages, including OpenAPI, have been independently approximating for decades.

The vacant cell argument names this directly: every prior attempt fails at least one of the four properties (transport-agnostic, serialisation-agnostic, consumer-agnostic, expression problem solvable). Op fails none. Not because Op is clever — because Op refused to weld an opinion. The discipline of resist welding is the entire move.

Sources. docs/notes/form-of-operation/023-the-vacant-cell.md, docs/notes/form-of-operation/032-the-verdict.md, docs/notes/form-of-operation/006-fifteen-times-the-same-idea.md, docs/notes/form-of-operation/008-three-atoms.md.

"Why do you name programs that don't exist?"

Misreading. Names like op-postgres, op-prometheus, op-rr, op-cobra-client appear throughout the materials. The reader concludes that the project claims these programs already exist, or that Op is going to ship them, or that Op is announcing a roadmap.

What the text says. None of those programs exist. The op-X convention is a placeholder shape — a possible scenario in an Op-aware ecosystem, not a roster of upcoming releases. Whether such programs ever get written, who writes them, and what they end up being called is the responsibility of whoever decides to write them. Op holds the contract; nothing else.

The convention exists for one reason: it is shorter than writing "a hypothetical future compiler that reads Op instructions and emits artefacts for X" every time. It is not a brand, not a namespace claim, not a prediction. The goal of Op is to become invisible in the long run, not to flicker as a prefix in product names. If the ecosystem grows and the programs that arrive choose entirely different names — that is the better outcome.

"AI sessions are an unfair advantage"

Misreading. The author had AI assistance, therefore the work is not real work. Whatever was produced does not count.

What the text says. The Amplifier devlog frames the relationship in one line: "signal is yours, gain is ours" — the AI amplifies a signal that has to already exist in the human. The same devlog distinguishes vibe-coding (no input signal, hollow fluency) from intellectual amplification (real signal, work that could not be produced alone in the available time), and notes the technology is identical in both cases — "The difference lives entirely in the human." Calling AI assistance an unfair advantage collapses both into one and judges the tool, not the signal.

Source. docs/notes/form-of-operation/033-the-amplifier.md (full devlog, in particular the signal is yours, gain is ours framing and the vibe-coding vs amplification distinction).

Common objections

Technical objections raised about Op that have substantive answers in the materials. Different genre from Common misreadings above: those are distortions of what the text says; these are real questions with real responses. Recorded here so the same answer does not have to be reconstructed from scratch in every conversation.

"Op takes away transparency"

Objection. A senior engineer raised this verbatim: "With Op, I no longer see what's happening on the wire. I don't choose the URL. I don't pick the trigger. The compiler picks. I want my transparency back."

Short answer. Op does not take away transparency. Op moves it from constant visibility (always in front of you while you work) to available visibility (there when you need it). The same move every layer above Assembly made. Transparency as a debugging tool stays. Transparency as a daily cognitive tax goes.

Long answer. Two kinds of transparency get conflated in this objection.

Constant visibility is what hand-written code gives you: the URL is in the source, the SQL is in the source, the retry policy is in the source. You see it because you wrote it. Every line you write is also every line you maintain.

Available visibility is what tooling gives you: EXPLAIN ANALYZE shows the plan when you ask. valgrind shows allocations when you ask. go build -gcflags="-m" shows escape decisions when you ask. tcpdump shows the wire when you ask. Nothing is hidden — but you do not pay for it on every line of code you write.

The history is consistent across every layer:

  • Assembly → C. "I want to see the registers!" C made registers invisible during writing. gdb kept them visible during debugging. Nothing was lost. Cognitive tax dropped.
  • C → Java. "I want to control when memory is freed!" GC made allocation invisible during writing. JVM profilers, heap dumps, jstat kept it visible during debugging. Nothing was lost. Cognitive tax dropped.
  • Manual SQL → ORM. "I want to see my queries!" (a real concern — early ORMs leaked badly here.) Working ORMs eventually made the SQL invisible during writing. EXPLAIN, query logs, slow query analysis kept it visible during debugging. Cognitive tax dropped.
  • Op. "I want to see the URL!" Op makes the URL invisible during writing. Tracing, debug-mode emit, generated artefact inspection keep it visible during debugging. Same shape as every previous step.

Each generation worried that the next layer would erase the layer below. None of them did. Assembly is still there for those who write compilers. C is still there for those who write databases. SQL is still there for those who write query optimisers. URLs are still there for those who write transports. None of those layers got abolished. They moved into the basement, where they belong, with the people who actually need them daily.

The XY-shaped version of this objection is "I want transparency" when the actual feeling is "I am afraid to lose control over a tool I already learned." These two are not the same. The first is about debugging capability — Op preserves it. The second is about identity continuity — Op does not preserve identity continuity, on purpose. The protocols people learned to write by hand were tools, not parts of who they are. The same applies to URLs. The same applied to memory addresses. The same applied to SQL.

For engineers genuinely worried about debugging: Op compilers are required to emit traceable artefacts. The wire is logged in debug mode. The compiled URL is inspectable. The trait resolution is dumpable as JSON. Whatever you used to read by hand, you can still read — you just no longer have to write it by hand. The asymmetry is the whole point.

Sources. docs/notes/universal/009-the-address-is-a-detail.md, docs/notes/universal/015-the-black-compiler.md, docs/notes/universal/017-postgres-is-a-jit.md, docs/notes/universal/018-hand-written-deopt-guards.md.

"Publishing /operations is a security risk"

Objection. Publishing a machine-readable list of every operation a service can perform amplifies the attack surface. Attackers enumerate endpoints, find privileged operations, craft payloads. This kills adoption in banks, healthcare, government, defence.

Short answer. Op publishes capability descriptions, never keys, credentials, secrets, or user data. Authorization and confidentiality work exactly as before, with the same libraries and the same review processes. The endpoints are already public — through browser network tabs, decompiled mobile apps, error messages, leaked Postman collections — whether Op publishes them or not. Op gives defenders a single honest artefact; it gives attackers nothing they could not already obtain.

Long answer. The full response is in docs/notes/form-of-operation/024-the-trial.md:526-604 (Attack 6 — Security through discovery). Key points from the transcript:

  • Historical precedent. The same panic appeared at every layer of public discovery: IP addresses (1983), DNS (1989), robots.txt (1994), OpenAPI/Swagger (2011), gRPC reflection (2015), GraphQL introspection (2015), /.well-known/ (2019). Each layer's panic aged poorly. Banks today publish OpenAPI. Healthcare publishes FHIR capability statements. Defence publishes OAuth discovery documents. None of this killed adoption; it became the norm.
  • Kerckhoffs's principle (1883). A cryptosystem should be secure even if everything about it, except the key, is public knowledge. If your security depends on attackers not knowing that ChargeCard exists, you do not have security — you have obscurity. Obscurity was bad practice in the 1880s and remains bad practice.
  • Three concerns the objection conflates. Capability discovery (what operations exist — Op's job), authorization (who is allowed to call them — bearer tokens, OAuth, mTLS, API keys), confidentiality (are payloads protected — TLS, encryption, signing). Op touches only the first; the other two work as they always did.
  • Endpoints are already public. Browser network tabs, decompiled mobile apps, copy-pasted Postman collections, error messages leaking schema piece by piece, OPTIONS responses revealing routing, JWTs containing scopes — every existing service narrates its own surface. The attacker who wants to enumerate enumerates in an afternoon, published or not.
  • The asymmetry flips toward the defender. Without /operations, the schema is implicit and scattered; attackers reconstruct it anyway, defenders argue about what the API actually looks like. With /operations, the schema is explicit, versioned, reviewable, and serves as a single source of truth for threat modelling, rate limiting, audit logging, WAF rules, and access control reviews.
  • Auth is unchanged. "If an attacker owning your /operations is enough to compromise you, your auth layer was already broken. Op did not break it. Op just made the pre-existing break visible."

Source. docs/notes/form-of-operation/024-the-trial.md:526-604.

Apache 2.0 · Built in public · Contributions welcome