@operato/twin-kernel 0.7.54 → 0.7.56

package/dist/contract.d.ts

@@ -415,12 +415,48 @@ export interface TestSpecificationCriterion {
     /** 표준 `Sequence` — 기준이 여럿일 때의 순서. */
     sequence?: number;
     /**
-     * 표준 `Expression`(`TextType`) — **그 현장의 표기 그대로** 나른다. 커널은 평가하지 않는다.
+     * 표준 `Expression`(`TextType`) — **그 현장의 표기 그대로** 나른다. 커널은 이것을 평가하지 않는다.
      *
-     * 표준에서는 선택이지만 **우리는 요구한다**(좁힘): 표현식이 없는 기준은 아무 한계도 말하지 않으므로
-     * 「기준이 선언됐다」는 착각만 만든다. 선언만 있고 내용이 없는 것을 이 저장소는 거절한다.
+     * 문법이 정의돼 있지 않으므로(자유 문자열) 파싱하면 그 순간 방언이고, 현장 규정과 우리 해석이
+     * 갈리는 날 어느 쪽이 옳은지 아무도 모른다. 사람이 읽는 값이다.
+     *
+     * **`expression` 과 `limit` 중 적어도 하나는 있어야 한다**(§`criterionSaysNothing`) — 둘 다 없는
+     * 기준은 아무 한계도 말하지 않으면서 「기준이 선언됐다」는 착각만 만든다.
      */
-    expression: string;
+    expression?: string;
+    /**
+     * **평가 가능한 한계** — 이것이 있으면 커널이 판정할 수 있다.
+     *
+     * ── 이 축은 **표준에 없다. 우리 것이다** (2026-08-24) ──────────────────────
+     * B2MML 일곱 파일(Common · OperationsTest · OperationsPerformance(+Types) · OperationalLocation ·
+     * OperationsEvent · OperationsSchedule · WorkAlert)을 원문으로 훑었고 `Minimum`·`Maximum`·
+     * `Tolerance`·`Range`·`LowerLimit`·`UpperLimit` 이 **하나도 없다.** ISA-95 의 기준은
+     * `Expression`(TextType)과 `Result`(TextType)뿐이고, `ValueType` 도 `ValueString`·`DataType`·
+     * `UnitOfMeasure`·`Key` 넷이다. 즉 표준은 한계를 **사람이 읽는 문장**으로만 담는다.
+     *
+     * 그런데 트윈은 **아무도 판정하지 않을 때 판정해야 한다** — 그것이 이 축의 근거다(당위). 자유 문장
+     * 으로는 그것을 할 수 없다. 그래서 숫자 한계를 우리가 더한다. **더한 것이라고 적어 두는 것**이
+     * 이 저장소의 규율이고(§`TestResult.result` 의 좁힘과 같은 자리), 그러면 다음 사람이 이것을
+     * 「표준이 준 이름」으로 읽지 않는다.
+     *
+     * 이 모양으로 한계를 주는 실 원본이 있다는 것도 확인했다. **그것이 이 축을 정한 것은 아니다** —
+     * 판정이 필요하다는 당위가 정했고, 원본은 그것을 채울 수 있다는 사실을 확인해 준 것이다.
+     * 어느 배포가 무엇을 주는지는 **커널이 알 일이 아니므로 여기 적지 않는다**(연동 쪽 문서의 몫이다).
+     */
+    limit?: {
+        /** 이 값 미만이면 벗어난다. 없으면 아래쪽 한계가 없다(모르는 것이 아니라 없는 것이다). */
+        minimum?: number;
+        /** 이 값 초과면 벗어난다. */
+        maximum?: number;
+        /**
+         * 한계의 단위 — 표준 `UnitOfMeasure` 와 같은 어휘(UN/CEFACT).
+         *
+         * **없으면 짐작하지 않는다.** 관측도 단위를 말하지 않으면 같은 척도로 보고 비교하고(같은 선언에서
+         * 온 값들이다), **둘이 서로 다른 단위를 말하면 판정하지 않는다** — 섭씨 한계에 화씨 관측을
+         * 견주면 조용히 틀린다.
+         */
+        uom?: string;
+    };
     /** 표준 `Result` — 이 기준이 만족될 때 기대하는 값(현장 표기). */
     result?: string;
     /** 표준 `EvaluatedPropertyID` — 이 기준이 **무엇을 재어** 판정하나. 측정값과 짝을 맞추는 키다. */
@@ -465,6 +501,34 @@ export interface PropertyMeasurement extends StandardValue {
      */
     derived?: boolean;
 }
+/**
+ * **이 기준이 아무 한계도 말하지 않나** — 선언만 있고 내용이 없는 것을 가려낸다.
+ *
+ * 표현식(사람이 읽는 것)도 없고 숫자 한계(커널이 판정하는 것)도 없으면, 그 기준은 「기준이 선언됐다」는
+ * 착각만 만든다. 화면이 「관리점 셋이 걸려 있다」고 말하는데 그중 하나가 아무것도 재지 않는 것은
+ * 이 저장소가 거절하는 모양이다.
+ */
+export declare function criterionSaysNothing(c: Pick<TestSpecificationCriterion, 'expression' | 'limit'>): boolean;
+/**
+ * **이 값이 한계를 벗어났나** — 판정할 수 있을 때만 답한다.
+ *
+ * ── 세 갈래를 가린다 ────────────────────────────────────────────────────────
+ *   `true`       벗어났다
+ *   `false`      한계 안이다
+ *   `undefined`  **판정할 수 없다** — 숫자 한계가 없거나, 값이 수가 아니거나, 단위가 어긋난다
+ *
+ * `undefined` 를 `false` 로 뭉개지 않는 것이 이 함수의 요점이다. 「한계 안이다」와 「판정 못 했다」를
+ * 같은 값으로 답하면 화면이 판정하지 못한 것을 **적합으로** 보여 준다 — 규제 기록에서 그것은 사고다.
+ *
+ * ── 표현식은 읽지 않는다 ────────────────────────────────────────────────────
+ * `expression` 이 있어도 파싱하지 않는다(§`TestSpecificationCriterion.expression`). 숫자 한계가
+ * 없으면 사람이 읽을 문장은 있어도 커널은 「모른다」고 답한다.
+ *
+ * ── 단위가 어긋나면 판정하지 않는다 ─────────────────────────────────────────
+ * 섭씨 한계에 화씨 관측을 견주면 **오류 없이 틀린다.** 둘 다 단위를 말하지 않으면 같은 척도로 본다 —
+ * 같은 선언에서 온 값들이고, 그때 판정을 거부하면 단위를 적지 않는 원본에서 이 축이 영원히 침묵한다.
+ */
+export declare function outsideLimit(criterion: Pick<TestSpecificationCriterion, 'limit'> | undefined, observed: Pick<StandardValue, 'value' | 'uom'> | undefined): boolean | undefined;
 /**
  * **이 판정에 근거가 있나** — 기준과 측정값의 짝을 맞춰 빈 곳을 돌려준다.
  *
@@ -944,7 +1008,105 @@ export interface LocationState {
      * 보드에 좌표가 없고 용량이 비어 있어 **계획에 참여하지 못한다**(그 사실을 감추지 않기 위한 표시).
      */
     origin?: 'master' | 'observed';
+    /**
+     * 이 자리에서 관측된 **물리량들의 마지막 값** — 속성마다 하나(§`LocationObservation`).
+     *
+     * 이력이 아니라 **지금 값**이다: 이력은 저널이 든다(그것이 「그때 그 방이 몇 도였나」에 답하는
+     * 자리다). 여기 두는 이유는 판정이 지금 값을 보기 때문이고, 상태가 시간에 비례해 자라지 않게
+     * **속성당 하나**만 든다.
+     *
+     * 없으면 **두지 않는다** — 빈 배열을 두면 「센서가 없는 자리」와 「아직 못 들은 자리」가 같아진다.
+     */
+    observations?: LocationObservation[];
 }
+/**
+ * **자리에서 관측된 물리량 하나** — 냉장실 온도·습도, 세척수 유량 같은 것.
+ *
+ * ── 왜 트윈이 이것을 들어야 하나 (당위) ─────────────────────────────────────
+ * 트윈의 판정 대상은 「물건의 상태」이고, 물건의 상태는 **조건 없이 정해지지 않는다.** 「이 로트가
+ * 냉장실에 있었다」까지만 아는 트윈은 그 로트가 괜찮았는지 말할 수 없다 — 기능 하나가 없는 것이
+ * 아니라 **판정의 재료가 없는 것**이다.
+ *
+ * 그리고 **이 조인은 트윈만 할 수 있다.** 계측 시스템은 물건의 자리 이력을 모르고, 물류 시스템은
+ * 조건 이력을 모른다. 물건이 여러 시스템을 지나면 어느 원본도 전 경로를 모른다.
+ *
+ * ── 주인은 **자리**다. 물건이 아니다 ────────────────────────────────────────
+ * 방 하나의 온도가 그 안의 물건 수백 개와 관계되고, **그 수백 개는 시간에 따라 바뀐다.** 값을 물건마다
+ * 복사하면 한 사실의 사본이 수백 개 생기고 드나드는 물건마다 어긋난다. 그래서 관측은 **자리에 한 번**
+ * 두고, 「그때 그 방에 있던 물건」은 시각∩자리로 파생한다(파생은 저장하지 않는다).
+ *
+ * 진행 중인 공정이 있어도 마찬가지다: 숙성창고에 로트가 여럿이면 숙성 작업도 여럿이고 구간이 각기
+ * 다른데 **센서는 하나**다. 그 값은 어느 한 작업의 것이 아니다.
+ *
+ * ── 표준 근거 — 붙는 자리가 「자리」가 아니라 **설비 계층 노드**다 ────────────
+ * 1차 출처: `OperationsEventType`(`B2MML-OperationsEvent.xsd`) + `OperationsRecordTemplateType`
+ * (`B2MML-Common.xsd`). 붙는 자리는 `HierarchyScope.EquipmentID` 인데, ISA-95 에서는 **장소 계층이
+ * 곧 설비 계층**이다(Enterprise → Site → Area → StorageZone → StorageUnit) — 냉장실은 `StorageZone`
+ * 수준의 설비다. 커널의 자리가 그 노드이므로(§`LocationState.level` 이 `EquipmentLevel1Type` 근거)
+ * `locationId` 가 그대로 대응된다.
+ *
+ * `OperationalLocationType` 에는 이 축이 **없다** — 그쪽은 나중에 들어온 공간(spatial) 개념이고
+ * 마스터 속성만 든다(시계열이 아니다).
+ *
+ * ── 우리가 좁힌 것 ──────────────────────────────────────────────────────────
+ * 표준의 기록 항목은 `InformationObject`(무엇이든)다. **그 임의성을 쓰지 않는다** — 값을 `ValueType`
+ * 으로 좁힌다(§`StandardValue`). 단위 없는 물리량을 받으면 소비처가 3이 섭씨인지 화씨인지 알 수 없고,
+ * 그 상태로는 어떤 판정도 못 한다.
+ */
+export interface LocationObservation extends StandardValue {
+    /** 표준 `HierarchyScope.EquipmentID` — 어느 자리인가. 커널의 자리 id 다. */
+    locationId: string;
+    /**
+     * **무엇을 쟀나** — 속성 식별자. 기준과 짝을 맞추는 키다
+     * (§`TestSpecificationCriterion.evaluatedPropertyId`).
+     *
+     * 어휘는 커널이 정하지 않는다 — 재는 것은 현장이 정한다(온도·습도·유량·중량). 커널은 나르고
+     * 짝만 맞춘다. `OP_PARAM` 과 같은 규율이고, 표준도 파라미터 ID 어휘를 정하지 않는다.
+     */
+    propertyId: string;
+    /**
+     * **언제의 사실인가** — 표준 `EffectiveTimestamp`.
+     *
+     * 관측 시각이지 기록 시각이 아니다. 둘이 어긋나는 것이 실 연동의 정상이고, 그래서 아래를 따로 든다.
+     */
+    effectiveTime: ISOTime;
+    /**
+     * **언제까지의 사실인가** — 표준 `EffectiveEndDate`. 없으면 그 시점 하나의 값이다.
+     *
+     * ── 왜 구간이 필요한가 ────────────────────────────────────────────────────
+     * ① **원본이 시각을 주지 않는 기록이 있다.** 수동 점검 장부는 「그날 아침」처럼 적고 시계를 적지
+     *    않는다(표준도 주기 점검을 전제한다 — `RecurrenceTimeInterval`). 그때 09:00 을 찍으면 **자정을
+     *    지어내는 것과 같은 발명**이다(§ADR-0039 「선언이 있으면 변환이지만 없으면 발명이다」).
+     *    구간으로 적으면 참인 것만 말한다: 그날 아침의 어느 때.
+     * ② **영향 로트를 찾는 데 구간이 필요하다.** 점 하나로는 며칠 머문 로트를 잡지 못한다 — 온도가 튄
+     *    한 시간의 이벤트 목록에는 정작 그 방의 로트가 하나도 없을 수 있다.
+     *
+     * 구간을 **모르는 것**과 **점인 것**은 다르다: 점이면 이 값이 없고, 모르면 넓은 구간으로 적는다.
+     */
+    effectiveEndTime?: ISOTime;
+    /** 언제 적혔나 — 표준 `RecordTimestamp`. 늦게 도착한 옛 관측이 최신을 덮지 않게 하는 재료다. */
+    recordTime?: ISOTime;
+    /** 누가 말했나 — 표준 `Source`. 계측기인지 사람이 적은 장부인지는 이 값이 답한다. */
+    source?: string;
+    /**
+     * 이 값이 **잰 것이 아니라 접은 것**임을 밝힌다 — §`PropertyMeasurement.derived` 와 같은 규율.
+     *
+     * 트윈은 원본이 주지 않는 값을 계산할 수 있다(그것이 존재 이유다). 그러나 실측과 같은 자리에 같은
+     * 모양으로 두면 보고서가 그것을 잰 값으로 읽는다. 규제 기록에서 그 구별이 사라지는 것은 결함이
+     * 아니라 사고다.
+     */
+    derived?: boolean;
+}
+/**
+ * **이 시각에 이 자리에서 참인 관측** — 구간을 든 관측을 시각으로 찾는다.
+ *
+ * 「그때 그 방이 몇 도였나」에 답하는 첫 칸이다. 점 관측은 그 시각에만, 구간 관측은 구간 안에서 참이다.
+ * 여러 개가 겹치면 **가장 늦게 시작한 것**이 답이다(정정이 나중에 온다).
+ *
+ * 커널은 값이 옳은지 **판정하지 않는다** — 기준의 표현식은 문법이 정의되지 않은 자유 문자열이다
+ * (§`TestSpecificationCriterion`). 여기서 하는 일은 짝을 찾아 주는 것까지다.
+ */
+export declare function observationAt(observations: readonly LocationObservation[] | undefined, propertyId: string, at: ISOTime): LocationObservation | undefined;
 /**
  * 물품 상태 — 표준이 담는 것을 담는다(EPCIS 2.0 / TDS).
  *
@@ -1908,6 +2070,18 @@ export declare const OP_EVENT: {
      * 과거를 다시 계산해도 그때 무엇을 확인했는지 알 수 없다 — 저널이 현실을 불완전하게 담는 자리였다.
      */
     readonly attentionAck: "attention.acked";
+    /**
+     * **자리에서 관측된 물리량** — 냉장실 온도·습도, 세척수 유량 같은 것(§`LocationObservation`).
+     *
+     * ── 왜 채널이 필요한가 ────────────────────────────────────────────────────
+     * `LocationState.observations` 를 상태에 두었는데 그것을 낳는 사건이 없었다. 그러면 **상태 ⊆ 이벤트**
+     * 가 깨진다: 채워도 재기동에서 사라지고, 폴드가 되살릴 수 없고, 미러가 이어받을 수도 없다. 상태에만
+     * 있는 축은 조용히 사라지는 축이다.
+     *
+     * 이름을 `energy.measured` 와 같은 결로 둔다 — 그쪽이 에너지 계량의 도착이고 이쪽이 그 일반형이다.
+     * 두 채널을 합치지 않는 이유는 에너지 쪽이 **구간에 누적되는 표본**이라 처리가 다르기 때문이다.
+     */
+    readonly observation: "location.measured";
 };
 /**
  * 에너지 트윈의 사건 — **물(物)의 계보가 아니라 스칼라의 시계열.**
@@ -2246,6 +2420,7 @@ export interface TwinModelDef {
         parallelism?: number;
         parentId?: string;
         properties?: ResourceProperty[];
+        testSpecificationIds?: TestSpecificationRefs;
     }[];
     /**
      * 설비(설비). mtbfMs/mttrMs 지정 시 확률적 고장 모델 참여(OEE Availability 손실). 미지정=고장 없음.

package/dist/contract.js

@@ -245,6 +245,63 @@ export function meetsTests(required, results, at) {
     }
     return true;
 }
+/**
+ * **이 기준이 아무 한계도 말하지 않나** — 선언만 있고 내용이 없는 것을 가려낸다.
+ *
+ * 표현식(사람이 읽는 것)도 없고 숫자 한계(커널이 판정하는 것)도 없으면, 그 기준은 「기준이 선언됐다」는
+ * 착각만 만든다. 화면이 「관리점 셋이 걸려 있다」고 말하는데 그중 하나가 아무것도 재지 않는 것은
+ * 이 저장소가 거절하는 모양이다.
+ */
+export function criterionSaysNothing(c) {
+    if (c?.expression?.trim())
+        return false;
+    const l = c?.limit;
+    return !(typeof l?.minimum === 'number' || typeof l?.maximum === 'number');
+}
+/**
+ * **이 값이 한계를 벗어났나** — 판정할 수 있을 때만 답한다.
+ *
+ * ── 세 갈래를 가린다 ────────────────────────────────────────────────────────
+ *   `true`       벗어났다
+ *   `false`      한계 안이다
+ *   `undefined`  **판정할 수 없다** — 숫자 한계가 없거나, 값이 수가 아니거나, 단위가 어긋난다
+ *
+ * `undefined` 를 `false` 로 뭉개지 않는 것이 이 함수의 요점이다. 「한계 안이다」와 「판정 못 했다」를
+ * 같은 값으로 답하면 화면이 판정하지 못한 것을 **적합으로** 보여 준다 — 규제 기록에서 그것은 사고다.
+ *
+ * ── 표현식은 읽지 않는다 ────────────────────────────────────────────────────
+ * `expression` 이 있어도 파싱하지 않는다(§`TestSpecificationCriterion.expression`). 숫자 한계가
+ * 없으면 사람이 읽을 문장은 있어도 커널은 「모른다」고 답한다.
+ *
+ * ── 단위가 어긋나면 판정하지 않는다 ─────────────────────────────────────────
+ * 섭씨 한계에 화씨 관측을 견주면 **오류 없이 틀린다.** 둘 다 단위를 말하지 않으면 같은 척도로 본다 —
+ * 같은 선언에서 온 값들이고, 그때 판정을 거부하면 단위를 적지 않는 원본에서 이 축이 영원히 침묵한다.
+ */
+export function outsideLimit(criterion, observed) {
+    const l = criterion?.limit;
+    if (!l)
+        return undefined;
+    const hasMin = typeof l.minimum === 'number';
+    const hasMax = typeof l.maximum === 'number';
+    if (!hasMin && !hasMax)
+        return undefined;
+    const raw = observed?.value;
+    if (raw === undefined || raw === null || String(raw).trim() === '')
+        return undefined;
+    const n = Number(raw);
+    if (!Number.isFinite(n))
+        return undefined;
+    /* 단위가 **둘 다 있고 다르면** 판정하지 않는다. 하나만 있거나 둘 다 없으면 같은 척도로 본다. */
+    const lu = l.uom?.trim();
+    const ou = observed?.uom?.trim();
+    if (lu && ou && lu !== ou)
+        return undefined;
+    if (hasMin && n < l.minimum)
+        return true;
+    if (hasMax && n > l.maximum)
+        return true;
+    return false;
+}
 /**
  * **이 판정에 근거가 있나** — 기준과 측정값의 짝을 맞춰 빈 곳을 돌려준다.
  *
@@ -782,6 +839,40 @@ export function capabilityOf(r, ctx) {
         return { available: false, reason: 'working' };
     return { available: true, reason: 'available' };
 }
+/**
+ * **이 시각에 이 자리에서 참인 관측** — 구간을 든 관측을 시각으로 찾는다.
+ *
+ * 「그때 그 방이 몇 도였나」에 답하는 첫 칸이다. 점 관측은 그 시각에만, 구간 관측은 구간 안에서 참이다.
+ * 여러 개가 겹치면 **가장 늦게 시작한 것**이 답이다(정정이 나중에 온다).
+ *
+ * 커널은 값이 옳은지 **판정하지 않는다** — 기준의 표현식은 문법이 정의되지 않은 자유 문자열이다
+ * (§`TestSpecificationCriterion`). 여기서 하는 일은 짝을 찾아 주는 것까지다.
+ */
+export function observationAt(observations, propertyId, at) {
+    const t = parsedMs(at);
+    if (!(t >= 0))
+        return undefined;
+    let best;
+    let bestStart = -1;
+    for (const o of observations ?? []) {
+        if (o.propertyId !== propertyId)
+            continue;
+        const from = parsedMs(o.effectiveTime);
+        if (!(from >= 0) || from > t)
+            continue;
+        /* 구간이 있으면 그 안이어야 한다. 없으면 그 시점의 값이고, 그 뒤로도 정정될 때까지 유효하다. */
+        if (o.effectiveEndTime) {
+            const to = parsedMs(o.effectiveEndTime);
+            if (to >= 0 && to < t)
+                continue;
+        }
+        if (from > bestStart) {
+            best = o;
+            bestStart = from;
+        }
+    }
+    return best;
+}
 // ── 운영 델타(비-EPCIS) — State 채널의 나머지 절반 ──────────────────────────
 // EPCIS 이벤트는 재고/위치만 재구성 가능. tasks·equipment·orders 의 운영 상태는
 // 이 델타로 미러한다. envelope.eventType = 'task.status' | 'equipment.status' | 'order.status'.
@@ -807,7 +898,19 @@ export const OP_EVENT = {
      * "확인해라"(요청)이고 이벤트는 "확인했다"(사실)다. 같은 문자열을 쓰면 저널에서 요청과 사실이
      * 구별되지 않는다.
      */
-    attentionAck: 'attention.acked'
+    attentionAck: 'attention.acked',
+    /**
+     * **자리에서 관측된 물리량** — 냉장실 온도·습도, 세척수 유량 같은 것(§`LocationObservation`).
+     *
+     * ── 왜 채널이 필요한가 ────────────────────────────────────────────────────
+     * `LocationState.observations` 를 상태에 두었는데 그것을 낳는 사건이 없었다. 그러면 **상태 ⊆ 이벤트**
+     * 가 깨진다: 채워도 재기동에서 사라지고, 폴드가 되살릴 수 없고, 미러가 이어받을 수도 없다. 상태에만
+     * 있는 축은 조용히 사라지는 축이다.
+     *
+     * 이름을 `energy.measured` 와 같은 결로 둔다 — 그쪽이 에너지 계량의 도착이고 이쪽이 그 일반형이다.
+     * 두 채널을 합치지 않는 이유는 에너지 쪽이 **구간에 누적되는 표본**이라 처리가 다르기 때문이다.
+     */
+    observation: 'location.measured'
 };
 // ── 에너지(EMS) 사건 — 네 번째 종류의 어휘 ────────────────────────────────
 /**

package/dist/epcis.d.ts

@@ -8,6 +8,58 @@ export declare const DISP: {
     readonly reserved: "urn:epcglobal:cbv:disp:reserved";
     readonly in_transit: "urn:epcglobal:cbv:disp:in_transit";
     readonly non_sellable: "urn:epcglobal:cbv:disp:non_sellable_other";
+    /**
+     * **기한이 지났다** — CBV `expired`.
+     *
+     * ── 왜 `non_sellable` 로 접지 않나 (2026-08-24) ─────────────────────────────
+     * 커널의 `non_sellable` 은 CBV 의 `non_sellable_other`, 즉 **「그 밖의 이유」**다. 기한 지남을 거기
+     * 넣으면 「기한이 지나 못 판다」와 「깨져서 못 판다」가 같은 값이 되고, 화면은 회수·폐기의 사유를
+     * 구별할 수 없다. 식품에서 그 둘은 다른 조치다.
+     *
+     * 그리고 표준에 **정확한 낱말이 있다** — 접는 것은 있는 낱말을 버리는 것이다.
+     *
+     * ── 기한 날짜와 다른 축이다 ────────────────────────────────────────────────
+     * `ItemState.expiry` 는 **날짜**이고 이것은 **상태**다. 날짜가 있으면 「지났나」는 파생이지만, 원본이
+     * 「기한 지남」을 상태로 선언하는 시스템이 있다 — 그때 이 값은 관측이다.
+     *
+     * 둘이 어긋나면(날짜는 남았는데 상태가 지남, 또는 그 반대) **어느 쪽이 맞다고 정하지 않는다** —
+     * 아직 그 판정을 세울 근거가 없다. 어긋남의 구분을 없애지 않는 것이 지금의 규율이다.
+     *
+     * ── 원문으로 확인했다 (2026-08-24) ────────────────────────────────────────
+     * 1차 출처: **CBV Standard Release 2.0, Ratified Jun 2022** §7.2.3 처분 값 표(38개). 이 객체의
+     * 다른 값들(`in_progress`·`sellable_accessible`·`reserved`·`in_transit`·`non_sellable_other`)도
+     * 그 표에 있다.
+     *
+     * **`non_sellable_expired` 를 쓰지 않는 이유**: 그 값은 CBV 1.0 의 것이고 표준이 **폐기**했다 —
+     * 「deprecated in favour of new disposition values expired, damaged, disposed, … introduced in
+     * CBV 1.1」. 폐기된 값을 쓰면 새 소비처가 읽지 못한다.
+     *
+     * 참고: GS1 어휘 등록처(`ref.gs1.org/cbv/…`)로는 확인할 수 없었다 — **없는 값에도 같은 응답**을
+     * 준다(지어낸 값의 JSON-LD 가 실재 값과 바이트까지 같았다). 그 경로를 근거로 삼지 말 것.
+     */
+    readonly expired: "urn:epcglobal:cbv:disp:expired";
+    /**
+     * **검사에 합격했다 / 불합격했다** — CBV `conformant` / `non_conformant`.
+     *
+     * 1차 출처(CBV 2.0 §7.2.3) 정의 그대로다.
+     *
+     *   conformant       Outcome of a successful/passed inspection in an inspecting or repairing step
+     *   non_conformant   Outcome of an unsuccessful/failed inspection in an inspecting or repairing step
+     *
+     * ── 왜 시험 결과 축을 자원에 더하지 않고 이것을 쓰나 (2026-08-24) ────────────
+     * 로트의 검사 판정을 담을 자리를 찾다가 `ItemState.testResults` 를 더하려 했다. 그런데 표준은 그
+     * 사실을 **이미 처분으로 말한다**: `bizStep: inspecting` 사건에 이 처분이 붙는다.
+     *
+     * 처분을 쓰면 두 가지가 공짜로 성립한다.
+     *   ① **상태 ⊆ 이벤트** — 처분은 이미 사건에서 온다. 상태에만 있는 축을 만들지 않는다
+     *   ② **운영에 곧 닿는다** — 「이 자재를 쓸 수 있나」가 처분으로 답해진다(판정을 따로 읽지 않는다)
+     *
+     * 시험의 **자세한 내용**(어느 명세로, 무엇을 재어)은 다른 물음이고, 표준은 그것을 `TestResult` 로
+     * 두며 결과가 대상을 가리킨다(`TestableObjectID`) — 대상이 결과를 들지 않는다. 그 축이 필요해지면
+     * 그때 열되, **판정 자체는 여기서 끝난다.**
+     */
+    readonly conformant: "urn:epcglobal:cbv:disp:conformant";
+    readonly non_conformant: "urn:epcglobal:cbv:disp:non_conformant";
 };
 /**
  * **자재 소비·산출의 CBV 단계** — 도메인 무관하게 코어가 쓴다.
@@ -20,6 +72,15 @@ export declare const CBV_BIZSTEP: {
     readonly consuming: "urn:epcglobal:cbv:bizstep:consuming";
     /** 새 물품이 생겨 계보가 시작된다 — ISA-95 `MaterialUse: Produced`. */
     readonly commissioning: "urn:epcglobal:cbv:bizstep:commissioning";
+    /**
+     * **검사** — CBV `inspecting`. 1차 출처(CBV 2.0) 정의: 「Process of reviewing objects to address
+     * potential physical or documentation defects」이고, 「표본과 달리 검사된 대상은 그대로 남는다」고
+     * 이어진다(즉 검사는 물건을 소비하지 않는다).
+     *
+     * 이 단계에 `DISP.conformant`/`DISP.non_conformant` 가 붙어 판정이 처분으로 남는다 — 입고검수·
+     * 공정 중 검사가 그 모양이다.
+     */
+    readonly inspecting: "urn:epcglobal:cbv:bizstep:inspecting";
 };
 export type EpcisEventType = 'ObjectEvent' | 'AggregationEvent' | 'TransactionEvent' | 'TransformationEvent';
 export type EpcisAction = 'ADD' | 'OBSERVE' | 'DELETE';

package/dist/epcis.js

@@ -16,7 +16,59 @@ export const DISP = {
     sellable: 'urn:epcglobal:cbv:disp:sellable_accessible',
     reserved: 'urn:epcglobal:cbv:disp:reserved',
     in_transit: 'urn:epcglobal:cbv:disp:in_transit',
-    non_sellable: 'urn:epcglobal:cbv:disp:non_sellable_other' // 불량/scrap
+    non_sellable: 'urn:epcglobal:cbv:disp:non_sellable_other', // 불량/scrap
+    /**
+     * **기한이 지났다** — CBV `expired`.
+     *
+     * ── 왜 `non_sellable` 로 접지 않나 (2026-08-24) ─────────────────────────────
+     * 커널의 `non_sellable` 은 CBV 의 `non_sellable_other`, 즉 **「그 밖의 이유」**다. 기한 지남을 거기
+     * 넣으면 「기한이 지나 못 판다」와 「깨져서 못 판다」가 같은 값이 되고, 화면은 회수·폐기의 사유를
+     * 구별할 수 없다. 식품에서 그 둘은 다른 조치다.
+     *
+     * 그리고 표준에 **정확한 낱말이 있다** — 접는 것은 있는 낱말을 버리는 것이다.
+     *
+     * ── 기한 날짜와 다른 축이다 ────────────────────────────────────────────────
+     * `ItemState.expiry` 는 **날짜**이고 이것은 **상태**다. 날짜가 있으면 「지났나」는 파생이지만, 원본이
+     * 「기한 지남」을 상태로 선언하는 시스템이 있다 — 그때 이 값은 관측이다.
+     *
+     * 둘이 어긋나면(날짜는 남았는데 상태가 지남, 또는 그 반대) **어느 쪽이 맞다고 정하지 않는다** —
+     * 아직 그 판정을 세울 근거가 없다. 어긋남의 구분을 없애지 않는 것이 지금의 규율이다.
+     *
+     * ── 원문으로 확인했다 (2026-08-24) ────────────────────────────────────────
+     * 1차 출처: **CBV Standard Release 2.0, Ratified Jun 2022** §7.2.3 처분 값 표(38개). 이 객체의
+     * 다른 값들(`in_progress`·`sellable_accessible`·`reserved`·`in_transit`·`non_sellable_other`)도
+     * 그 표에 있다.
+     *
+     * **`non_sellable_expired` 를 쓰지 않는 이유**: 그 값은 CBV 1.0 의 것이고 표준이 **폐기**했다 —
+     * 「deprecated in favour of new disposition values expired, damaged, disposed, … introduced in
+     * CBV 1.1」. 폐기된 값을 쓰면 새 소비처가 읽지 못한다.
+     *
+     * 참고: GS1 어휘 등록처(`ref.gs1.org/cbv/…`)로는 확인할 수 없었다 — **없는 값에도 같은 응답**을
+     * 준다(지어낸 값의 JSON-LD 가 실재 값과 바이트까지 같았다). 그 경로를 근거로 삼지 말 것.
+     */
+    expired: 'urn:epcglobal:cbv:disp:expired',
+    /**
+     * **검사에 합격했다 / 불합격했다** — CBV `conformant` / `non_conformant`.
+     *
+     * 1차 출처(CBV 2.0 §7.2.3) 정의 그대로다.
+     *
+     *   conformant       Outcome of a successful/passed inspection in an inspecting or repairing step
+     *   non_conformant   Outcome of an unsuccessful/failed inspection in an inspecting or repairing step
+     *
+     * ── 왜 시험 결과 축을 자원에 더하지 않고 이것을 쓰나 (2026-08-24) ────────────
+     * 로트의 검사 판정을 담을 자리를 찾다가 `ItemState.testResults` 를 더하려 했다. 그런데 표준은 그
+     * 사실을 **이미 처분으로 말한다**: `bizStep: inspecting` 사건에 이 처분이 붙는다.
+     *
+     * 처분을 쓰면 두 가지가 공짜로 성립한다.
+     *   ① **상태 ⊆ 이벤트** — 처분은 이미 사건에서 온다. 상태에만 있는 축을 만들지 않는다
+     *   ② **운영에 곧 닿는다** — 「이 자재를 쓸 수 있나」가 처분으로 답해진다(판정을 따로 읽지 않는다)
+     *
+     * 시험의 **자세한 내용**(어느 명세로, 무엇을 재어)은 다른 물음이고, 표준은 그것을 `TestResult` 로
+     * 두며 결과가 대상을 가리킨다(`TestableObjectID`) — 대상이 결과를 들지 않는다. 그 축이 필요해지면
+     * 그때 열되, **판정 자체는 여기서 끝난다.**
+     */
+    conformant: 'urn:epcglobal:cbv:disp:conformant',
+    non_conformant: 'urn:epcglobal:cbv:disp:non_conformant'
 };
 /**
  * **자재 소비·산출의 CBV 단계** — 도메인 무관하게 코어가 쓴다.
@@ -28,7 +80,16 @@ export const CBV_BIZSTEP = {
     /** 공정에 자재가 들어갔다 — ISA-95 `MaterialUse: Consumed`. */
     consuming: 'urn:epcglobal:cbv:bizstep:consuming',
     /** 새 물품이 생겨 계보가 시작된다 — ISA-95 `MaterialUse: Produced`. */
-    commissioning: 'urn:epcglobal:cbv:bizstep:commissioning'
+    commissioning: 'urn:epcglobal:cbv:bizstep:commissioning',
+    /**
+     * **검사** — CBV `inspecting`. 1차 출처(CBV 2.0) 정의: 「Process of reviewing objects to address
+     * potential physical or documentation defects」이고, 「표본과 달리 검사된 대상은 그대로 남는다」고
+     * 이어진다(즉 검사는 물건을 소비하지 않는다).
+     *
+     * 이 단계에 `DISP.conformant`/`DISP.non_conformant` 가 붙어 판정이 처분으로 남는다 — 입고검수·
+     * 공정 중 검사가 그 모양이다.
+     */
+    inspecting: 'urn:epcglobal:cbv:bizstep:inspecting'
 };
 // ── GS1 EPC URI 헬퍼 (표준) ────────────────────────────────────────────────
 /** SSCC (물류단위: 팔레트/화물/트레일러) — 결정적 카운터 기반. */

package/dist/flow-engine.d.ts

@@ -1,4 +1,5 @@
-import type { TestResult, ISOTime, MaterialQuantity, WorkCalendarEntry, EffectivePeriod, Effectivity, OffCalendarReason, ResourceProperty, ResourceClassDef, MaterialDefinition, Attention, TwinModelDef, CanonicalEnvelope, Command, CommandAck, EventHandler, EquipmentMotion, OeeMetrics, AssetState, GeneratorSpec, InterventionOutcome, OrderState, PersonState, ScenarioControl, ScenarioOverride, StateSnapshot, TwinKernel, Unsubscribe, LocationState, ItemState, EquipmentState, OrderStatusDelta, TaskState, TaskStatus, StructureShift, IdentityGroundingView, IdentityDeclaration } from './contract.ts';
+import type { TestResult, ISOTime, MaterialQuantity, WorkCalendarEntry, EffectivePeriod, Effectivity, OffCalendarReason, ResourceProperty, ResourceClassDef, MaterialDefinition, Attention, TwinModelDef, CanonicalEnvelope, Command, CommandAck, EventHandler, EquipmentMotion, OeeMetrics, AssetState, GeneratorSpec, InterventionOutcome, OrderState, PersonState, ScenarioControl, ScenarioOverride, StateSnapshot, TwinKernel, Unsubscribe, LocationState, ItemState, EquipmentState, OrderStatusDelta, TaskState, TaskStatus, StructureShift, IdentityGroundingView, IdentityDeclaration, TestSpecificationCriterion, LocationObservation } from './contract.ts';
+import type { ReducerCheckpoint } from './observed-reducer.ts';
 import type { EpcisEvent, BizTransactionElement } from './epcis.ts';
 import type { AllocationPolicy, SlotView } from './allocation-policy.ts';
 import type { DurationEstimator, DurationContext } from './duration-estimator.ts';
@@ -369,6 +370,10 @@ export declare function deriveAttentions(view: {
         id: string;
         capacity?: number;
         occupancy?: number;
+        /** 이 자리에 걸린 판정 기준들 — 없으면 관측을 판정하지 않는다. */
+        criteria?: TestSpecificationCriterion[];
+        /** 이 자리에서 관측된 물리량들(속성당 최신). */
+        observations?: LocationObservation[];
     }[];
     orders: {
         id: string;
@@ -560,6 +565,37 @@ export declare abstract class FlowEngine implements TwinKernel {
     protected localParams: Map<string, Map<string, string>>;
     /** 관측 구동(P0) — 이벤트를 접는 투영기와 그 사실. tick 과 섞이지 않게 명시적으로 들고 있다. */
     private observer?;
+    /**
+     * **관측 리듀서의 재개점을 꺼낸다** — 호스트가 저장해 다음 기동에서 되돌릴 수 있게.
+     *
+     * ── 무엇이 문제였나 (2026-08-24 실측) ──────────────────────────────────────
+     * 미러는 재기동마다 저널을 **0부터** 다시 집계했다. 실측으로 저널이 2,960만 줄이고, 그 때문에 기동
+     * 직후 몇 분간 상태가 비어 있었다. 계측처럼 경계 없이 자라는 흐름이 들어오면 그 몇 분이 몇십 분이
+     * 된다 — 불편이 아니라 벽이다.
+     *
+     * 재개점 자체는 오래전부터 있었다(`serialize`/`restore`). 조회 경로는 그것을 쓰는데
+     * (`replayFrom`) **라이브 경로에는 꺼낼 문이 없었다.** 그래서 호스트가 저장할 수 없었다.
+     *
+     * ── 상태 스냅샷으로는 대신할 수 없다 ──────────────────────────────────────
+     * 리듀서는 소비처가 보는 값 말고도 든다: 부모를 기다리는 담김·집계 중인 수량·담을 줄 몰라 세어 둔
+     * 사건. 상태만 되돌리고 이어 집계하면 **0부터 집계한 결과와 조용히 달라진다**(§`ReducerCheckpoint`).
+     *
+     * 관측 구동이 아니면 `undefined` — 시뮬은 리듀서를 갖지 않는다(저장할 것이 없다).
+     */
+    observedCheckpoint(): ReducerCheckpoint | undefined;
+    /**
+     * **재개점에서 관측 리듀서를 되세운다** — 저널을 0부터 다시 집계하지 않게.
+     *
+     * 리듀서가 아직 없으면 만든다: 미러는 첫 봉투가 올 때 리듀서를 만드는데(§`apply`), 되돌리기는 그보다
+     * 먼저 일어나야 한다(그러지 않으면 첫 봉투가 빈 리듀서를 만들고 되돌린 것을 덮는다).
+     *
+     * 되돌린 뒤 상태로 옮긴다 — 그러지 않으면 첫 스냅샷이 빈 상태를 보인다.
+     *
+     * **구조가 다르면 되돌리지 않는다**: 재개점은 그 모델 위에서 만들어진 것이고, 다른 공장의 재개점을
+     * 얹으면 없는 자리·설비가 생긴다. 판단은 부르는 쪽이 한다(`structureRev` 를 아는 것은 호스트다) —
+     * 여기서는 받은 것을 그대로 세운다.
+     */
+    restoreObserved(cp: ReducerCheckpoint): void;
     /**
      * 이 커널의 상태가 **관측에서 왔나** — 미러인가.
      *