The Same 60 HP Can Belong to Two Completely Different Lives
Mara and Eli both have 60 HP now.
If we look only at their character data, their conditions appear identical.
Both can still act.
Neither is dead.
Both have lost part of their maximum health.
But Mara’s 60 HP is the result of taking 40 damage in a single battle.
Her history is simple:
100
→ take 40 damage
→ 60
Eli’s 60 HP comes from a different history.
He was critically wounded in the ruins, reducing his health from 100 to 10. A companion used their last remaining medicine to restore 30 HP. After returning to camp, he received further treatment and recovered another 20.
His history is:
100
→ take 90 damage
→ 10
→ recover 30
→ 40
→ recover 20
→ 60
The final value is the same.
What the world carries forward is not.
Mara was injured once.
Eli came close to death.
Someone consumed a limited resource to save him.
Someone chose to remain with him in a dangerous place.
That injury may have prevented him from participating in later events. It may also have changed his relationship with the person who saved him.
If the treatment occurred at a different time, events that required him to have enough health along the way might have produced different results.
The 60 on a character sheet can tell us how much health each character has now.
It cannot tell us how that number was formed.
It cannot tell us which states they passed through before reaching 60.
Numbers tell us the result.
Causality gives the result a history.
An Attribute Is Not Profile Data; It Is State Changed by Events
Character attributes are easily treated as part of a character profile.
How much health does the character have?
How much magic remains?
How much stress have they accumulated?
Is their reputation positive or negative?
These fields usually display one current answer.
When a character takes damage, the author lowers their health.
When they rest or receive treatment, the author raises it again.
The character sheet may continue showing the correct current value.
But the changes that came before it have been overwritten.
The world knows that Eli currently has 60 HP.
It does not know that he once fell to 10.
It does not know which two treatments brought him back.
It also cannot tell whether an event between those treatments should encounter him at 10, 40, or the final 60.
World simulation cannot preserve only the latest number assigned to an attribute.
It needs to preserve:
What was the character’s initial value?
Which event increased it?
Which event reduced it?
Where did each change occur?
Did the resulting value remain within its permitted range?
Did it ever reach a boundary that changes the character’s life-and-death state?
In InkWeave, an attribute can have a default value.
Damage, healing, consumption, recovery, and accumulation can then become attribute events in the manuscript timeline.
The causality engine begins with the initial value and applies each increase or decrease in event order.
When the cursor is positioned before Eli is injured, he still has 100 HP.
After the injury but before the first treatment, he has only 10.
After the first treatment, the value becomes 40.
Only after the second treatment does the world display the final 60.
An attribute is not an answer attached to a character.
It is the numerical history the character has lived through.
Some Values Need Bounds; Others Need Room to Accumulate
Not every attribute should follow the same rules.
Health usually has a defined range.
It might run from 0 to 100.
When a character receives treatment, the value should not increase without limit beyond their maximum health.
When they take damage, the world should not keep subtracting indefinitely without confronting the consequences.
Magic, stamina, sanity, stress, and other limited resources may also require minimum and maximum values.
InkWeave can represent these attributes as bounded integers.
The creator can define a default value, minimum, and maximum, allowing the causality engine to check those boundaries as it replays events.
Other values may not need a fixed range.
Reputation may rise from a negative value without a universal maximum.
Debt may continue accumulating.
Merit, completed missions, cumulative failures, and records of corruption may not have an upper limit appropriate to every world.
These attributes can use unbounded cumulative values.
Unbounded does not mean unimportant.
It only means the world should not invent a boundary the creator never defined.
A character can have negative reputation.
They can carry debt far beyond what anyone originally expected.
The world only needs to preserve every confirmed increase and decrease.
A bounded attribute asks:
Where is this character within the permitted range?
An unbounded attribute asks:
How much has this character accumulated so far?
Both are numbers.
They describe different rules of the world.
When a Value Reaches a Boundary, It Stops Being Only Arithmetic
Suppose the minimum value for health is 0.
Eli has only 10 HP left, and the next attack deals 15 damage.
Ordinary arithmetic gives us -5.
For the story world, however, the question cannot end with a negative number.
Did the character die?
Did he become unable to act?
Did he fall unconscious?
Does this world have a rule that can save him from lethal damage?
What happens to the items he carries?
Can later events that require his participation still occur?
When certain values reach their boundaries, they begin affecting other parts of world state.
InkWeave therefore allows creators to mark a bounded attribute as lethal.
When a decrease would bring a lethal attribute to or below its minimum value, the system does not silently treat it as an ordinary numerical change.
During event creation, InkWeave can recognize that the change has reached a life-and-death boundary and allow the creator to address the character’s death.
Causality validation can also detect that a lethal attribute has reached its lower limit. This prevents the character from continuing to participate in later world events as though the value represented an ordinary condition.
Of course, reaching zero does not always mean death.
Zero MP may only mean the character can no longer cast spells.
Zero stamina may mean they need to rest.
A shield value reaching zero may only mean the protection has failed.
The creator decides whether an attribute has lethal meaning when defining it.
InkWeave does not impose the same rules of death on every world.
It allows the creator to state explicitly:
In this world, when this value reaches its boundary, it can no longer be treated as ordinary arithmetic.
When a Character Meets an Attribute, the World Checks the Current Value First
Writing about a character and an attribute in the same passage does not mean the attribute must immediately change.
“Mara felt the wound tear open again.”
This might mean her health decreases.
It might only describe pain.
“Eli finally felt like himself again.”
This might mean his stress decreases.
It might simply describe his mood and the rhythm of the scene.
“Almost none of his magic remained.”
The passage might require a new MP consumption event.
Or it might be describing the result of an earlier event that has already been recorded.
InkWeave does not increase or decrease a value merely because a character name and an attribute appear near each other.
When a character interacts with an attribute that applies to their current identity, the AVG experience can first ask the causality engine:
What is this character’s attribute value at this moment?
What are the minimum and maximum values?
Is this a lethal attribute?
Does this attribute apply to the character’s current identity?
The world brings the current state back into the writing environment first.
The author then decides whether this passage truly establishes an increase or decrease, and how much the value should change.
If the passage only describes the wound, the world does not need to change.
If the author confirms that the injury has worsened, the decrease enters the manuscript timeline.
If the change reaches a lethal threshold, the system can also warn the author during event creation that this is no longer a matter of losing only a few points.
This interaction does not calculate how painful the story ought to be.
It lets the author see which value they are about to change, and where that value actually stands, before they change the world.
The Inspector Shows the Result; History Shows How It Got There
When the cursor rests after Eli’s second treatment, the Inspector can show that his health is 60.
If the author only needs to continue writing the next action, that answer may be enough.
But when the value does not match expectations, another question becomes necessary:
Why is it 60?
InkWeave’s attribute history can list every relevant change.
Initial health: 100.
Critical injury in the ruins: minus 90.
Medicine used by a companion: plus 30.
Treatment after returning to camp: plus 20.
The author can inspect the history of one attribute or review every attribute change associated with the character.
Health, magic, stress, reputation, and other states no longer have to be reconstructed from scattered chapters and character notes.
History is not only there to help the author remember the story.
It also helps determine whether the current value has a valid source.
If Eli currently displays 60 HP, but his history contains only 90 damage and one recovery of 30, the value the world can actually derive is 40.
A manually entered 60 on a character sheet cannot replace the missing treatment event.
The character’s current state should be produced by changes the world has actually experienced.
The Inspector tells the author how much remains now.
History shows where every point was lost and where it returned.
Change an Earlier Value, and Every Later State Must Be Recalculated
Suppose the author returns to the ruins and decides that the original 90 damage was too severe.
They change the damage to 70.
Eli’s history now becomes:
100
→ take 70 damage
→ 30
→ recover 30
→ 60
→ recover 20
→ 80
The final result is no longer 60.
It is 80.
The author should not be able to change the earlier damage while the later Inspector continues displaying the old answer.
Likewise, if the first treatment event is removed, the value after the second treatment must also be recalculated.
If a recovery exceeds the maximum, the causality engine must handle that boundary according to the attribute’s definition.
If the revised damage reaches the lethal minimum, later movement, item transfers, and other events may begin losing their prerequisites.
This is the difference created when numbers become part of causality.
An earlier event is not old prose that has ceased to matter.
It remains the source of every value that follows.
Change the source, and the later answer cannot remain still.
InkWeave does not decide whether the damage should be 70 or 90.
It does not require the story to preserve its original outcome.
The author can revise any event.
The world then faithfully recalculates the consequences of that revision.
Creative freedom remains intact.
The arithmetic does not pretend to miss a new number merely to preserve an older draft.
This Is Not AI Deciding How Tired a Character Looks
When the manuscript says, “Mara could barely remain standing,” different readers may interpret her condition differently.
One may think she is merely tired.
Another may believe she is close to losing consciousness.
Someone else may read it as deliberate exaggeration.
InkWeave does not send that sentence to AI and ask it to decide how much stamina should be deducted.
It does not restore health simply because a character says, “I’m fine.”
The creator defines the numerical rules first.
Which attributes exist?
What are their default values?
Do they have minimum and maximum bounds?
Can they accumulate without fixed limits?
Does reaching the minimum trigger death?
The creator also confirms every actual increase and decrease.
InkWeave’s self-developed causality engine is responsible for something else:
It replays confirmed attribute events in manuscript order.
100 - 90 + 30 + 20 produces 60.
Given the same initial value, events, order, and rules, the result does not change because a system interprets the prose differently.
Within the explicitly modeled world, that result is mathematically guaranteed.
This guarantee covers only what has been modeled.
If the creator never defines a fatigue attribute, InkWeave does not invent a fatigue value.
If the manuscript describes treatment but the author does not confirm a recovery event, the number does not increase on its own.
InkWeave is not an AI editor estimating character condition from tone or wording.
It does not pretend to understand every piece of narration.
It guarantees that established numbers do not lose their arithmetic between events.
Real Life May Not Use HP, but It Still Needs Value Histories
Real life rarely expresses a person’s condition as HP or MP.
Real processes still contain many values that accumulate through events.
Training hours.
Completed assignments.
Cumulative work time.
Equipment usage.
Project contributions.
Merit.
Debt.
Any explicitly defined workload or measure of progress.
Some of these values have minimum and maximum limits.
Others can accumulate freely.
Some cause other conditions to become valid or invalid when they enter a particular range.
InkWeave is not a medical, payroll, or occupational safety system.
It does not decide what legal, medical, or managerial meaning a professional field should assign to a number.
But when a creator needs to simulate a clearly defined process, they can define the relevant attributes and change events themselves. The world can then present the correct result at different points in time.
A fictional world can use the same structure for values that do not exist in reality.
Magic.
Divinity.
Corruption.
Curse depth.
Faith.
Psychic erosion.
The world does not need to prove that magic exists in reality.
It needs to prove that, under its own fictional rules, magic that has been spent does not return by itself, unresolved corruption does not suddenly disappear, and health that has crossed a lethal threshold does not return to normal in the next chapter without a cause.
Real processes show us how precise numerical history sometimes needs to be.
Fictional worlds use that precision to support rules readers can believe.
A Character Carries More Than the Final Number
Mara has 60 HP.
Eli also has 60 HP.
If the world preserves only the latest data, they appear identical.
But the weight of a story often lies in the path taken before the final value was reached.
Who suffered the more severe injury?
Who came close to death?
Who consumed a limited resource?
Who accepted help?
Which recovery arrived too late?
Which later event actually occurred while the character was at their weakest?
Not every answer belongs inside an attribute field.
Some become relationships.
Some change items.
Others affect location, death, and future conditions.
Attribute history can at least tell the world that a character did not appear directly at the final number.
They were pushed there by one event after another.
InkWeave does not decide how much damage a character should endure.
It does not choose when the story should heal them, consume a resource, or cross a lethal threshold.
It allows every change the author has confirmed to keep counting as the manuscript moves forward.
A number tells us how much the character has left.
Causality tells us what they lost to reach it.