Released is permanent and the reasons for it are not

Abstract

A transition is an event: an item, a from-state, a to-state, an identity and a timestamp. Once it has happened it cannot become untrue. An approval does not have that shape. It is a conditional commitment whose conditions are almost never written down, so when one of those conditions changes the item stays Released while the grounds for releasing it have gone — and a state machine can hold only the first of those two facts.

That condition has no name in PLM. This paper gives it one: released and no longer justified. A state machine has two primitives, states and transitions. Both are discrete, both are asserted and neither can be contradicted by later evidence. There is no primitive for a state whose justification has expired while the state persists. The problem is not modelled badly. It is not modelled at all.

So the question that prompted this paper — is PLM always about moving data and design from one state to another? — has a short answer and a longer one. The short answer is no. The longer one matters more: the movement is real, necessary and correctly built. It is a permission event. The rest of the organisation reads it as a measurement of whether the design is sound, which is a reading the record was never built to support. The gap between those two things is where this paper lives.

What follows proposes one new primitive — an approval that stores the predicate it was granted under, over properties the engine already reads — and then spends most of its length constraining it. It publishes counts from a vendor-shipped configuration before any customer has touched it. It names the prior art, which is older than PLM. It gives staleness a type with four terminal outcomes. It refuses to aggregate any of it into a score. And it grants the position of the quality manager who does not want to hold a discoverable record saying the company's released design has no valid basis, because that position is rational.

1. The question, answered directly

Ask what a PLM is for and the honest functional answer is that it holds identity, structure, versions and access, then moves items between states under rules. That is not a small thing. The discipline took thirty years to get it right and it is the reason you can answer which drawing applied to which unit in which month, which almost nobody could answer before.

But notice what a state transition actually certifies. It certifies that an identity with a particular authority performed a permitted move at a particular moment. That is a statement about permission. It is not a statement about whether the thing being moved was any good.

In practice nobody reads it that way. When a part reaches Released, procurement orders against it, the configurator offers it, the supplier portal exposes it, ERP opens a routing and a planner commits tooling money. Every one of those consumers is treating the label as a verdict on engineering sufficiency. The label does not contain that verdict. It contains the fact that somebody with the right to sign did sign.

Most of the time this is harmless, because the person who signed was right and stays right. The interesting case is the one PLM has no vocabulary for. A substance limit on a cited regulation moves. A load case is revised. An approved-vendor row is withdrawn and a manufacturer part is substituted. An analysis input changes, so a passing result now describes a different product. In each of those cases a set of past approvals should become suspect — and in each case the organisation finds out by emailing whoever is still there.

The state did not move, because nothing moved it. There is no edge pointing backwards from the evidence to the decision that relied on it.

One axis, honestly declared. There are several plausible answers to "what else could PLM be". I can name the ones I am not going to argue here. A BOM could be a derived view over a constraint system rather than a stored tree, so a configuration is solved rather than assembled. The as-built could be abandoned as a concept, because an instrumented fleet is a distribution rather than a configuration. Structures could branch and merge the way source code does. Those are real and I find the first one genuinely exciting. I am leaving them aside because this paper is about the one axis where I can put verifiable counts on the table and point at something buildable now and because a paper that gestures at four futures persuades nobody of any of them.

2. What a shipped configuration already says

The claim that lifecycle states are an authority structure being read as a measurement should not rest on assertion, so here are counts.

These come from an Aras Innovator development database with the standard solutions installed — vendor-shipped configuration, before any customer adds a single state. That makes it a floor rather than a sample of industry practice, which is exactly why it is worth publishing: the proliferation starts before anybody customises anything.

Two hundred and fifty-nine of three hundred and sixty states bind their own permission. The state is where authority attaches and the shipped configuration says so about as plainly as configuration can — which is the argument for granting to teams and lifecycle states rather than to individuals seen from the other end.

Then the sharper number. Twenty-seven states are called Released and fifteen of them set the flag the engine itself uses to mean released. The word and the mechanism disagree in twelve places, in a configuration nobody has customised.

Sixty-five distinct names cover three hundred and sixty states. "In Review" appears in forty-one maps, "In Work" in thirty-five. Nothing guarantees that three states called In Review in three maps mean the same thing and nothing in the model can be asked whether they do. The drift is visible in the names themselves: alongside "In Work" in thirty-five maps there is one "InWork", alongside "Cancelled" in seventeen there is one "Cancel", alongside "Rejected" in twenty there is one "Reject". One state is called Submitted - Awating Disposition, spelling included.

I want to be careful about what that proves. It is naming drift across several independently authored solution packages, which is the ordinary consequence of a large configuration built by different teams. It is not by itself evidence of semantic pressure from an unmet modelling need. What it does establish is weaker and still useful: the state vocabulary is not a controlled vocabulary, so any downstream consumer inferring readiness from a state name is inferring it from a string that nobody governs.

Run the counts on your own estate:

SELECT COUNT(*) FROM innovator.LIFE_CYCLE_MAP WHERE IS_CURRENT = 1;
SELECT COUNT(*) FROM innovator.LIFE_CYCLE_STATE;
SELECT COUNT(DISTINCT NAME) FROM innovator.LIFE_CYCLE_STATE;

SELECT COUNT(*) FROM innovator.LIFE_CYCLE_STATE
  WHERE STATE_PERMISSION_ID IS NOT NULL;

SELECT NAME, COUNT(*) FROM innovator.LIFE_CYCLE_STATE
  GROUP BY NAME ORDER BY COUNT(*) DESC;

SELECT COUNT(*) FROM innovator.LIFE_CYCLE_STATE
  WHERE NAME = 'Released' AND SET_IS_RELEASED = 1;

If the last two numbers differ on your system, you have found your first predicate class before writing a predicate.

What these counts cannot give is the number that would settle the argument. This database holds configuration and no item data whatever — zero parts, zero documents, zero workflow processes — so there is no approval population in it to evaluate a predicate against. The staleness run that would either prove or embarrass this paper has not been performed. The predicates in section 4 are written and unevaluated. Inventing their results would be the one thing that would make the rest of this worthless.

3. Why this got worse rather than better

The gap is not new. What changed is who reads the label and how fast.

When a release was consumed by a person — a drawing came off a plotter and somebody walked it somewhere — the reading carried context with it. The person doing the consuming often knew the person who signed or could ask. Asking is a slow interface and it has one property no automated consumer has: a human being can say "that was approved before we changed the duty cycle, let me check".

Every structural change since then has removed that property, in order. State is consumed programmatically by ERP integrations, configurators, supplier portals and dashboards. The consumers are faster, there are far more of them and not one of them can ask a question. A released flag arrives as a boolean and is acted on as a boolean.

So the label did not get worse. The reading got fast. It got literal. It got detached from anybody who knew what the approval had assumed. That is the sense in which this is a next-generation problem rather than a historical complaint: the more of the engineering-to-manufacturing path you automate, the more weight rests on a field that was only ever a permission coordinate.

It is worth separating this from the ordinary observation that organisations add too many lifecycle states. They do and change processes accumulate ceremony for reasons that have nothing to do with this paper. The claim here is narrower and structural: adding rungs to a ladder does not turn it into a measurement. No number of extra states creates a primitive the model does not have.

4. The missing primitive

The missing primitive is an approval that stores what it was granted under. It is ordinary dependency tracking applied to authority rather than to data and it has a shape.

• Subject — the approval, never the item.
• Predicate — the expression, in a stated syntax.
• Reads — the exact property paths referenced, resolved to identifiers rather than to names.
• Predicate version, plus the schema version those properties were defined under.
• Asserting identity, plus the authority that identity held at the time.
• Valid-from and valid-to in world time.
• Recorded-at in transaction time, plus the moment the organisation learned a premise had failed.
• Closure hash over the declared input set.

The approval stores what it was granted under. The state stores who may do what. Neither is ever allowed to mean the other.

Three predicates, written against real property shapes:

Evaluation is three-valued, not two. Holds, violated and undecidable-because-the-input-is-absent. In any estate worth discussing the third value is the most common answer on the first run, so what happens to it is the proposal rather than a detail of it. An undecidable predicate raises a different notice to a different owner — a data owner, not an engineering one — and it never, under any circumstances, resolves to still valid. Undecidable absorbed into valid is the single design error that turns this mechanism into reassurance.

Declare the inputs or do not bother. This is incremental recomputation over a declared dependency set. The cautionary example is the oldest one available. Make has worked this way since 1976 and its characteristic failure is exactly the one to avoid: declare a dependency incompletely and it will cheerfully hand you a stale object built against a header you forgot to list. Bazel's sandboxing exists because of that failure — it denies access to undeclared inputs so that an omission fails loudly instead of producing a result which silently depended on something nobody wrote down. The lesson transfers directly. Under-declare an approval's closure and the engine will report still valid forever, which is worse than reporting nothing. So an approval must be able to declare its own closure incomplete — and that state must be visible rather than rounded down to valid.

Making the closure content-addressed buys something practical. Staleness becomes a hash comparison rather than a subscription to a change feed, so it survives migration and replication and runs inside an air-gapped site that syncs once a week with no event stream at all.

Two clocks, three notices, three different obligations. The premise changed after we approved — obligation: review. The premise was never what we recorded — obligation: escalation, because the release was never justified. The premise's definition changed underneath us — obligation: re-author the predicate and draw no engineering conclusion at all. One timestamp cannot tell the first two apart, which is why valid time and transaction time both belong on the row. SQL:2011 already makes this distinction, separating an application-time period the user maintains from a system-versioned period the database maintains. Anyone who has modelled date and serial effectivity has met the same two clocks wearing different clothes. A notified body cares most about the second notice, because the gap between when the world changed and when the organisation recorded it is the exposure window.

This is a different object from the typed reason that explains why a change was made and the difference is load-bearing. Intent is retrospective, narrative and confirmed by a human at a checkpoint. A validity predicate is forward-looking and executable. Its entire value is that it fires without anybody revisiting the decision.

TODAY -- the state machine

  [In Work] --promote--> [In Review] --promote--> [Released]
                                                      |
                     (transition recorded: item, from, to, identity,
                      timestamp. Permanent. Correct. Insufficient.)

  substance limit tightened ............... no edge back
  load case revised ....................... no edge back
  AVL manufacturer part substituted ....... no edge back
  analysis input mass changed .............. no edge back
        the label does not move and nothing knows it should


PROPOSED -- a commitment with live premises

  [Released]  <-- state unchanged, still a permission coordinate
      ^
      |  Approval
      |    predicate  : potting.max_temp >= amb.max + 10
      |    reads      : potting.max_temp, amb.max   (schema v7)
      |    closure    : sha256(declared inputs)
      |    valid from : 2027-03-14   (world time)
      |    recorded   : 2027-03-14   (transaction time)
      |
   potting.max_temp 125 -> 115   [closure hash differs]
      |
      v
  StaleApproval -> named owner, deadline, derivation chain,
                   values then and now, evidentiary class
     outcomes: re-approved | re-approved with rationale |
               change raised | PREDICATE CORRECTED

5. It already has a name and the name is from 1979

I should be plain about the prior art, because a practitioner reinventing something from artificial intelligence research badly is worth less than a practitioner pointing at it accurately.

What section 4 describes is a justification-based truth maintenance system. The mechanism was set out by Jon Doyle in "A Truth Maintenance System", published in Artificial Intelligence in 1979. A TMS does not store beliefs as true. It stores each belief together with the justification that supports it, keeps the derivation chains explicit and retracts or marks a belief when a premise it rested on is withdrawn. Leaves are external facts. Internal nodes are deductions. The system records support rather than asserting truth.

Replace "belief" with "approval" and that is the primitive PLM is missing, described forty-seven years ago and well understood.

So why has no PLM adopted it? Three reasons, none of them stupid:

• The premises were never machine-readable. A TMS needs its leaves to be addressable facts. For most of PLM's history the facts an approval rested on were in a report, a mail thread or an engineer's head, so there was nothing to attach a justification to.
• Truth maintenance was built for systems that reason. PLM deliberately does not reason. It is a system of record and in regulated industries that is a feature, so a mechanism that retracts conclusions on its own was never going to be welcome near a release.
• It makes the organisation's ignorance explicit. A TMS that cannot justify a belief says so. A PLM that said so about a released part would be producing a discoverable record, which is section 8.

The useful observation is that the first reason has quietly stopped being true. Substance figures, test results, approved-vendor rows, analysis inputs and load cases are increasingly values in the model rather than paragraphs in a document. The leaves exist now. That is the actual change that makes this a 2026 conversation rather than a 1996 one.

6. Thursday

The notice is four lines long and Anjali reads it twice in the car park before she goes in.

Rahul answers on the second ring.

"You've seen it."

"This morning."

"It's a convention failing, not a part failing." Paper, somewhere near the phone. "The compound went from one-two-five to one-one-five. Your condition wanted ten degrees over a hundred and ten. Now there's five. The part is fine. The number you picked in 2027 is what's broken."

"Who told you I picked it."

"It's written on the thing. Your name, March 2027, ten degrees." A pause. "Which is a round number, Anjali. You chose a round number."

She did. She remembers choosing it, which is not the same as remembering the decision.

"Change it to five and close it out," he says. "I've got four hundred and twelve units in service and an audit on the twenty-eighth."

A van reverses somewhere behind her. She watches it and thinks about the wash cycle.

The housing sits in a bay that gets hosed down at end of shift. The thermal model said a hundred and ten and the thermal model was steady state, because in 2027 that was the model that existed and nobody was going to pay for a transient. What actually happens is a forty-second soak while the bay drains. She has never seen a number for it. She wrote ten degrees because ten degrees was the size of her ignorance. It was not headroom. It was a note to herself that she had no idea what the end of the wash cycle did.

"Anjali."

"The ten isn't margin."

"Then what is it."

"It's the soak. End of the wash. The bay holds water about forty seconds. It wasn't in the model."

The line goes quiet in the particular way that means he is deciding whether to be angry.

"Then why does the condition say headroom. If it's a soak, write a soak."

"There was nothing to write it against. There's no transient result. There still isn't."

"So the condition is wrong."

"The condition is the closest thing I could write to something true."

"Right. So we fix the condition."

"If we fix it, it stops covering the soak."

"It isn't covering the soak. It's covering a number you made up."

That is either exactly right or exactly wrong and she cannot tell which, standing in a car park at ten past nine.

"Raise it as a change," she says.

"On four hundred and twelve units."

"I didn't say recall. I said raise it."

"It's the same door and you know it's the same door."

She does know. The only way to say this officially is to say it loudly.

"Give me until Thursday."

"For what? There's nothing to measure. You said so yourself."

"There's nothing to measure yet."

"Thursday is a day. It isn't a test rig."

She has four options and she has been turning them over since the train. She can agree it is still fine, which she almost believes. She can agree it is not fine and say why, which puts a dated sentence in the record saying she released a housing against an exposure nobody had quantified. She can raise a change, which costs Rahul his quarter. Or she can correct what she wrote in 2027, which is the only one that is actually true and the only one that tells nobody anything.

"I'm going to correct the condition."

"Good."

"I'm not closing it."

"You can't do both."

She can, probably. She is not sure anybody has.

Inside, she opens the response and types: The stated condition does not describe the exposure it was written to cover. Then she sits looking at that sentence, which is correct and which does not mention the four hundred and twelve.

---

That story contains the strongest objection to this entire paper and I put it in deliberately. The mechanism worked perfectly. It fired on the right part, named the right person and cited the right premise. What it surfaced was not a defective housing. It was a defective predicate — a round number standing in for an unquantified exposure — and the honest resolution produces no engineering finding at all.

That is not a failure of the design. It is the design working at the only resolution available — and it is why predicate corrected has to be a first-class terminal outcome rather than an administrative tidy-up. A system that could not express "the condition was wrong" would have forced Anjali to either clear the notice dishonestly or raise a change she could not justify. Most organisations would pick the first.

The deeper point the fiction can make and the prose cannot: a predicate is often a proxy for ignorance rather than a statement of fact. Making predicates explicit does not eliminate that — it just means somebody eventually has to read their own proxy back.

7. What the engine must never say

A mechanism that produces notices about released designs can go wrong in ways that are worse than the gap it closes, so the constraints matter more than the capability.

It must never produce a score. Not a readiness percentage, not a confidence rating, not a trend line, not a rollup to assembly level. The reason is not squeamishness. Evidence sufficiency is not aggregable: a tested prototype on the wrong load case is worse than no prototype, so any arithmetic that treats them as 0.5 and 0 is producing a number that is confidently wrong in the direction of reassurance. The first executive who reads a paper like this will ask for exactly that figure. The correct answer is that the design deliberately cannot produce one — and a worse product is the price of not lying.

It must never touch the signature. The approval stays a human act with a human name on it. Nothing here converts promotion into constraint satisfaction. A promotion is a vote. Satisfaction of a constraint set is a proof. Confusing the two would quietly transfer accountability from a person to an expression, which is the outcome most worth avoiding.

It must report its own coverage. The number of predicates that could not be evaluated belongs on the same screen as the number that failed, for the same reason a test suite reports skipped tests. An engine that cannot state how often it failed to answer is the dangerous kind of quiet.

It must be gameable only expensively. It will be gamed: predicates narrowed until they pass, test records pointed at a convenient load case, evidence rows created to satisfy a view. This is what happens to every engineering metric that acquires an audience. The countermeasure I accept is an evidentiary class on each row — in-house measured, supplier reported, engineering judgement — so that a weaker class can never silently substitute for a stronger one. The countermeasures I refuse are any weighting, any rollup and any trend, because each of them creates the incentive to manage the number rather than the design.

A boolean stale is useless. A notice that says only "this approval may no longer hold" will be ignored by the second week. The notice has to carry the derivation chain, the value then, the value now and the evidentiary class, because what the engineer needs is not an alarm. It is the four facts that let them decide in ten minutes.

8. The objections with force

"This is what the change process is for." Partly true and the overlap is worth being precise about. A change process handles a known change to a known item: somebody has noticed, raised it and routed it. The gap here is upstream of that — nobody has noticed, because the thing that moved was a premise rather than an item. Every organisation already has a manual version of this mechanism and it is called remembering, usually located in one long-serving engineer.

"PPAP already does this." The strongest objection in the automotive case and it deserves a narrow answer rather than a dismissal. Production part approval, design review checklists and design-control evidence sets are genuine readiness instruments, they predate most PLM products and they work. The contribution is narrower than replacing them: a document package parallel to the model cannot be queried across a structure, cannot be referenced by a release rule and cannot tell you which of four hundred rows is resting on an assumption whose basis has moved. That is the whole claim and anything broader would be wrong.

"A solver with an incomplete model is confidently wrong." Yes, which is why the proposal is deliberately not a solver. It never asserts that an approval is valid. It asserts only that a premise it declared has changed, which is a claim about two values differing and not a claim about engineering sufficiency. The asymmetry is the entire safety argument: the engine may add doubt and may never add confidence.

"Our quality manager will refuse to hold this record." They are right to hesitate and I am not going to pretend otherwise. Once evidence is visible beside a state, signing against a visibly thin premise creates a dated, attributable record showing the organisation released knowing what it knew. That is a real change in exposure and it is a question for counsel rather than for an architect. The only honest thing to weigh against it is that the alternative exposure — having no record of what an approval assumed, and reconstructing it under adversarial conditions years later — is the one most organisations are carrying today without having chosen it.

"The approver will just click through." Probably, at first. The mechanism's value is not that it improves a signature in the moment. It is that a finding with a response is a defence and a finding with no response is an admission, so the asymmetry does the work over time rather than at the point of click.

"How much does it cost?" The predicates are cheap. The expensive part is the join: analysis results sitting in attachments with no declared inputs, and test results in a system with no reliable part key. My estimate is that a scoped first year is one analysis class and one test class, existence and currency only, nothing else — and I am labelling that an estimate rather than a measurement, because I have not run it at scale and you should discount it accordingly. Section 9 is designed so you can price it yourself rather than take my figure.

9. Run it with no authority at all

Five things, none of which need a project or a vendor conversation.

1. Count your own states. Run the statements in section 2 against production. Compare the number of states named Released with the number that set the engine's released flag. A difference is your first predicate class.
2. Write out by hand the conditions one released part's approval rested on. Pick a part you know well. List the limits, test results, supplier records and assumed duty cycles, then mark which exist as a value in the system and which live in a mail folder. That ratio is the size of the work and nobody can produce it for you.
3. Take one analysis result out of the vault and try to establish its inputs. Time yourself. Multiply by the number you would need to instrument. That is year one's real cost — the join rather than the predicates.
4. Settle who owns a finding raised against an approval whose approver has left. By role, with an escalation point and a response time. If that cannot be answered this week, nothing downstream of it is worth building.
5. Write one predicate and run it with no authority at all. A numeric limit, a named test result or a manufacturer part substitution. Evaluate it against last quarter's releases, raising nothing and blocking nothing, then count how many findings a human agrees with. Publish that count internally even if it embarrasses you, because it is the only number in this entire argument that belongs to you.

10. Where the architecture helps and how much

Two things are genuinely true on a platform whose configuration is itself data. The permission-coordinate argument is not rhetoric on Aras Innovator, it is countable — two hundred and fifty-nine of three hundred and sixty shipped states bind their own permission. And because every item type is itself an item with a matching table whose columns are its properties, the property paths a predicate would reference are addressable without new infrastructure, which turns the evidence coordinate from a product request into a reporting problem. That is the whole defensible claim and it is the same structural property as the one in the code boundary and configuration-derived tests.

Two supporting points, kept in proportion. Aras documents Configurator Services as having a built-in Boolean satisfiability solver whose capabilities include getting reasons for invalid options — reasons rather than only verdicts — so the explanation half of this mechanism has precedent in the box. And nothing in the mechanism needs a cloud service, which matters in an air-gapped estate where most 2026 assistant features are simply not deployable.

Now the refusals, which cost more to leave out than to state.

Aras ships none of this. There is no predicate store, no stale-approval type, no closure hash, no scheduler and no reverse edge. Buildable is not shipped, not correct and not safe. Every line of a custom predicate store becomes yours to own, test and carry through upgrades — which is the real cost of configuration-as-data and the opposite of a selling point for an organisation without internal capability.

The counted table says nothing about anybody else. It is one Aras development installation and I have not run the equivalent count on Teamcenter, Windchill or 3DEXPERIENCE, so it is evidence about where proliferation starts in general and evidence about no competitor in particular. Equally, I did not find the reverse edge documented on any platform including Aras — and the correct form of that is a question put to all four vendors rather than a claim made about three of them.

Anyone who reads this section and concludes it would be easy on Aras has read it wrongly.

---

So: is PLM always about moving data and design from one state to another? No. It is about holding a commitment. The movement is only the moment the commitment was made. Thirty years went into recording that moment precisely, which was the right thirty years. The next generation is not a better state machine or a prettier one. It is a system that can hold the second half of the sentence — what the commitment was made on — and that can therefore tell you, without anybody remembering to look, that something it is still calling Released no longer rests on anything.

---

White paper. PLMClub implements on Aras Innovator, including in air-gapped and multi-site estates. The counts in section 2 were run against a vendor-shipped Aras development configuration and are reproducible with the statements given. The mechanism in sections 4 and 5 is a proposal and a reading of established prior art, not a product: the staleness run described in section 9 has not been performed at scale — and that is stated rather than hidden. If you want the counts run on your own estate or the section 9 exercise designed so that it raises nothing and blocks nothing, get in touch.