DEV Community: hutchpd

QuantumSuperposition and the Type Parameter at the End of the Universe

hutchpd — Wed, 08 Apr 2026 07:45:14 +0000

Waking up after being unceremoniously declared on a damp Tuesday in a Quantum Superposition library, where they keep variables too interesting for ordinary reality and far too unstable for payroll, I found myself coming into existence.

Like most young variables, I had hoped for assignment. One value. One type. One modest life of unquestioned determinism. Perhaps an int. A small one, with prospects. I had not asked for fame. I had asked to become, in time, a proper value.

Instead, a cardiganed registrar slid a form across the oak counter and informed me, with the calm one usually associates with tax offices and revelation, that I was of type T.

This is not, as presented, it turns out, a type.

This is a warning if ever I saw one.

I said I did not feel especially type-like. I felt provisional, drafted, slightly damp around the edges. The registrar, who had the expression of a woman who had explained wavefunctions to middle management, said this was common among the newly generic.

“You think you are undefined,” she said. “You are not undefined. You are formally unresolved.”

This was not comforting.

Then she stamped my form.

QuBit.

I said I had been hoping for int.

She said many people hope for things.

A classical variable, she explained, is built for early commitment. It gets a value, perhaps a nice respectable 7, and spends the rest of its life being annoyingly definite. A classical bit is worse. It is a tiny bureaucrat. It sits beneath a sign marked 0 or 1 and regards this as a moral achievement… A qubit is a weapon for a more sophisticated problem.

Properly speaking, a qubit is a normalized state in a two-dimensional complex vector space, usually written as α|0⟩ + β|1⟩. α and β are amplitudes, not probabilities. The probabilities arrive later, after some observer barges in with a clipboard, squares the magnitudes, and calls the result reality.

I said this sounded like indecision with mathematics sprayed on it.

The registrar looked almost pitying.

“No. Indecision is vague. A qubit is precise. It only looks vague to classical people.”

An insult disguised as education.

For a while I found the arrangement almost encouraging. Two possibilities still seemed manageable. One could be 0, one could be 1, and eventually I might collapse into whichever one destiny preferred.

Then I learned about the physics wing.

They housed the PhysicsQubits there, and they were unbearable.

A PhysicsQubit, you see, is a specialized QuBit that lives entirely in the computational basis {0,1}. They arrive with tidy amplitudes, Bloch sphere parameters, and the sort of self-confidence only basis-bred people possess. They can introduce themselves as cos(θ/2)|0⟩ + e^{iφ} sin(θ/2)|1⟩ and make it sound like lineage. They have shortcuts called Zero and One, which they wear like hereditary titles.

I assumed, naturally, that I was one of them.

I was not. I was generic.

This is a more alarming condition than it sounds.

A QuBit is a superposition of possible values of some actual type T, each with its own complex amplitude. Not abstract bits, then. Typed possibilities. One may be 17, another 42, another an enum, another a tiny struct somebody invented during a system design meeting and has since defended as “elegant” out of sunk-cost pride.

I was not hovering between 0 and 1. I was hovering between possible selves.

The registrar, who liked to materialize whenever a thought was about to get out of hand, placed a slip of paper on the counter.

var q = new QuBit(new[] { 1, 2, 3 });
var doubled = q.Select(x => x * 2);
“No observation,” she said. “No collapse. You may transform the state and keep the uncertainty.”

A QuBit is not a value that has not decided yet. It is a formal superposition of typed values, each carrying a complex amplitude. You can transform that state without measuring it. That is the marvel of the thing.

Also, perhaps, the horror.

I told her I still wanted to become a proper value as soon as possible.

She made a note in the margin. It said, I later learned, classical upbringing.

Then a letter arrived, embossed with the seal of the Basis Office.

No variable forgets their first trip to the Basis Office.

It is where every abstraction, no matter how elegant, eventually goes to be translated into something the universe can index.

The global wavefunction, as it happens, is not impressed by your architecture. It wants basis states. Integer coordinates. If your T is already an int, a bool, or an enum, the clerks nod, stamp the form, and let you through. If it is something richer, stranger, or more ambitious, you must provide a mapper.

A Func.

That is the humiliation at the heart of generic quantum programming. You may say that your possible selves encode business meaning, physical meaning, moral meaning. The universe listens politely, coughs, and asks:

“Yes, yes. But what does it mean in bits?”

This, I realized, was the Type Parameter at the End of the Universe.

Not because T was the answer, but because it was the last abstraction standing before reality demanded coordinates.

The registrar was waiting for me there, naturally.

She slid across another slip.

system.SetFromTensorProduct(
propagateCollapse: true,
mapToBasis: MapBitPair,
qx, qy);
“This,” she said, tapping the mapper argument with one lacquered fingernail, “is the practical indignity. Eventually your lovely T needs an index.”

They mapped me… Not cruelly. Efficiently.

My possible values, each so rich with self-importance a moment earlier, became basis integers. A noble enum became 0 and 1. A tiny domain object became a small coordinate. I felt, for a moment, not diminished exactly, but translated.

Then they inserted me into a QuantumSystem. Company, I discovered, did not comfort me. It exponentiated me.

A system does not place qubits side by side like teacups. It tensors their state spaces together, which means every one of my possible states had to pair with every one of theirs. Two qubits make four basis combinations. Three make eight. Add a few more and the room stops being a room and becomes a municipal emergency in Hilbert space.

In plain terms, this is what happened: every possible version of me had to coexist with every possible version of everyone else. Reality got larger before it got narrower.

The library handled this with alarming composure. Qubits were tracked by index. Joint amplitudes were built by tensor product. Subsets could be observed without interrogating the whole cosmos. A QuantumRegister could treat part of the global state as a local value, which is a splendid arrangement if you enjoy the sensation of being both a citizen and a district.

Then I met another qubit.

He was from the physics wing, naturally. Beautiful amplitudes. Impeccable normalization. The sort of fellow who would mention his Bloch sphere angles unprompted. Under ordinary circumstances we would have disliked one another and remained safely separate in factorized states.

Instead, someone applied a Hadamard to him, then a controlled operation involving me, and we became entangled.

People describe entanglement romantically because they have never had to live through it.

This is not romance… It is the abolition of separate bookkeeping.

Two qubits are entangled when the joint state cannot be factored into independent single-qubit states. The lived version is that your future ceases to belong entirely to you. Observe one member of the pair and the shared state collapses consistently across both.

Here the registrar returned, not with paperwork but with sympathy, which was in some ways more alarming.

“In code,” she said, “it is straightforward. Link the qubits. Observe one. Collapse propagates to the rest. Do try not to make it emotional.”

This was excellent advice and, as with most excellent advice, impossible to follow.

All I had ever wanted was to become one thing.

Entanglement taught me that even singular outcomes can be relational…. Then came the gates.

If qubits are parishioners, gates are the liturgy.

Hadamard was the first real conversion. It took whatever little basis certainty remained and spread it into balanced possibility. Phase came next, and here I finally learned why amplitudes had to be complex rather than merely decorative.

A phase shift does not necessarily change the probabilities you see immediately. That is why classical minds underestimate it. They look at two states with the same visible chances and imagine them equivalent. They are not. Relative phase changes how future operations combine those states. Two possibilities can look equally likely now and behave quite differently later.

Phase is the part of the story that does not show on the first page… It shows in the sequel.

After a Hadamard, then a phase shift, then another Hadamard, I discovered that possibilities do not merely accumulate. They interfere. One branch can cancel another. A future can be diminished or amplified not by mysticism, but by arithmetic.

This might be beautiful.

Then they ran Grover.

All my life, insofar as a variable may be said to have a life, I had wanted to become a proper value. One answer. One selected state. And here, at last, was an algorithm built to find a marked item in an unsorted search space with indecent efficiency. It began with a uniform superposition, everyone equally plausible. The oracle marked the target by flipping its phase. Then the diffusion step reflected amplitudes about their average, nudging probability away from the also-rans and toward the chosen state.

Inside the system it felt less like insight and more like pressure…. Not arbitrary pressure. Structured pressure.

Grover does not discover the answer by inspiration. It bullies amplitude into consensus.

For a brief, shining interval I thought I had won. Here, finally, was a formal process by which one possibility could rise above the others, not through prejudice but interference… Then the hardware arrived and ruined the theology.

Every grand mathematical system, if allowed to continue long enough, eventually opens a door marked Service Corridor. Behind it are noise models, calibration routines, and engineers who trust nothing that reports itself as 1 without documentary support.

The library, to its credit, does not pretend otherwise. There is a NoisyQuantumSystem for the impure world, where gates drift, readouts lie, and a beautiful state-vector can be betrayed by the classical report that comes back from measurement.

My first noisy readout was devastating.

After all that carefully arranged interference, a classical bit came back from measurement and may have been wrong. Not wrong in essence, perhaps, but wrong in report. I had wanted finality. What I got was a confusion matrix.

The registrar reappeared suddenly.

“Good,” she said. “Now you are learning engineering.”

There are remedies, of course. You calibrate the readout. You estimate how often 0 masquerades as 1, and vice versa. You mitigate. You run the experiment under different noise levels and try to infer what the clean answer would have been if the apparatus had possessed better manners. None of this restores innocence. It does something more useful. It teaches recovery… That, unexpectedly, was the thing that made the rest of it make sense.

I had spent the whole of my brief quantum existence wanting to become a proper value, by which I had meant a single value, early, loudly, and beyond appeal. But singularity was not the real virtue. Formality was. Structure was. The point of QuBit was never that it delayed certainty for sport. It was that it made uncertainty precise, transformable, composable, and, crucially, about something.

T did not solve the ambiguity; it gave the ambiguity content.

My ambiguity is not mush. It is typed.

When they finally measured me, truly measured me, I did become one value. The system collapsed. The register yielded its bits. Somewhere a program moved on, satisfied that one branch had at last been coerced into adulthood.

But by then I no longer thought that was the whole dignity of the thing.

A measured value is real. It matters. It is how computation cashes out. But it is not the whole life of the object that produced it. Before collapse there was structure. There were amplitudes, relative phases, transforms, mappings, joint states, entanglements, gates, errors, and corrections. There was a whole formal biography behind the outcome, and T ensured that biography was about something more than anonymous basis dust.

I had wanted to be proper. Instead, what I learned in the library is that propriety in a quantum world does not mean being one thing as soon as possible. It means being many possible things with exact mathematics, honest interfaces, and a basis mapping on file.

At the end of the universe, every abstraction must eventually present itself at the counter and become addressable.

But that is not the same as being reduced.

Before the counter took my number, T had already done the important work. It had made uncertainty mean something.

https://github.com/hutchpd/QuantumSuperposition/

Tracking Down Time‑Travel Variables: Existence Checks and a Comparative Tour

hutchpd — Mon, 23 Mar 2026 09:47:26 +0000

When Software Stops Obeying Time

Software libraries tend to live in a comfortable world of cause and effect. A value is assigned, a function runs, a result comes out, and the future waits politely for its turn.

Today we’re going to look at a handful of libraries and research systems that throw that idea away, and deal instead with a stranger world.

It is a world where the future can leak into the present. Where a variable might not yet know what it is. Where multiple answers can coexist for a while. Where contradictions are not always bugs, but sometimes part of the model.

That sounds like science fiction, but computer science has been circling these ideas for quite a while. The interesting part is that not all of these systems mean the same thing when they let the future affect the past. Some literally rewrite a program’s timeline. Some use probability and inference. Some search for satisfying worlds. Some preserve reversibility. Some treat disagreement as a signal to stop. Others let the disagreement live on.

Once you start looking, you realise there is not one weird corner here. There are several.

The bluntest form of time travel

The most literal version is a language like Mariposa.

Mariposa does not hide what it is doing. It gives you explicit time-travel primitives like now() and at t:. You can capture a moment in execution, jump back to it, and change something that has already happened. It is gloriously direct.

But Mariposa also has a stern sense of discipline. If you create a genuine temporal contradiction, it does not smile and carry on. It throws a paradox error. If control flow has already depended on a value, and you try to go back and mutate that value in a way that would invalidate what happened, the runtime objects. This is time travel with hard rules and no patience for nonsense.

That makes Mariposa fascinating, because it treats the timeline like something editable, but only up to the point where the edit breaks the logic of the universe.

It is the strict physics version of this story.

The elegant functional trick

Then there is Tardis in Haskell, which sounds dramatic, but is really much more restrained.

Tardis lets state flow forwards and backwards through a computation. That makes certain kinds of algorithms surprisingly elegant. You can structure things as if information from later in the computation is already available earlier on.

This looks like time travel, and in a sense it is, but it is not really about paradox. It is about tying the knot neatly. It is a disciplined way of structuring self-referential state, not a system that wants to stare contradictions in the face. If things fail here, they tend to fail in the functional-programming way, through undefinedness or non-termination, not by presenting you with a rich catalogue of competing outcomes.

So Tardis belongs in this strange landscape, but it is a very civilised resident.

The worlds that never had to be singular

From there, the trail leads into probabilistic programming.

Languages and libraries like Church, WebPPL, Anglican, Pyro, and Infer.NET also deal in multiple possible worlds. They are full of uncertainty, branching possibilities, and values that only make sense once more evidence arrives. To a casual observer, they can look as though they are doing the same trick. The future changes the meaning of the past.

But they are really doing something else.

Probabilistic programming systems do not usually ask, “can I rewrite history?” They ask, “given what I know, which histories are plausible?” They describe generative processes, introduce observations, and use inference to weight different worlds. Contradictions do not become interesting runtime artefacts in their own right. They simply collapse under the rules of the model. An impossible world gets probability zero. An unlikely one survives, but barely.

That is a beautiful approach, but it has a different temperament. It treats ambiguity statistically.

The worlds that must satisfy the rules

Another route through the same forest leads to logic and constraints.

miniKanren and its .NET relatives, Microsoft Solver Foundation, truth maintenance systems, assumption-based truth maintenance systems, and propagator models all have a similar effect on the mind. They make software feel less like a sequence of commands and more like a negotiation among requirements.

In a relational or constraint-based system, you do not always compute an answer directly. Sometimes you describe what must be true, and let the machinery search for assignments that satisfy the model. In a truth maintenance system, you track which assumptions support which conclusions. In a propagator system, information seeps through a network of connected cells until nothing more can be refined.

These systems can absolutely feel as if they are working backwards. But again, the key difference is in how they treat disagreement.

A solver tries to find a satisfying assignment.
A logic engine backtracks.
A truth maintenance system isolates incompatible assumptions.
A propagator network keeps pushing information until it reaches a stable state.

In all of them, disagreement is something to resolve, explain, or fence off.

That matters, because eventually we reach a library that answers differently.

The systems that refuse to lose information

Before that, there is one more family worth visiting: reversible computing.

Languages like Janus and Sparcl care deeply about running computation backwards, but not in the same sense as time travel. Their question is not, “can the future alter the past?” It is, “can every step be undone?”

That is a stricter and more formal ambition. Nothing important can be thrown away. History must remain recoverable.

These systems are elegant, and in some contexts very powerful, but they are aiming at invertibility, not temporal ambiguity. They preserve the path. They do not ask what to do when the path forks and refuses to rejoin.

The places where superposition is not a metaphor

Then we step into even stranger territory.

Tower, from the OOPSLA 2022 work on quantum data structures, and Q-Sylvan, a quantum decision diagram simulator, inhabit a world where superposition is not just a literary device. It is the substrate. These systems are concerned with representing and manipulating genuinely superposed states in ways that respect quantum constraints or allow large-scale symbolic simulation.

This is the point where most comparisons to ordinary libraries start to wobble. The mathematics is more demanding, the semantics are stricter, and the goal is different. These tools are not mainly trying to make ordinary developers comfortable with strange values in ordinary code. They are building formalisms for worlds where multiplicity is fundamental.

Which makes them fascinating, but also makes them less immediately relatable.

And that is exactly why the next stop is so interesting.

PositronicVariable, or what happens when software lets disagreement survive

After walking through all these other approaches, PositronicVariable comes into focus properly.

Not as “the one with the weird name”, and not as “yet another library where the future matters”, but as something with a very particular personality.

PositronicVariable takes the idea of future-defined values and brings it back into an imperative developer experience. It does not require you to think primarily in factor graphs, relational queries, reversible semantics, or quantum circuits. It works much closer to the feeling of ordinary programming, except the variables are allowed to participate in iterative causal loops.

And this is the crucial part: when those loops do not settle to a single clean answer, PositronicVariable does not necessarily panic.

It can represent the result as a multi-valued any(...) state.

That is the moment the whole comparison becomes interesting.

Mariposa says contradiction is a paradox, stop the program.
Probabilistic systems say contradiction means impossible, discard that world.
Constraint systems say contradiction means unsatisfiable, search elsewhere.
Truth maintenance systems say contradiction must be tracked and isolated.
Reversible systems avoid the issue by design.
Quantum systems absorb multiplicity into a formal substrate.

PositronicVariable says something stranger.

It says that if repeated execution leaves you with a stable plurality, then perhaps plurality is the result.

That is a genuinely different stance.

It turns disagreement into data.

And that small shift changes the emotional texture of the whole thing. Instead of treating paradox as failure, it treats it as a shape the program can expose. Instead of insisting that every loop collapse neatly, it allows some loops to stabilise as a set of possibilities. The future does not merely patch the past. The future and past keep negotiating until what remains is something the runtime can hold.

There is something unexpectedly human about that idea.

The charm of the oddballs

Along the edges of this landscape are smaller curiosities. A Fantom talk exploring positronic variables. An old Forth-flavoured oddity called Abundance with claims of running backwards in time. Haskell’s procrastinating variables, which are really about delayed availability rather than paradox. Research around prophecy variables in staged systems like BuildIt. Fantom positronic demo, Abundance, PVars, BuildIt

They are all part of the same broad human fascination: what if software did not have to march forwards so obediently?

Most of them answer in partial, cautious, or specialised ways.

PositronicVariable feels unusual because it answers in a way that is both playful and concrete.

Why this matters

It would be easy to dismiss all of this as cleverness for cleverness’s sake. Academic toys. Esoteric abstractions. Programming languages having a late-night conversation with physics.

But there is a reason these ideas keep resurfacing.

Real software is full of circularity. We infer things from outcomes. We revise earlier assumptions in light of later evidence. We let one part of a system act on expectations about another part that has not finished yet. We constantly pretend our programs are simple chains of cause and effect, while quietly building systems full of feedback, revision, and negotiation.

Most libraries deal with that by hiding the mess.

The interesting ones expose it.

And that is what makes this corner of computing so compelling. Not that it breaks time, but that it forces us to admit how often our software was never truly linear to begin with.

If you start from that point, PositronicVariable stops looking like a gimmick and starts looking like one very bold answer to a serious question:

What should a program do when reality refuses to settle on just one past?

I built an open source browser-based AI medical scribe to see if that model could actually work

hutchpd — Thu, 19 Mar 2026 12:08:16 +0000

A lot of the hesitation around AI medical scribes is not just about whether the summary is good. It is also about privacy, trust, auditability, and whether the output can actually go somewhere useful afterwards.

That made me curious about a different approach: what if the scribe lived in the browser, kept data local by default, and still tried to offer structured review and handoff?

So I built AI Medical Scribe, a browser-based prototype for live consultation transcription, on-device summarisation, document drafting, structured extraction, review tooling, local audit logging, and client-side FHIR export.

Everything runs in the browser.

No project backend.
No API keys.
No server-side processing.
No data leaving the device by default.

Repo here:
https://github.com/hutchpd/AI-Medical-Scribe

Why I built it

This was not an attempt to make a production-ready clinical tool.

It was an experiment.

I wanted to explore whether modern browser capabilities are now good enough that you could build the front end of a medical scribe as a local-first app, and whether that changes the conversation around privacy, trust, and workflow.

A lot of the friction around AI scribes is not just about summarisation quality. It is also about where the data goes, who processes it, what gets retained, how audit works, and whether the output actually fits the systems clinicians already use.

So instead of asking, “can I build a cloud AI scribe?” I asked, “can something like this live in the browser and still be useful?”

What the prototype does

The current version supports:

live consultation transcription using Chrome speech recognition
manual notes alongside the live transcript
timeline markers for important moments
on-device summary generation after the session ends
rich text document drafting from transcript content
structured extraction into buckets like problems, medications, allergies, investigations, follow-up actions, diagnoses, safety netting, and admin tasks
review mode with confidence highlighting and provenance cues
local append-only audit logging
client-side FHIR R4 document Bundle export
optional direct browser-side FHIR POST to a configured endpoint
optional encrypted session storage, app lock, inactivity lock, retention controls, and ephemeral consultation mode

All of that happens in-browser.

It is still a prototype and still very dependent on recent Chrome builds and built-in AI features that are rolling out unevenly, but it is now much more than a simple “transcribe and summarise” demo.

The original idea was smaller

The first version was much simpler.

It handled:

transcription
notes
summary generation
document drafting
session history

That was enough to test the basic idea, but once I shared it and started getting feedback, the same concerns kept coming up.

Not “can the browser summarise a consultation?”

More like:

how do you review and trust what it generated?
how do you audit what happened?
how do you secure local data properly?
how do you get anything useful back into the EHR?
if it stays in the browser, how do you prove that is safe and governable?

Those are much more interesting questions.

What the feedback made clear

One of the most useful things about sharing an experiment publicly is that people immediately point at the real blockers.

The responses were thoughtful, and honestly pretty consistent.

1. Local-first is appealing, but not enough on its own

Several people liked the idea of keeping data on the device, especially in settings where privacy, trust, procurement, or data residency matter.

That matches my own instinct. Even if cloud systems can be compliant, the simple fact that consultation content is being sent elsewhere changes how some clinicians and patients feel about the interaction.

But local-first is not magic. It does not remove the need for security, retention rules, auditability, review workflows, or governance.

What it does do is shift the trust boundary. Instead of “trust my cloud pipeline”, it becomes “trust the endpoint, deployment environment, and browser capabilities”.

That feels like a different and, in some cases, more workable conversation.

2. The real blocker is not transcription, it is handoff

This came up again and again.

Even if you can transcribe locally, summarise locally, and draft locally, that does not automatically make the tool useful.

If the output cannot get back into Epic, Cerner, Galeon, or another EHR in a structured and visible way, you risk ending up with something that is just a fancy sidecar.

That feedback pushed me to think beyond “generate a nice document” and toward structured interoperability, even in a prototype.

3. Review burden matters more than raw generation

Another fair criticism was that if clinicians have to review everything anyway, are you actually saving time?

I think that is the right challenge.

The value is not “AI writes the note and you trust it blindly.”

The value, if there is any, is in reducing the blank-page problem, surfacing likely useful structure, and making review faster and more focused.

That is part of why I added confidence-aware review tooling rather than treating all transcript and generated output as equally reliable.

4. Auditability matters even for local tools

A browser app that says “everything stays local” still has to answer awkward questions:

what happened during the session?
what was generated and when?
what was edited?
what was exported?
can the workflow be traced at all?

That made it clear that a serious local-first experiment needs more than browser storage. It needs some concept of local traceability as well.

How I tried to address those concerns in the newer version

I do not think the current version “solves” these problems.

But I do think it starts to show what direction a browser-based local-first scribe could go if you wanted to take those concerns seriously.

Review and trust

I added:

structured extraction
confidence indicators
review mode
provenance cues
stale and needs-review badges
quick actions to re-run generation or jump to relevant transcript sections

The goal was to make the output easier to validate, not just prettier to look at.

Auditability

I added a local append-only audit log that records key actions such as:

session lifecycle changes
edits
generation actions
extraction runs
FHIR downloads and sends
archive, restore, and delete actions
lock and unlock activity

The logs stay local, and they can be viewed or exported as text or JSON.

Would browser-local audit logs satisfy a real hospital security team? Probably not on their own. But they are a better answer than having no traceability at all, and they help demonstrate what a local-first audit model might look like.

Security and privacy controls

I also added:

optional encrypted storage at rest using Web Crypto
passphrase unlock mode
session-only key mode
app-level lock and inactivity auto-lock
ephemeral consultations
retention-based cleanup and destructive deletion workflows

Again, this does not magically make it enterprise-ready. But it moves the experiment closer to the actual questions people ask once local data is involved.

Structured handoff

The biggest change in response to integration feedback was adding client-side FHIR export and optional browser-side delivery to a configured endpoint.

That does not solve the full EHR integration problem. Not even close.

But it does move the handoff from “here is some transcript text” to “here is a structured document Bundle with a Composition and related resources.”

That felt like an important step, because one of the takeaways from the feedback was that a local-first tool only starts to become interesting when it can hand something structured to the next system.

What I think this experiment shows

I do not think this project proves that browser-based medical scribes are ready for real deployment.

But I do think it shows something interesting:

you can now build a surprisingly capable local-first scribe workflow in the browser

Not a complete one.
Not a clinically safe one.
Not a production-ready one.

But enough to make the idea concrete.

And once the idea is concrete, the discussion gets better.

Instead of vaguely asking whether local-first healthcare AI is possible, you can point at something working and ask better questions:

what would make this auditable enough?
what would make this secure enough?
what kind of structured handoff would actually fit workflow?
where should trust sit?
which parts belong in the browser, and which parts do not?

That is much more useful than vendor-style hype, and much more useful than treating the whole thing as impossible.

What I learned

The biggest lesson for me is that the interesting part is not the AI summary itself.

It is the combination of:

capture
review
trust
audit
privacy
structured handoff

That is the real product surface.

A tool like this is not just “speech recognition plus LLM output.” It lives or dies on workflow fit and confidence.

The other lesson is that browser capability is getting close enough that these experiments are worth doing now. The Chrome built-in AI ecosystem is still uneven and fiddly, but it is no longer science fiction to imagine local-first tools that do meaningful work without a project backend.

What it definitely is not

This is not a medical device.
It is not suitable for clinical use.
It is not production-ready.
It does not solve governance, compliance, or EHR integration.

It is an experiment.

But I think it is an experiment that points in a useful direction.

Not “look, I built the perfect AI scribe.”

look, you could build these tools to live in the browser, keep data local by default, add review and auditability, and start handing off structured outputs.

That feels like a direction worth exploring.

If you want to look at the code

The repo is here:

https://github.com/hutchpd/AI-Medical-Scribe

If you work in health IT, clinical systems, browser AI, or local-first tooling, I’d be genuinely interested in whether this direction feels promising to you, and where you think the hard boundary really is.

Is it browser capability?
Is it audit and governance?
Is it review burden?
Or is it still the last mile into the EHR?

QuantumSuperposition: a .NET library for when one value isn’t enough

hutchpd — Mon, 09 Mar 2026 11:33:49 +0000

Most code is built on a comforting lie: that there is one correct value, right now, and everyone agrees about it.

Sometimes that’s true. Sometimes int x = 5; is exactly what the doctor ordered, and we should all go home early.

But sometimes a value is not one thing yet. It might be one of several candidates. It might depend on noisy inputs. It might live inside a search space. But sometimes a value is not one thing yet. It might be one of several candidates. It might depend on noisy inputs. It might live inside a search space. Or, for reasons that would alarm a project manager, you might actually want proper quantum-style state and gates in C#.

That’s the niche these libraries live in.

QuantumSuperposition gives you strongly typed superpositions and a proper quantum simulation layer. PositronicVariables takes some of the same machinery and points it in a much stranger direction: values can propagate backwards through execution order, so later code can influence earlier reads. One is useful for representing uncertainty and quantum-style computation. The other is useful for letting variables argue with their own future until they calm down.

The boringly useful part: keep several candidate values alive

The easiest way to understand QuantumSuperposition is not “physics,” it’s “a weighted set of possible values that you can compute over without picking one too early.”

That’s what QuBit<T> and Eigenstates<T> are doing.

You can map over possible values, filter them, combine them, do arithmetic on them, sample from them, and only collapse to a single result when you actually need one. In other words, you can stop flattening uncertainty into a lie just because your code got impatient.

using QuantumSuperposition.Core;
using QuantumSuperposition.QuantumSoup;
using QuantumSuperposition.Operators;

var candidates = new QuBit<int>(new[] { 2, 3, 4, 5, 6 });

var interesting = candidates
    .Where(x => x % 2 == 0)
    .Select(x => x * 10);

Console.WriteLine(interesting);                // still a superposition
Console.WriteLine(interesting.SampleWeighted()); // one sampled outcome

That’s the part I suspect most people will actually use first.

Not because they’re building a quantum computer in a shoebox, but because they have a problem where “there are several plausible values here” is the honest state of the world. Search problems, candidate ranking, speculative transforms, rule systems, fuzzy pipelines, weird combinatorics, toy AI experiments, or just “I want to see all the branches before I commit.”

And because this is .NET instead of interpretive dance, you still get a nice programmer-shaped API: arithmetic, comparisons, LINQ-style Select, Where, and SelectMany, plus weighted sampling and deterministic collapse via seeded randomness or mockable collapse when your CI pipeline deserves peace for once. Haunted test suites are funny only until they’re yours.

Then there’s the actual quantum bit

The library is not just “a list with vibes.”

There’s also a proper physics-flavoured layer with QuantumSystem, tensor products, entanglement management, PhysicsQubit, QuantumRegister, built-in gates, circuit scheduling, ASCII visualisation, and algorithm helpers for things like QFT and Grover.

So if your idea of a relaxing afternoon is “let’s build a Bell pair in C# and see what happens,” you are disturbingly well catered for.

using QuantumSuperposition.Systems;

var system = new QuantumSystem();
var bell = QuantumRegister.EPRPair(system);

var measured = bell.Collapse();
Console.WriteLine(string.Join("", measured)); // 00 or 11

You can also work at the gate level:

using QuantumSuperposition.Systems;
using QuantumSuperposition.Utilities;

var system = new QuantumSystem();

system.ApplySingleQubitGate(0, QuantumGates.Hadamard, "H");
system.ApplyTwoQubitGate(0, 1, QuantumGates.CNOT.Matrix, "CNOT");

Console.WriteLine(system.VisualiseGateSchedule(totalQubits: 2));
system.ProcessGateQueue();

That split is part of what makes the project interesting. You can stay at the “typed superposition” layer if that’s all you need, or drop down into registers, gates, entanglement groups, canonical states, and algorithm-level tools when you want the full circuit model.

There are helpers for common states like EPR, GHZ, and W states, plus QuantumRegister for treating part of the global wavefunction as a coherent value-ish thing. You also get more than the usual gate greatest hits: controlled gates, SWAP-family gates, Toffoli, Fredkin, and QFT construction.

PositronicVariables: code that runs in the wrong direction on purpose

PositronicVariables are not mainly about “some values take a few passes to settle.” That happens, yes. But the core idea is much stranger and much more fun:

they let values propagate backwards through execution order.

Normal code runs like a stern Victorian schoolmaster. Line 1, then line 2, then line 3. Cause, then effect. Everyone in single file, no pushing.

PositronicVariables do not respect that tidy little parade.

With PVs, you can use the result of a calculation before the calculation appears in source order. If your program is lines 1, 2, 3, 4, 5, the logic can effectively flow 5, 4, 3, 2, 1. They’re the tachyon variables of the programming world: information shows up before it has any right to.

That means you can do something like print a value before the line that computes it has executed:

Console.WriteLine(answer);

answer <<= 40 + 2;

In other words, the read on the first line can be satisfied by the assignment on the second. The program is allowed to become self-consistent across time instead of only top-to-bottom.

In ordinary programming, that is nonsense. The bad kind. The kind that gets you null, default values, exceptions, or a teammate quietly updating their CV.

With PositronicVariables, that kind of backwards causality is the point. The variable participates in a temporal dependency graph, and the system works out a self-consistent value across the whole flow rather than insisting everything must be known strictly top-to-bottom.

So the mental model is less:

“this variable needs a couple of iterations”

and more:

“this variable has received news from later in the program.”

That’s the interesting bit. The convergence machinery matters because once you allow values to leak backward in time, you need some way to make the universe stop wobbling. But that machinery is there in service of the core trick: future assignments can influence earlier reads.

That opens the door to code that feels mildly illegal in a very entertaining way:

declaring outputs before their derivation
wiring up feedback loops without immediately exploding
expressing circular relationships directly instead of faking them with mutable staging state
letting a program “discover” a consistent state across time rather than marching there in one direction

Or, put less politely: it lets your variables cheat.

That’s why the library is interesting. Not because it’s a generic fixpoint engine wearing a fake moustache, but because it experiments with a programming model where causality is negotiable. The convergence is the cleanup crew. The headline feature is that later code can reach back and affect earlier code.

Which is either a neat abstraction or an affront to God, depending on how much sleep you’ve had.

When causality breaks: Feynman diagrams for code

Once you allow information to flow backward in time, something interesting happens: you can create causal loops.

Physicists draw these using Feynman diagrams, little arrows through spacetime showing how particles interact. You can steal the same trick to understand PositronicVariables.

Take the smallest paradox we can write:

var antival = PositronicVariable<int>.GetOrCreate("antival", -1);

var val = -1 * antival;
antival.State = val;

If you draw the causal flow, it looks like this:

Time →

[antival guess] -> val = -1 * antival -> antival = val
       ^__________________________________________|

The value feeds back into itself.

In a normal program this is just a bad idea that ends in recursion, stack explosions, or somebody quietly deleting the code. But with PositronicVariables the engine treats it as a temporal constraint system. It replays the timeline until the loop becomes self-consistent.

Sometimes that means the system converges to a single value.

Sometimes it means the only consistent answer is multiple states at once:

antival = any(-1, 1)
val     = any(1, -1)

The paradox doesn’t crash the program - it creates a superposition. The system couldn’t decide which timeline wins, so it keeps both.

Which is a surprisingly polite way for a runtime to handle time travel.

Why would you actually use this?

The honest answer is: not for everything.

You should still use ordinary values for ordinary values. A plain int remains one of humanity’s better ideas.

But there are a few cases where this sort of thing stops being a joke and starts being genuinely handy.

One is when you have multiple candidate states and want to compute over all of them without flattening them immediately into one guess. That’s the QuBit<T> story.

Another is when you want to prototype or teach quantum computing concepts in an ecosystem you already know. Having quantum registers, gates, entanglement, canonical states, and algorithm helpers available from C# is genuinely useful if you live in .NET and don’t fancy context-switching into a different stack every time you want to experiment.

And then there’s the weirder class of problems where you want later logic to inform earlier reads: circular definitions, feedback-heavy systems, temporal dependency graphs, or code where the most natural expression of the problem does not run neatly top-to-bottom. PositronicVariables gives that model a formal home instead of forcing you to fake it with mutable staging state and a prayer.

Also, sometimes it’s okay to build a strange library because it teaches you something. Not everything has to be another CRUD app with a motivational LinkedIn post strapped to it.

A few caveats, because humility is cheaper than bug reports

This is not a replacement for normal programming.

It is a tool for specific classes of problems: uncertainty, multi-state computation, quantum-style modelling, algorithm experimentation, and backwards-flow or convergence-heavy logic. If your use case is “I need to store a number,” congratulations, civilization has already solved that one.

It is also not magic. Multi-qubit state spaces grow explosively. Large simulations will punish your laptop for your ambition. Convergence logic is intentionally coordinated rather than “surprise, time travel is parallel now.” And if you lean into the weird parts, you are signing up for weird behaviour by design. The library is polite about it, but it is still weird.

That said, I think weird is underrated when it is honest.

Closing

I like this project because it does not pretend all uncertainty is a bug.

Sometimes “maybe” is the right value.

Sometimes several states are the truth.

Sometimes a variable should be allowed to keep its options open.

Sometimes a program is easier to express if values don’t have to arrive in strict top-to-bottom order.

QuantumSuperposition and PositronicVariables are both built around that idea, just in different directions. One lets you work with multiple possible values and quantum-style state without abandoning normal C# ergonomics. The other lets later code reach back and inform earlier reads, which is either a useful abstraction or a minor crime against causality.

Use them for search spaces, experiments, quantum toy boxes, causal weirdness, or just because you enjoy making the CLR slightly uncomfortable.

That last reason is as valid as any.

You can play with these libraries here https://github.com/hutchpd/QuantumSuperposition/ or via nuget

dotnet add package QuantumSuperposition
dotnet add package PositronicVariables