{
  "n_docs": 5,
  "assignments": {
    "sample_dt_factory_2022": 0,
    "sample_dt_overview_2024": 1,
    "sample_dt_sync_2023": 0,
    "sample_ml_anomaly_2023": 0,
    "sample_std_interop_2021": 1
  },
  "topic_info": [
    {
      "Topic": 0,
      "Count": 3,
      "Name": "0_twin_synthetic_sample_state",
      "Representation": [
        "twin",
        "synthetic",
        "sample",
        "state",
        "digital",
        "decision",
        "synthetic sample",
        "value",
        "paper",
        "digital twin"
      ],
      "Representative_Docs": [
        "        A Digital Twin on the Factory Floor: an\n             Eighteen-Month Case Study\n\n                                      E. Eriksen\n\n                             2022 (synthetic sample)\n\n      Synthetic sample paper. Written solely as a sample source for the chi-\n      tragupta documentation\u2019s worked examples; the factory, the numbers and\n      the lessons are invented for illustration. Public domain (CC0).\n\n\nSetting\nThis case study follows a digital twin of a packaging line \u2013 three filling stations, two\nlabellers, one palletiser \u2013 through eighteen months of operation at a mid-size synthetic\nbeverage plant. The twin began as a monitoring dashboard and ended as the plant\u2019s\nscheduling authority, and the path between those two points is the subject of this paper.\n\n\nPhase one: the shadow that earned trust\nThe first six months deliberately stopped at a digital shadow: sensor data flowed to\nthe model automatically, and nothing flowed back. This was an explicit trust-building\ndecision. Operators could compare the shadow against the line they could see, and its\none visible product \u2013 a per-station utilisation display \u2013 was checked against manual logs\nweekly. By month four the weekly checks were abandoned as redundant, which we treat\nas the moment the representation earned operational trust.\n\n\nPhase two: closing the loop\nActuation began with the lowest-stakes decision on the line: palletiser pattern selection.\nThe twin\u2019s predicted changeover cost was allowed to pick the pattern, with a supervisor\noverride that was exercised eleven times in the first month and twice in the sixth.\nScheduling authority followed station by station. The deciding argument for each\nextension was never model accuracy in the abstract; it was the override log, which\nshowed supervisors agreeing with the twin\u2019s choice in over ninety-five percent of cases\nfor three consecutive months.\n\n\n\n\n                                            1\n\fWhat broke\nTwo failures are worth recording. A firmware update changed one labeller\u2019s event times-\ntamps from local time to UTC, and the twin silently recorded eight hours of impossible\nsequences before a scheduled report made the corruption visible; input validation on\ntimestamp monotonicity would have caught it in seconds. And a maintenance bypass\nswitch, invisible to the sensor layer, meant the twin scheduled work for a station that\nwas physically disconnected \u2013 the one incident that required a human to notice that\nreality and representation had parted.\n\n\nLessons\nTrust is built by letting people audit the twin against reality on their own schedule, and\nit is spent invisibly whenever the twin is confidently wrong. Start with the decision\nnobody is afraid to delegate, publish the override log, and treat every silent divergence\nbetween plant and model as a severity-one defect, because the operators will.\n\n\n\n\n                                            2\n\f",
        " State Synchronisation Strategies for Operational\n                 Digital Twins\n\n                                C. Chen and D. Devi\n\n                              2023 (synthetic sample)\n\n      Synthetic sample paper. Written solely as a sample source for the chi-\n      tragupta documentation\u2019s worked examples; all measurements are invented\n      for illustration. Public domain (CC0).\n\n\nThe synchronisation problem\nA digital twin is only as trustworthy as its last synchronisation. The engineering question\nunderneath every twin deployment is how state moves from the asset to its representation:\nhow often, at what granularity, and with what guarantee when the link fails.\n\n\nPush, pull, and event-driven flows\nWe compare three strategies. Under periodic pull, the twin polls the asset on a fixed\ninterval; the implementation is simple and the staleness bound is exactly the interval, but\nquiet assets are polled as often as busy ones. Under threshold push, the asset transmits\nwhen a sensed value moves more than a configured delta; bandwidth follows activity,\nbut a mis-set delta hides slow drift entirely. Under event-driven flows, domain events \u2013\na job start, a valve close \u2013 trigger synchronisation; the twin\u2019s state history then reads as\na process log, which operators in our trials strongly preferred.\nIn our synthetic benchmark across nine simulated production cells, event-driven flows\nreduced transmitted volume by 71 percent against one-second periodic pull while\nkeeping worst-case staleness under two seconds during active periods. Threshold push\nperformed comparably on volume but produced the two worst staleness excursions of\nthe study, both during slow thermal drift that never crossed its delta.\n\n\nConsistency after disconnection\nLinks fail, and a twin\u2019s behaviour during reconnection defines its trustworthiness. We\nargue for explicit staleness marking: a twin that knows it is stale must say so on every\nread, rather than serving the last value as if it were current. In our trials, marking\n\n\n                                             1\n\fstaleness cut operator mistrust incidents roughly in half, because the twin stopped being\nconfidently wrong.\nReplaying a backlog after reconnection is a separate decision from marking. Full\nreplay restores the audit trail; last-value-wins restores currency fastest. The hybrid we\nrecommend replays events into history while promoting only the newest value to the\nlive state.\n\n\nConclusion\nSynchronisation strategy is a first-class design decision, not plumbing. Event-driven\nflows with explicit staleness marking and hybrid reconnection gave the best operator-\ntrust outcomes in our synthetic trials, and the pattern costs little more than the periodic\npull it replaces.\n\n\n\n\n                                            2\n\f",
        "Lightweight Anomaly Detection over Digital-Twin\n                State Streams\n\n                               F. Farah and G. Gupta\n\n                              2023 (synthetic sample)\n\n      Synthetic sample paper. Written solely as a sample source for the chi-\n      tragupta documentation\u2019s worked examples; the methods are textbook and\n      the results are invented for illustration. Public domain (CC0).\n\n\nMotivation\nA digital twin\u2019s state stream is a natural place to detect anomalies: it is already cleaned,\naligned and semantically labelled, which is most of the work in industrial anomaly\ndetection. The question this paper examines is how little model is enough once the twin\nhas done that work.\n\n\nThree detectors\nWe compare three detectors of increasing cost on the same synthetic state streams. The\nfirst is a rolling z-score per signal: a value more than four standard deviations from\nits trailing one-hour mean is flagged. The second is an isolation forest over ten-signal\nwindows, retrained nightly. The third is a small autoencoder whose reconstruction error\nis thresholded at the ninety-ninth percentile of a clean week.\n\n\nResults\nOn streams with injected point faults, all three detectors exceeded 0.95 recall; the\nz-score\u2019s precision (0.71) trailed the forest (0.88) and the autoencoder (0.90) because\nit fired on legitimate setpoint changes it had no context to recognise. On injected drift\nfaults the ordering reversed at the tail: the autoencoder, retrained on a window that had\nbegun to drift, absorbed the fault into its notion of normal and missed the slowest ramp\nentirely, while the humble z-score \u2013 anchored to a longer baseline \u2013 flagged it after nine\nhours.\nThe cost gap is larger than the accuracy gap. The z-score runs in constant memory\nper signal; the forest\u2019s nightly retrain took eleven minutes on our synthetic plant;\n\n\n                                             1\n\fthe autoencoder required a GPU hour per week and a human decision about when a\nretraining baseline is clean.\n\n\nRecommendation\nLayer, do not choose. Run the z-score everywhere as the incorruptible baseline nobody\nretrains, and add a learned detector only on the signals whose false-positive cost justifies\nits upkeep. The layered configuration matched the autoencoder\u2019s precision on point\nfaults while retaining the z-score\u2019s immunity to baseline corruption on drift \u2013 the failure\nmode that matters most, precisely because it is the one a learned model conceals.\n\n\n\n\n                                             2\n\f"
      ]
    },
    {
      "Topic": 1,
      "Count": 2,
      "Name": "1_twin_model_asset_sample",
      "Representation": [
        "twin",
        "model",
        "asset",
        "sample",
        "digital",
        "synthetic",
        "data",
        "synthetic sample",
        "automatically",
        "twins"
      ],
      "Representative_Docs": [
        "   Interoperability Standards for Industrial Asset\n              Models: a Field Guide\n\n                               H. Havel and I. Ismail\n\n                              2021 (synthetic sample)\n\n      Synthetic sample paper. Written solely as a sample source for the chi-\n      tragupta documentation\u2019s worked examples; the standards landscape it\n      sketches is simplified for illustration. Public domain (CC0).\n\n\nWhy standards decide twin projects\nDigital-twin pilots rarely die of modelling problems; they die of integration. Every asset\non a real site speaks the protocol its vendor shipped a decade ago, and the cost of a\ntwin is dominated by the adapters between those dialects and the twin\u2019s own model.\nStandards are how that cost is paid once instead of per project.\n\n\nThree layers of agreement\nInteroperability requires agreement at three distinct layers, and conflating them is the\ncommonest failure we observed. At the transport layer, systems agree how bytes move\n\u2013 a publish-subscribe broker, a request-response service, a file drop. At the syntax layer,\nthey agree how a message is structured \u2013 a schema language and a serialisation. At the\nsemantics layer, they agree what the fields mean \u2013 that two systems\u2019 \u201ctemperature\u201d\nis the same sensor, unit and sampling discipline. Transport and syntax standards are\nmature and plentiful; semantic agreement is where projects stall, because it cannot be\nbought, only negotiated.\n\n\nThe asset-model registries\nThe practical instrument of semantic agreement is a shared asset-model registry: a\nversioned catalogue mapping every signal to a definition, a unit and an owner. In\nour synthetic survey of twelve multi-vendor sites, the eight that maintained a registry\nintegrated a new asset in a median of six days; the four that negotiated semantics per\nproject took seven weeks for the same task. The registry\u2019s value came less from the\ncatalogue itself than from the ownership column: a signal with a named owner had\nsomeone to answer the questions the schema could not.\n\n\n                                            1\n\fVersioning discipline\nAn asset model is a contract, and contracts change. The sites that survived model\nevolution treated versions as append-only: a field is never repurposed, only deprecated\nand replaced, and every message carries the model version it was written against. The\none site that allowed in-place field redefinition spent, by its own estimate, a quarter of\none engineer\u2019s year attributing a single mis-unit incident.\n\n\nConclusion\nBuy transport and syntax; budget for semantics. A registry with named owners and\nappend-only versioning converts the semantic negotiation from a per-project tax into a\none-time investment, and in our sample it was the strongest single predictor of a twin\nproject reaching production.\n\n\n\n\n                                            2\n\f",
        "   Digital Twins: Definitions, Distinctions, and a\n                  Short Taxonomy\n\n                             A. Author and B. Builder\n\n                              2024 (synthetic sample)\n\n      Synthetic sample paper. This document was written solely as a sample\n      source for the chitragupta documentation\u2019s worked examples. It imitates\n      the shape of a survey paper; its claims are illustrative, not scholarship.\n      Public domain (CC0).\n\n\nIntroduction\nA digital twin is a virtual representation of a physical system that is kept consistent with\nthat system for the length of its operating life. The phrase is often used loosely, and\nmuch of the early literature disagrees about where a simulation ends and a twin begins.\nThis short overview fixes the vocabulary used across our sample corpus.\n\n\nThree levels of integration\nWe distinguish three levels of integration between a physical object and its virtual\ncounterpart. A digital model exchanges data with its physical counterpart only through\nmanual steps: an engineer updates the model when the plant changes, and nothing flows\nback automatically. A digital shadow adds an automatic data flow in one direction,\nfrom the physical object to the virtual one, so the representation tracks reality without\nhuman effort. A digital twin closes the loop: data flows automatically in both directions,\nand a change in the virtual object can actuate a change in the physical one.\nThe distinction matters in practice because the engineering cost rises sharply at each\nlevel. In our synthetic survey of forty deployments, twenty-eight systems described as\ntwins were, by the definition above, shadows: they monitored faithfully but actuated\nnothing.\n\n\nWhat a twin is for\nFour uses dominate. First, monitoring: the twin renders the current state of the asset\nlegibly. Second, prediction: simulation over the twin\u2019s state estimates behaviour under\n\n\n                                             1\n\fhypothetical loads before they occur. Third, optimisation: the closed actuation loop\nlets predicted improvements be applied automatically. Fourth, and least discussed,\nrecord-keeping: a twin\u2019s state history is an audit trail of the asset\u2019s life, valuable long\nafter the asset is retired.\n\n\nA note on fidelity\nFidelity is not free, and it is not always desirable. A twin that models every bolt of\na wind turbine costs more to keep synchronised than the turbine costs to run. The\nuseful question is not \u201chow faithful is the twin\u201d but \u201cwhich decisions does the twin\nhave to support\u201d, and fidelity should be purchased decision by decision. In our sample\ndeployments, the twins that survived beyond their pilot phase were uniformly the ones\nwhose scope had been cut to a named decision list.\n\n\nConclusion\nThe model/shadow/twin distinction is a property of data flow, not of model sophistication.\nA crude model with two-way automatic flow is a twin; a exquisite model updated by hand\nis not. Keeping the vocabulary strict keeps expectations honest, and honest expectations\nare the difference between a deployed twin and an abandoned pilot.\n\n\n\n\n                                            2\n\f"
      ]
    }
  ],
  "embedding_model": "sentence-transformers/all-mpnet-base-v2",
  "embedding_method": "chunk-mean-content-v2",
  "memberships": {
    "sample_dt_factory_2022": {
      "0": 0.372023
    },
    "sample_dt_overview_2024": {
      "1": 0.568182
    },
    "sample_dt_sync_2023": {
      "0": 0.394773
    },
    "sample_ml_anomaly_2023": {
      "0": 0.590058
    },
    "sample_std_interop_2021": {
      "1": 0.770421
    }
  },
  "membership_mechanism": "centroid-cosine-centred-v2"
}