The Method

PMDA, read back from its own sources: the 2013 blog and the patent family, as an evidence-backed specification.

Parametric Model-Driven Architecture is Guilherme Scomparim's method for building business applications from a model in which an object's State is computed from its data rather than stored, and every transition is gated by Filters, Conditions and Derivations declared in the model. This site is a reading of that method from the two places it was written down: the owlnestblog.com posts of 2013 and 2014, and US patent 9,378,071 B2 with its Australian counterpart.

Every statement about the method here is an assertion with a trust token, a verbatim quote and a link to the frozen source it was read from. Where the sources disagree, or say nothing, the site says so instead of guessing. The reading was done without the author, so some of it will be wrong. The point of the machinery is that the wrong parts are findable.

Start here

The demo. The blog's own Artist, User and Artefact example, run by a small engine that implements exactly what the specification says and nothing more. It shows the one thing the sources leave open: an Artist with both a createdDate and an activatedDate is in two States at once, and nothing in the sources picks one.
The questions. 37 open for the method's author, ordered by how much of the specification depends on the answer. 2 blocking. 5 were settled by the patent after they were written and are kept on the record.
The spec. 53 live assertions across the constructs, 39 of them quoted from a source. None is marked stable, deliberately: nothing should be while the blocking question is open.
The evidence. 556 captured files, every one checksummed, and an honest count of how many transcripts a human has re-read against the image: 0.

What the reading found

The patent settles four questions the blog leaves open. A Filter is existential (PM-FLT-0060). A Condition validates the State the Operation would achieve, not the current one (PM-CND-0050). A Component refines its imports and never overrides them (PM-FLT-0070). There are no timers at all; every transition is an inbound event.
State is a set. Restrictions in the worked example only accrete, so state() returns every satisfied State, and no source gives a selection rule. The demo shows this on its first screen. Q-G-0001, PM-STR-0030.
The worked Derivations read the clock and the acting user. afn:now() and pmda:User() are the only two formulas in the sources. As written, the example cannot be replayed bit for bit. Q-G-0034, PM-DET-0020.
Derivations attach to Authorizations, not Operations. The same Operation on the same data writes different values under a different Authorization. PM-AUT-0030.
The blog's Condition table is inconsistent with itself. Five of its twelve rows name a State that does not exist, and five put a State name in the property column. The demo reports both rather than correcting them. Q-G-0040, Q-G-0042.

How to read a trust token

SRC-PATENT	The patent says it. Quoted verbatim, linked to the frozen text.
SRC-BLOG	The blog says it. Quoted verbatim. Where the two overlap, the patent wins.
SRC-GUIL	The author said it, on the record. None yet.
INFERRED	Deduced from the sources. The reasoning is on the page; check it.
DESIGN	Our own choice, where the sources are silent. Labelled so it can be argued with.
CONFLICT	The sources disagree, or an example contradicts a rule. Not built on.
OPEN	A question, not a belief. Not built on.

Two rules govern the whole site. If it is not an assertion with an ID, it is orientation, not specification. And every assertion says where it came from, so a reader who knows the method can tell us exactly which reading is wrong.