Markdown for LLMs

Separate the date of the norm from the date of the relation

The source Markdown for this article. Copy it into your assistant or download it as a text file.

# Separate the date of the norm from the date of the relation

## Intention

I want to apply a new duty only after the norm enters force and only to new issuances.

## Incorrect form and why it stays silent

An entry-into-force date only in window creates a position before the norm appears:

```text title="Incorrect form"
// у Report отсутствует effective
window [on, @2026-05-01];
```

## Correct form

```law
language "law.core" version "0.2";
package recipes.e.r04 version "0.1.0";
namespace "urn:recipe:e-time:04";

entity Person;
relation registered(p: Person);

relation received(p: Person, on: Date);
relation submitted(p: Person);
rule Report strict {
    effective [@2026-04-01, infinity);
    for p: Person; for on: Date;
    when received(p, on) and on >= @2026-04-01;
    then duty File {
        bearer p;
        goal achievement {
            condition submitted(p);
            window [on, @2026-05-01];
        }
    };
}
```

## Frozen execution scene

| Facts / cut | Question | Answer |
|---|---|---|
| legal_time 15.03, received 10.04 | application of Report | no |
| legal_time 15.04, received 01.03 | application of Report | no |
| legal_time 15.04, received 10.04 | File | ACTIVE |
| without effective: legal_time 15.03, received 10.04 | File | PENDING |

```law
test "pre-enactment bars application" {
    given {
        context {
            legal_time @2026-03-15;
            decision_time @2026-03-15T09:00:00+05:00;
            knowledge_time @2027-12-31T09:00:00+05:00;
            timezone "Asia/Almaty";
        }
        assert received(entity_ref("urn:recipe:e-time:04:a"), @2026-04-10);
    }
    evaluate positions();
    expect not applied(Report);
}
```

```law
test "old relation escapes new rule" {
    given {
        context {
            legal_time @2026-04-15;
            decision_time @2026-04-15T09:00:00+05:00;
            knowledge_time @2027-12-31T09:00:00+05:00;
            timezone "Asia/Almaty";
        }
        assert received(entity_ref("urn:recipe:e-time:04:a"), @2026-03-01);
    }
    evaluate positions();
    expect not applied(Report);
}
```

```law
test "new relation activates duty" {
    given {
        context {
            legal_time @2026-04-15;
            decision_time @2026-04-15T09:00:00+05:00;
            knowledge_time @2027-12-31T09:00:00+05:00;
            timezone "Asia/Almaty";
        }
        assert received(entity_ref("urn:recipe:e-time:04:a"), @2026-04-10);
    }
    evaluate positions();
    expect position(File, ACTIVE);
}
```

```law
test "early position stays pending" {
    given {
        context {
            legal_time @2026-03-15;
            decision_time @2026-03-15T09:00:00+05:00;
            knowledge_time @2027-12-31T09:00:00+05:00;
            timezone "Asia/Almaty";
        }
        assert received(entity_ref("urn:recipe:e-time:04:a"), @2026-04-10);
    }
    evaluate positions();
    expect position(File, PENDING);
}
```

## Counterfactual

runs.without drops effective and shows a premature position. teaches duplicates effective: E1329. The condition on >= cutoff separately limits old events.

## Boundary

effective reads the date of the law; the comparison reads the date of the relation. Both are needed; the goal window names the performance term. The claim “effective for relations after a date” is wrong without this split.

## Pitfall

Before entry into force the result was PENDING, then a retroactive violation followed. The fix is effective and a separate issuance-date guard. The as-of moment for statuses is the decision time (entry into force still reads the law date); every scene names its decision date explicitly.