Wetware World

WWD — draft 0.1

Tell us what your process actually costs you

The specification is a draft written from research, not from traffic. The feature-discovery work has not been done: nobody has yet sat with a working laboratory and found out which parts of this are useful and which are a solution to a problem that does not exist. That is the gap we are trying to close, and it is the reason this page asks about your process rather than about our format.

Spec status
Draft 0.1
External implementers
None yet
Working group
None
Discovery campaign
Not yet run

Where this actually stands

Stated plainly, because a draft standard that oversells itself is worse than one that does not exist.

WWD 0.1 exists. It is a real specification with twenty-five normative sections, a JSON Schema set, a reference validator, a conformance suite and a handful of example packages that round-trip. It is implementable. It is also entirely untested against anybody else's work, and that distinction matters more than the page count.

There are no adopters. There are no external implementers. There is no consortium, no working group and no standards-body relationship — the neutral-custody path described on the overview page is a plan, not a fact. The registries are deliberately thin, and the parts of the draft that read most confidently are the parts most likely to be wrong, because normative language is cheap and evidence is not.

So the question is not whether the format is good. It is whether it is about the right things. That question can only be answered by people who make living components for a living, and the fastest way for us to get it wrong is to keep writing without asking.

Six things we want to know

Each one changes something specific in the format. Answer any of them, in any order, at whatever length suits you.

01

Technician hours per batch

How much skilled human time goes into one batch, end to end, including the parts nobody counts — feeds, media changes, imaging, the analysis afterwards. This decides whether the expensive part of the process is the biology or the bookkeeping, and the format should be carrying whichever of those can be carried.

02

Batch failure rate, and how you find out

What fraction of batches you discard, at what point in the process you discover it, and whether you can usually tell why. If failures are found late, the acceptance model needs intermediate criteria rather than only end-of-line ones.

03

Maturation delay before a construct is usable

Days from seeding to the point where the thing is the thing. This is why WWD gives a component a validity window with an explicit time origin — a construct at day 7 and the same construct at day 21 are different articles, and a format that treats them as one identifier is lying.

04

What you measure before accepting a batch

The actual measurement, the actual instrument, the actual threshold, and whether you write any of it down in a form a second person could reproduce. If the real acceptance test is a technician looking at a well plate, we would rather know that than design around a test nobody runs.

05

What mechanical, electrical or fluidic interface you need

How the component physically attaches to whatever you put it in. Loop anchors, pillar spacing, electrode pitch, well geometry, tubing connections, optical access. Interfaces are where two laboratories discover they had different assumptions, usually on the day the parts do not fit.

06

The thing WWD cannot represent

Best of all: something real you tried to describe where the format got in the way. A property with no slot, a quantity with no unit, an assay whose calculation cannot be written down. In a draft standard that is the most valuable message there is.

01 Who you are
Used to reply to you and for nothing else.
What do you work with
02 Your current process

This is the part we care about. Nothing here is required — answer what you can, skip what you cannot, and approximate freely. A rough number you are unsure of is worth more than a blank.

End to end, including the analysis afterwards.
And where in the process you discover it.
03 On the draft itself

Only if you have read some of it. Skipping this section is completely reasonable.

In a draft standard this is the most valuable message we can get.

Read by a person. Every reply gets an answer, including the ones that tell us we are wrong.

How a change gets into the specification

The process is small because the project is small. It is written down anyway.

  1. 1

    It becomes an issue, not a pull request

    Anything beyond a typo starts as a written problem statement. A change to a normative section without prior discussion will be asked to become an issue first, because the discussion is the valuable part.

  2. 2

    It needs a fixture

    Every normative change ships with one valid and one invalid example, which become validator tests. The conformance review is the gate, and "discussed somewhere" is not a pass.

  3. 3

    It is additive by default

    New versions add capability. Redefining what an existing field means breaks every file ever written and is only possible in a major version with a migration path. If a term meant peak isometric force in 0.1, it means that permanently — a new concept gets a new term.

  4. 4

    It appears in a public changelog

    With the reason, and with the contributor named unless they asked otherwise. The public-draft cadence is the one part of the Gerber process worth copying without modification.

If you build these things, you know something we do not

The format is a draft precisely so that it can still be changed by what you say. That window closes once files exist in the wild.