# Twin Mining TMS — full content in English > Twin Mining TMS is a tailings storage facility management and monitoring platform: it brings together instrumentation, operations and technical documentation, supports decisions with information and artificial intelligence, tracks compliance, and keeps reports and traceability for every decision. Site: https://twin-mining.com/en/ ## Twin Model URL: https://twin-mining.com/en/modules/twin-model/ Put on the same map what moves around the site — the trucks and their haul cycle — and what is being built — the dam raise; today over a simulation, with the visualization ready to connect to the operator's position feed. ### The problem The tailings facility does not live apart from the mine: the dam is raised with material hauled by the same trucks that work the pit, and the dam works compete for that fleet. Yet the fleet is watched in one system, the works in the contractor's drawings and the facility in its own. Nobody has a view where you can see, at once, how many trucks are dumping on the dam and how much is left on the reach being filled. And the dam raise, the most sensitive works on the facility, is tracked through periodic reports: cut and fill, compaction by lot, progress by reach. Reports that arrive late and are hard to compare with one another. Twin Model, inside Twin Mining TMS, is the visualization of those two things on the same map. It is built and ready to connect to the operator's position feed; today it runs on a simulation, and we say so before anyone asks. ### What it does - **The whole site on one map (simulated visualization).** A map of the whole site with the truck fleet, its haul-cycle state — loading, hauling loaded, dumping, hauling empty, stopped — and the shift indicators by site and by zone. Today the fleet is a deterministic simulation: it is shown as a visualization capability, never as a real fleet in operation. - **The facility geometry is real.** The outline of the dam and the ponds is drawn over the satellite image, generated from the facility survey, not from a sketch. - **Zone counts with geofences.** Each truck is assigned to the zone it is in — pit, crusher, dumps, dam — or left as en route, and the indicators are summed by zone. The facility's dam is one more zone of the site. Over today's simulation, the count is of simulated trucks. - **The dam raise, walkable in time (simulation).** Works view: progress by reach, cut and fill, contour lines, cross profile, compaction control by lot, haulage to the dam and a 3D view, walkable survey by survey. There is no real survey behind it: it is a simulation anchored to the design figures of a raise report. We show the tool, not its numbers. - **Measurement with an elevation profile.** A measuring tool on the map with distance, minimum and maximum elevation, ascent, descent and average slope. It is the only measured value on the screen, and it is worth saying where it comes from: a public 30 m digital elevation model with a vertical error of around ±16 m. Good for a sense of the terrain, not for construction survey. - **The data source is swappable.** The screen consumes a contract and the source — simulated today — is swapped by configuration without touching the interface. The visualization is done; connecting the real position feed does not require redoing it, and it is an integration project. ### What it works out on its own It is a read-only surface. The only thing it computes on its own is which zone each truck is in — geofences: pit, crusher, dumps, dam, or en route — and the indicators that come from summing by zone; today, over simulated positions. And the only measured thing on the screen is the elevation profile of the measuring tool, which queries a public 30 m digital elevation model. ### What it never decides It does not dispatch, assign trucks or raise alerts. There is no integration with the operator's position feed: the fleet moving on screen is a deterministic simulation, and the works are a simulation anchored to the design figures of a raise report. ### What it does not do yet - The fleet is simulated. Everything that moves on screen — trucks, states, shift indicators — comes from a deterministic function of time, and the screen does not say so. That is why every image from this module carries a simulated-visualization caption. - There is no integration with the operator's position feed, no route history or playback, and no alerts on entering or leaving a zone. The visualization is built and ready to connect; the integration is a project. - The works are a simulation anchored to design figures. The surveys, the progress and the lots are constructed, and no figure from this screen is published: no tonnes, no cycles, no percentage complete. - The camera videos in the zone view are stock footage, and their detection labels are demonstration placeholders. The view reserves the spot for existing cameras beside the zone's indicators; nothing more. - The heat maps have no measurement behind them. We do not talk about them until they have a source. ### Frequently asked questions **Does Twin Model connect to our fleet dispatch system?** Not today. The fleet visualization is built and ready to connect to the operator's position feed; today it runs on a deterministic simulation, and the screen does not say so, so we do. The data layer consumes a contract and the source is swapped by configuration without touching the interface, but the integration is a project, not a checkbox. Twin Model does not replace a fleet system: it puts what that system already knows next to the facility, with the dam as one more zone of the site. The only measured value on the screen is the elevation profile of the measuring tool, which comes from a public 30 m digital elevation model. **Are the cameras and detection labels shown in Twin Model real?** No. The camera videos in the zone view are stock footage, not from the facility, and the detection labels are demonstration placeholders. The view reserves the spot for existing cameras beside the zone's indicators; nothing more. The same goes for everything that moves on the screen: the fleet, its states and the shift indicators are a simulation, and the dam works are a simulation anchored to design figures. That is why no Twin Model image is published without a simulated-visualization caption, and no figure from that screen is published. **How are data integrated from instrumentation, sensors, and other systems?** Twin Mining TMS's data layer uses interchangeable adapters per source: the screen consumes a contract and the source — geotechnical and geochemical instrumentation, sensors, corporate systems — is swapped by configuration without touching the interface. There is also an API for integration; there is no write path towards control systems. Each integration is a piece of work, not a checkbox: source, frequency and units have to be agreed with the operator. We say so up front so nobody arrives at the first meeting expecting an automatic connection. Integrations are implemented incrementally, source by source, without stopping what already works. ## Knowledge Base URL: https://twin-mining.com/en/modules/knowledge-base/ Turn a facility's folder of technical reports — stability studies, monitoring, closure plans, manuals, protocols, TARPs — into something you can ask, and that answers citing the page. ### The problem A facility's knowledge sits in documents nobody opens again. Not because they don't matter: because finding the answer requires knowing which report it is in, and the person who wrote it is the one who knows. When that person moves to another project, the document stays in the folder and the knowledge does not. And there is a quieter problem underneath: nobody knows which version rules. The same folder holds the report at revision B, the same one at C, and the approved one. A TARP pointing at the wrong revision is a correct procedure executed against a threshold that no longer exists. Twin Mining TMS ingests the corpus once — conversion to PDF, the original archived, metadata transcribed from the cover page — and from then on it is indexable, searchable and citable. The assistant proposes an answer, cites the document and page, and signs it; the person decides what to do with it. ### What it does - **Revision control from the trade.** A document runs through the letters A, B, C while under review and reaches 0 when the client signs and validates it. Zero is terminal: a later change is a new document that starts at A and points at the one it replaces. That is how tailings engineering actually works. - **The citation carries the page.** Ask in plain language and the answer cites the document and the page it came from, not just the file name. That is the difference between an answer and a hint, and it is verified in one click. - **Nothing is derived.** No metadata is invented. Title, date and type are transcribed from the document's cover page, not from the file name, and a field nobody wrote shows up empty rather than filled with a plausible value. In a module whose output is used as evidence, an invented metadata field is worse than none. - **Figures come out of the PDF and stay objects.** Figures and charts are extracted from the documents and become addressable: they can be opened, combined with one another and used as the basis for a new chart. - **A graph you can walk.** A knowledge graph links documents, studies and people by their declared relationships, and lets you walk from a report to what replaced it or what cites it. - **Three advisors, one engine.** Protocols advisor, technical advisor and GISTM compliance are three configurations of the same query engine over the corpus, not three products. Each proposes, cites the document and page, and signs; the person decides. ### What it works out on its own It answers and cites. Every statement from the assistant carries the document and page it came from, and the interface shows the sources beside the answer, not underneath in small print. The sources panel has a permanent place of its own, even when empty. ### What it never decides It does not decide what is true, approves nothing and changes no state. And it does not derive: a field nobody wrote shows up empty. An earlier version fabricated plausible metadata from an identifier; the screen looked complete and it was fiction. ### What it does not do yet - In the demo the corpus is a simulated catalogue, byte-for-byte reproducible and with no network calls. That is a presentation choice, not a product limitation — but no capture shows a client's documents. A technical report identifies the facility on its cover page. - "Three advisors" are three configurations of the same engine. They are not three specialized artificial intelligences. - The assistant answers and cites. It does not decide, approve, or change any state. Models get things wrong; that is why the page-level citation is verified in one click and the module prefers an empty field to a plausible one. - The search and assistant captures show the layout, not an answer in progress: they are taken right after opening. ### Frequently asked questions **Which documents does the Knowledge Base accept, and how does it handle revisions?** The documents a tailings facility lives with: stability studies, monitoring reports, closure plans, operating and instrument manuals, emergency protocols and TARPs. Ingestion converts each document to PDF, archives the original and transcribes title, date and type from the cover page, not from the file name; deriving them produced invented titles that later contaminated the citations. Revision control follows the trade: a document runs through the letters A, B, C while under review and reaches 0 when the client signs and validates it. Zero is terminal. A later change is a new document that starts at A and points at the one it replaces, so it is always clear which version rules. **Language models make things up. How do I know a Knowledge Base answer is true?** That is exactly the right objection, and the answer is built into the module. The assistant proposes an answer and cites the document and the page it came from, not just the file name; the citation is verified in one click, and the sources panel has its own permanent place beside the answer, even when empty. A person decides what to do with it. And one rule governs the whole module: nothing is derived. A field nobody wrote shows up empty instead of being filled with a plausible value. The assistant does not decide what is true, approves nothing and changes no state. **Does Twin Mining's artificial intelligence make decisions on its own?** No. Agents propose and cite; people decide. This is not a stated policy: it is in the data model. An agent suggestion enters a state that blocks until a person confirms it, and that confirmation is a second event with its own author and timestamp. An agent never takes part in evaluating state transitions, and every verdict is signed with the model and prompt version that produced it, so an external reviewer can reconstruct where it came from. Nothing is inferred from nothing either: every edge of the impact graph corresponds to a real relationship in the data model and declares whether it is stated or derived. Deterministic computation first, model narration second — inverting that order would let the model invent the pattern with no way to check it. ## Operations URL: https://twin-mining.com/en/modules/operations/ Answer the question that orders a facility's operation — how much water comes in, how much goes out and how much stays — and see the pipelines that carry tailings and water: where they run, what equipment they have and what their instruments say. ### The problem In most operations, a facility's water balance lives in a spreadsheet one person updates. It is a good spreadsheet — usually years of work inside — and it has three problems that improving it will not fix: only its keeper understands it, the source data is copied by hand, and it is not where the rest of the conversation is. When freeboard shrinks, the discussion happens over a screenshot of that spreadsheet pasted into an email. Pipelines are similar. Kilometres of line with pumps, boxes and drop chambers, and their state is checked in the control system point by point: a pump's flow on one screen, a reach's pressure on another. Nobody sees the whole line, with its equipment in order and the failing instrument marked where it sits. Twin Mining TMS puts the balance and the pipelines in the same place as the alerts, the tasks and the document that justifies each band. A flow rate without its band is a number, not an alarm. ### What it does - **Water balance as a waterfall.** Inflows, outflows and the result, in a single reading, instead of scattered across a spreadsheet. On the same screen as the alerts and the tasks. - **The circuit is drawn.** The tailings circuit is represented as a navigable schematic diagram, with facility and junction nodes and animated flow edges. Most tools in the sector show tables of measurement points; here the flow has a shape. - **Performance and alerts on the map.** Operational elements coloured by their threshold band, and the pipeline routes over the facility map; each point opens its series. In the demo, test sensors with simulated series sit alongside the rest. - **Pipelines with their real route.** Tailings, return-water and drainage pipelines are drawn with their real route over the facility, grouped by system, and each has a card with length, straightness, azimuth and associated instruments. The route comes from the survey, not from a sketch. - **A process schematic per pipeline.** Each pipeline has a schematic with its equipment — boxes, drop chambers, pumps, junctions — and its instruments coloured by band. Equipment is shown in order, not to scale, and the screen says so; what is real is the length of each reach, labelled. It is not an engineering drawing. - **Instruments attach themselves.** Instruments attach themselves to the nearest pipeline and are placed at their real chainage, with their offset from the axis. Nobody maintains by hand the list of which sensor belongs to which line. - **A data source swapped by configuration.** The interface consumes a contract — readings, summary, balance, topology — and does not know where the data comes from. Behind it are swappable adapters; there are three implementations. Connecting a client's historian does not require rewriting a screen, but each concrete connection is an integration project, not a checkbox. ### What it works out on its own It presents. When a sensor has no configured threshold, it derives bands from its own series with the same shape as a real threshold — and it knows that for freeboard, factor of safety and strength the dangerous side is the low side, so it mirrors them. That is not an operational recommendation: it is a reference value so that a number never appears bare on screen, and the interface does not present it as an approved threshold. ### What it never decides It decides nothing about the operation. Thresholds are defined by a person, and changing them is subject to the management-of-change lock — currently in observe mode. It does not model flow, does not detect leaks and does not act on pumps or valves: there is no write path to control systems. ### What it does not do yet - Five of the nine menu entries are not built: transport and deposition plan, storage capacity, sand deposition, environmental and operational reports. They do not appear in the demo and are not part of what is shown. - There is no hydraulic profile, head-loss calculation, leak detection or pump-and-valve control. The screen draws the route, orders the equipment and shows readings; it does not model flow or act on anything. That there is no write path to the control system is also the module's most valuable safety property. - In the demo, every sensor without readings gets a deterministic simulated series that never overwrites real data. In the process schematic it is marked with a dashed border and a simulated label; on the main performance map there are old test sensors without that mark. No capture is live telemetry. - The architecture is ready to connect the client's historian. Each concrete integration is still a project; we do not promise it as immediate. - The water-balance forecast appears in the menu and is disabled in the demo. ### Frequently asked questions **Does Twin Mining TMS connect to my historian or control system?** The data layer is designed for it: the interface consumes a contract — sensor readings, summary, water balance, topology — and does not know where the data comes from. Behind it are swappable adapters chosen by configuration, and three implementations exist. Plugging in a client's historian does not require rewriting a single screen. But each concrete connection is an integration project, not a checkbox. We do not promise it as immediate. And there is no write path to the control system: the platform reads and presents, it does not act on pumps or valves. That is also its most valuable safety property. The historian has the series. What it does not have is the band, the task or the document that justifies the band; that is what the platform adds. **Is the pipeline schematic a hydraulic model? Does it detect leaks?** No. The screen draws each pipeline's real route — it comes from the survey — orders its equipment and shows its instruments' readings coloured by threshold band. It does not model flow, compute head losses, detect leaks or blockages, or control pumps and valves. The process schematic is in order, not to scale, and the screen says so; what is real is the length of each reach, which is labelled. It is not an engineering drawing. What it adds is something else: a twenty-kilometre line that reads at a glance, with the out-of-band instrument marked at its chainage rather than in a list. **How are data integrated from instrumentation, sensors, and other systems?** Twin Mining TMS's data layer uses interchangeable adapters per source: the screen consumes a contract and the source — geotechnical and geochemical instrumentation, sensors, corporate systems — is swapped by configuration without touching the interface. There is also an API for integration; there is no write path towards control systems. Each integration is a piece of work, not a checkbox: source, frequency and units have to be agreed with the operator. We say so up front so nobody arrives at the first meeting expecting an automatic connection. Integrations are implemented incrementally, source by source, without stopping what already works. **What is a TARP in tailings facility management?** TARP stands for Trigger Action Response Plan. It is the set of threshold bands for an instrument — green, amber, red — together with the response defined for each: which actions are mandatory, who must approve them, and who must be notified. Explained to someone outside the sector: it is a sensor's traffic light, plus what has to happen when it changes colour. In Twin Mining TMS the threshold, the response, and the document backing it live on the same screen, and changing a threshold goes through a formal management-of-change record. That last link is what separates a TMS from a monitoring system. ## Physical Stability URL: https://twin-mining.com/en/modules/physical-stability/ Put an instrument's reading, the band that qualifies it and the response that band calls for on the same screen — and let the dam be viewed in section, cross-section by cross-section, the way the engineer thinks about it. ### The problem A well-instrumented facility produces a great deal of data and very few people interpret it. Piezometers, inclinometers and survey points generate series that someone periodically reviews against a criterion written in a report, in a TARP, somewhere else. The familiar result: the anomalous reading was in the system days before anyone looked at it, because looking required opening the series, remembering the threshold and knowing whom to call. And there is a mismatch of form: the engineer thinks about the dam in section — what lies beneath, how deep the piezometer is, in which stratum — but monitoring software shows it in plan, as points on a map. The section lives in a drawing inside the stability report, separated from the readings. Twin Mining TMS does not assess stability. It lets you see sooner what was already happening: it shortens the time between a reading changing and someone looking at it, and puts the threshold and the protocol in front of whoever looks, without a search. ### What it does - **The band travels with the reading.** Instrumentation points appear on the facility map coloured by their threshold band, and clicking one opens its time series with the bands drawn over the chart. The state of the whole reads without opening anything. - **A band crossing takes over the screen.** When a sensor crosses a band other than green, the whole application raises a situation overlay with sensors grouped by colour, a severity gauge, the short series and the point's map. It is not a bell-icon notification. - **Criticality is derived.** An instrument is critical when a TARP threshold hangs from it. It is not a box someone ticks: a criticality checkbox maintained by hand stops being true within six months. - **Risk with the tools of the trade.** FMEA matrices, bowtie diagrams and the ALARP tolerability chart with its three bands. Not a generic three-by-three colour matrix. - **The dam is viewed in section.** The dam is walked by cross-sections: each has its real trace in plan, its profile by stratum and the instrumentation placed at its chainage along the trace, with the geometry summarized — dam height, crest elevation, toe elevation, length and azimuth. You reach it from the map. - **A profile by stratum, as a tool.** The profile shows the facility's strata — sands, slimes, bedrock, geomembrane, embankment — with the instruments on top. Today it is loaded by hand and at drawing scale, not real elevations, and only two sections have it. What is real is the trace in plan: length, azimuth and endpoints. - **Filter by instrument family.** Instrumentation is filtered by family — piezometers, inclinometers, prisms — on the map, including instruments installed inside a borehole. The prism family is inferred from the displacement variable. ### What it works out on its own It shortens the time between a reading changing and someone looking at it. It colours each instrument by its band, raises a situation overlay when a reading crosses a band other than green, and derives an instrument's criticality from the fact that a TARP threshold hangs from it. Judgement remains human; what changes is how long it takes before it can be exercised. ### What it never decides It does not assess stability or compute factors of safety. That is a piece of engineering the Engineer of Record produces with their models, and it lives in the platform as a document in the Knowledge Base. The factor-of-safety panel says "no data source" rather than inventing a number. ### What it does not do yet - The module does not assess stability, compute factors of safety or anticipate failures. The Engineer of Record does that with their models. The factor-of-safety panel says "no data source": it is where the Engineer of Record's stability model plugs in, not a result. - The section's phreatic line is a schematic visualization, not a calculation. It does not come from piezometer readings or a seepage model; the figures beside it — gradient, margin — are arithmetic over that curve. The toggle is off by default. - The piezometers in each cross-section are synthetic, and the screen does not mark them, by product decision. No reading, trend or band on that screen is presented as measured. We show the tool, never what it says. - Changing a TARP threshold goes through a management-of-change record, and that lock is currently in observe mode: it records the violation, it does not block it. That is deliberate, because every existing threshold predates the module. - The geotechnical screen, sensors and CCTV exist and are hidden in the demo. They can be mentioned as scope, not shown. ### Frequently asked questions **Does Twin Mining TMS compute the dam's factor of safety?** No. Stability is assessed by the Engineer of Record with their models, and that analysis lives in the platform as a document in the Knowledge Base. The factor-of-safety panel in each cross-section says, in so many words, "no data source": it is where the Engineer of Record's stability model plugs in, not a result the platform produces. What the module does is more modest and more useful than it sounds: it puts the instrumentation, its threshold and the protocol's response on the same screen, and shortens the time between a reading changing and someone looking at it. The Engineer of Record keeps saying what they say; what changes is how long their criterion takes to reach the operator's screen. **Are the readings shown in the cross-section from a real facility?** No. Every capture comes from a demonstration environment, and in the cross-section it pays to be especially precise: the trace in plan is real — length, azimuth and endpoints — but the profile by stratum is loaded by hand at drawing scale, the section's piezometers are synthetic, and the phreatic line is a schematic visualization, not a calculation from readings or from a seepage model. The screen does not mark those piezometers as simulated, by product decision, so we say it ourselves: no reading, trend or band on that screen is presented as measured. What we show is the tool — the navigable section with its stratigraphy and instrumentation — never what it says. **What is a TARP in tailings facility management?** TARP stands for Trigger Action Response Plan. It is the set of threshold bands for an instrument — green, amber, red — together with the response defined for each: which actions are mandatory, who must approve them, and who must be notified. Explained to someone outside the sector: it is a sensor's traffic light, plus what has to happen when it changes colour. In Twin Mining TMS the threshold, the response, and the document backing it live on the same screen, and changing a threshold goes through a formal management-of-change record. That last link is what separates a TMS from a monitoring system. **Does Twin Mining TMS predict tailings dam failures or collapses?** No, and it is worth saying plainly: the platform contains no model that predicts the failure of a tailings storage facility. Any vendor claiming otherwise is making a promise an Engineer of Record will take apart in the first technical meeting. What Twin Mining TMS does do is shorten the time between a reading changing and someone looking at it: thresholds a specialist defined, time series with their bands, anomaly detection over the historical record, and agents that read the facility's documentation and propose with the source cited. Deciding what a deviation means and what to do about it remains with the accountable people: the RTFE, the EoR, and the site organization. ## GISTM URL: https://twin-mining.com/en/modules/gistm/ Turn a 77-requirement standard into a queryable state: what was declared, which evidence supports it, who answers for it, and which external reviewer will look at it and when. ### The problem Today the GISTM self-assessment lives in a spreadsheet one person updates before each review. Status and evidence sit in different places — the green in a cell, the document in a shared folder — so a requirement can stay green for months on the strength of a report that expired, or one nobody signed. Nobody notices until the independent reviewer asks. And it is not a tidiness problem: it is a problem of who can answer. The standard demands accredited, current roles. When the compliance lead has to explain where a green came from, the honest answer is usually "someone who no longer holds the role set it, in a review of which no record remains". Twin Mining TMS does not say whether you conform. It organizes the evidence that supports conformance in front of an external reviewer, requirement by requirement, and shows where the declared status and the documentation do not match. ### What it does - **The standard comes preloaded.** 15 principles and 77 requirements, with their sub-requirements, without the client having to transcribe them. It is the real head start: nobody copies 77 requirements into a spreadsheet before seeing anything. - **Topic → principle → requirement, with its evidence.** It walks the structure of the standard and stores each requirement's self-assessment status with the documentary evidence behind it. The topic-by-principle matrix reads without any text. - **Declared versus evidence, row by row.** A deterministic rule — not a model's judgement — checks the declared status against the attached evidence and flags divergences in the table itself: over-declared, not supported by the documents. The divergences-only checkbox turns the table into the work list. - **An AI verdict with a signature.** An agent reads a requirement's evidence, proposes a verdict on whether it really proves it, cites the document and page, and signs it with its model and prompt version. It is shown beside the declared status, never in its place; a person decides. If the model breaks the output format, the screen shows the prose instead of filling half a table. - **The org chart is a compliance artefact.** Roles, appointments and their validity, with the independent review panel on its own branch. An empty role or an expired appointment is visible, and that is information: the standard treats a change of Engineer of Record as a management-of-change event. - **Compare facilities.** A portfolio view compares the facilities in the demonstration environment, with a ranking and detection of the recurring gap and of the practice that can be transferred. The matching is deterministic; the model only drafts how to transfer the practice. - **Lessons learned tied to the requirement.** A library of lessons from public industry incidents, tied to the requirements they affect, with preventive actions that become tasks. Opening a requirement also answers "what has the industry already learned about this?". ### What it works out on its own A deterministic rule compares the declared status against the attached evidence — it looks only at files, dates and signatures — and flags the divergence. With no evidence, the ceiling is "None"; with undated or unapproved evidence, the ceiling is "Partial": having it is not the same as someone having answered for it. Separately, an agent reads the evidence, proposes a verdict on whether it really proves the requirement, and signs it with its model and prompt version. ### What it never decides It does not decide whether a requirement conforms. A person declares that. The agent's verdict is shown beside the declared status, never in its place, and conformance is verified by an independent reviewer, not by the software. ### What it does not do yet - The software does not say whether you conform. The operator declares conformance and an independent reviewer verifies it; what the module does is organize the evidence that supports it. - Divergence detection is a rule, not the AI. It looks at files, dates and signatures. The model comes afterwards, to interpret the evidence, and signs what it proposes. Merging the two would sell something the product does not do that way. - Today the standard comes preloaded and is not configurable: requirements, scales and periodicities cannot be adapted to an internal framework. That is a head start and a real limitation. - There is an audit tab; per-profile reports (board, Engineer of Record, regulator) are not there yet. What exists is the conformance matrix and the evidence package. - "Portfolio" in the demo means four facilities. We can talk about the mechanics — compare, rank, spot the recurring gap — without implying a scale that is not there. ### Frequently asked questions **Does Twin Mining TMS certify GISTM conformance?** No, and no software can. The operator declares conformance and an independent reviewer verifies it. What the module does is organize the evidence that supports that conformance in front of the external reviewer, requirement by requirement, and show where the declared status and the documentation do not match. A consultancy produces the report once a year; this is the state between reports, which is what the reviewer asks about. A spreadsheet does not know the document expired; the module does, because a deterministic rule checks the declared status against the attached files, dates and signatures. **What exactly does the AI agent do in the GISTM module? Does it decide for me?** It does not decide. Two things the module does differently are worth separating. First, a deterministic rule — not the AI — compares the declared status against the attached evidence, looking only at files, dates and signatures, and flags the divergence. Second, an agent reads a requirement's evidence, proposes a verdict on whether it really proves it, cites the document and page, and signs it with its model and prompt version. The verdict is shown beside the declared status, never in its place; a person decides. And if the model breaks the output format, the screen shows the prose instead of filling half a table: an invented row on a compliance screen is worse than no row. **What is the GISTM and what does it require from tailings operators?** The GISTM (Global Industry Standard on Tailings Management) is the global tailings standard published in 2020 following the Brumadinho collapse. It is structured into 6 topics, 15 principles, and 77 requirements, and major mining operators publicly committed to conform to it. Among other things it requires an interdisciplinary knowledge base for the facility, a designated and empowered Engineer of Record (EoR), a Responsible Tailings Facility Engineer (RTFE), an Independent Tailings Review Board (ITRB), and traceable evidence that each requirement was assessed and by whom. Conformance is declared by the operator and verified by an independent reviewer: no software can certify it. What Twin Mining TMS does is organize the evidence that supports that conformance in front of the external reviewer, requirement by requirement. **Is Twin Mining Tailings aligned with international standards such as GISTM?** Yes. The platform is aligned with the principles of the Global Industry Standard on Tailings Management (GISTM) and helps operationalize the self-assessment of its 77 requirements. It structures processes, controls, evidence, and workflows to assess adherence to all 15 principles with traceability and audit-ready records, and makes visible the gap between what can already be defended and what cannot yet. No software certifies or guarantees GISTM conformance: the operator declares it and an independent reviewer verifies it. What the platform organizes is the evidence that declaration is defended with. ## Management of Change URL: https://twin-mining.com/en/modules/change-management/ No change that alters the facility's risk happens without one person assessing it and a different person authorizing it — and two years on, anyone can reconstruct who decided what, when, with which information in view and under what authority. ### The problem A change in the deposition rate, the pond level, a TARP threshold or the responsible engineer alters the facility's risk even if not a single cubic metre of earth moves. Without a formal record, those changes happen as catalogue edits: someone changes a value on a screen, nobody assesses the effect, and the next review finds a TARP pointing at an instrument that no longer exists. And there is a second problem, the one you pay for in the audit: the decision existed, but the context of the decision was never kept. You know who signed. You don't know what they were looking at when they did. The usual practice today is a paper procedure and a shared folder. The procedure exists; the question is whether the record survives the turnover of the people who ran it. Twin Mining TMS treats every change as a record that can be defended. ### What it does - **A formal record with thirteen states.** Every change that alters the facility's risk runs through a thirteen-state flow, from draft to closure: regulatory screening, impact assessment, Engineer of Record conformance, approval, authorization, execution, verification. The order of the list is the order of the work. - **Segregation of duties, no exceptions.** Whoever requests does not approve; whoever executes does not verify. There is no administrator path around it, and an automated test watches that none appears. - **The approval level is computed and justified.** A rules engine computes who has to sign and returns which rule produced it. An automatic escalation can be justified to an auditor by pointing at the row that caused it. - **"Not applicable" is a signed assessment.** The impact matrix has eight fixed dimensions. The system distinguishes between deciding something does not apply and nobody having looked at it; in a spreadsheet the two look identical. - **A record that cannot be silently tampered with.** Events are hash-chained per facility, not per record, with a verifier that returns a report rather than a boolean. We don't claim the record cannot be altered: we claim that if someone touches it, it shows, and it shows where. - **An audit package organized by question.** It exports structured by question rather than by table: what, who, when, with which information in view, under what authority and with what integrity. PDF to sign, JSON to re-verify the hashes, plain text to diff. - **Impact graph: nothing is inferred from nothing.** When a change is proposed, the system shows which instruments, thresholds, documents and procedures are affected. Every edge corresponds to a real relationship in the data model and declares whether it is stated or derived; none is invented by a language model. The result starts the record — it does not skip it. ### What it works out on its own It decides what can be done now and what is missing. It computes who has to sign — the approval level is a conclusion of a rules engine, not a choice — and makes sure the person approving is not the person who requested. ### What it never decides It does not decide whether a change is a good idea: a person signs that. And an agent never takes part in evaluating transitions: it writes suggestion events, and only the human confirmation — a second event with its own author and date — moves the state. ### What it does not do yet - The TARP threshold lock is currently in observe mode: it records the violation, it does not block it. That is deliberate: every existing threshold predates the module, and enforcing it would lock the screen for the whole team. The observation period buys the evidence. - Today nobody can sign a change, because role appointments have no person assigned. You can create, advance, execute and cancel; you cannot sign. That is deliberate: a platform role never becomes technical authority. - We don't say the record is unalterable. That would be weaker, and also false. We say it is tamper-evident: if someone rewrites it, it shows, and it shows where. - Inspections and Maintenance appear in the menu and do not open. They are not part of what is shown. ### Frequently asked questions **Who signs a change in Twin Mining TMS, and can an administrator sign it?** The person holding the role that matches the approval level signs, and nobody picks that level: a rules engine computes it and returns which rule produced it. Whoever requests does not approve, and whoever executes does not verify. There is no administrator path around that segregation, and an automated test fails if one appears. Today, moreover, nobody can sign yet: role appointments have no person assigned. A change can be created, advanced, executed and cancelled; it cannot be signed. That is deliberate: a platform role never becomes technical authority. An AI agent does not sign either: it proposes, cites, and signs its proposal with model and prompt version, and a person decides. **Is the impact graph generated by artificial intelligence?** No, and that is exactly the opposite of what makes it reliable. When a change is proposed, the system shows which instruments, thresholds, documents and procedures are affected, and every edge in the graph corresponds to a real relationship in the data model: a foreign key, a join table, an index. None is invented by a language model, and each one declares whether it is stated or derived. The result starts the management-of-change record; it does not skip it. The button says "generate change workflow", not "apply". **What is a TARP in tailings facility management?** TARP stands for Trigger Action Response Plan. It is the set of threshold bands for an instrument — green, amber, red — together with the response defined for each: which actions are mandatory, who must approve them, and who must be notified. Explained to someone outside the sector: it is a sensor's traffic light, plus what has to happen when it changes colour. In Twin Mining TMS the threshold, the response, and the document backing it live on the same screen, and changing a threshold goes through a formal management-of-change record. That last link is what separates a TMS from a monitoring system. **Does Twin Mining's artificial intelligence make decisions on its own?** No. Agents propose and cite; people decide. This is not a stated policy: it is in the data model. An agent suggestion enters a state that blocks until a person confirms it, and that confirmation is a second event with its own author and timestamp. An agent never takes part in evaluating state transitions, and every verdict is signed with the model and prompt version that produced it, so an external reviewer can reconstruct where it came from. Nothing is inferred from nothing either: every edge of the impact graph corresponds to a real relationship in the data model and declares whether it is stated or derived. Deterministic computation first, model narration second — inverting that order would let the model invent the pattern with no way to check it. ## Agents URL: https://twin-mining.com/en/modules/agents/ Put the knowledge that is already written — protocols, TARPs, manuals, reports — to work at the moment it is needed: when the ground shakes, when a sensor crosses a band, when someone needs a chart they would otherwise request by email. ### The problem A tailings facility has a procedure for almost everything. The problem is not that one is missing: it is the time between the event and the procedure. At three in the morning, after an earthquake, someone has to remember which TARP applies, find it, read which level corresponds to that magnitude and distance, and notify the right people. That gap fills up with phone calls. And what gets lost is not the action — it gets done in the end — but the record: what was looked at, with which information in view, and who decided. The agents in Twin Mining TMS predict nothing. They do something more useful: they find the procedure you already wrote, walk it at the moment it is needed, propose, cite the document and page, and sign. A person decides. ### What it does - **They propose, cite and sign; they do not decide.** Agents propose, cite the source with document and page, and sign with their model and prompt version. They never decide: human confirmation is a separate event, and only that one moves the state. - **Reasoning and citation are protocol, not decoration.** The agent's reasoning and its citations are first-class events on the channel — start, thought, text, citation, end — not text pasted at the end. The screen shows them as they arrive. - **Post-seismic response over the TARP that already existed.** After a seismic event, the agent walks the post-seismic TARP level by level and proposes the actions of the applicable protocol, with the event record and the affected sensors. Threshold and response on the same screen; the decision stays with the person. - **Conversational data analyst.** It works over the facility's data and produces charts and sheets inside the same screen, without leaving for another tool. The query goes through the specialized-agent dispatcher, not through free-form queries against the database. - **An audit trail of the agents.** There is a log of what the agents did, with the agent's name, the model and the prompt version of each run. A verdict without a prompt version would be an anonymous opinion. ### What it works out on its own It prepares. It reads the corpus by document type, the sensors and their bands, the public seismic catalogue, the standard and its requirements; it walks the applicable protocol and proposes the actions. Everything it does is logged with its name, model and prompt version, so a proposal from three months ago can be attributed and therefore challenged. ### What it never decides Nothing. And not out of commercial caution: by architecture. In management of change, an agent's suggestion enters a state that blocks until a person confirms it, and that confirmation is a second event with its own author and date. An agent never takes part in evaluating state transitions. ### What it does not do yet - They do not predict, detect or anticipate a failure. They read documents, time series and public seismic catalogues, and walk a protocol a person wrote. It is the hardest rule to keep, and what there is is easier to defend. - The agent does not execute: it does not create the change, move the state or notify the team. It prepares the record and leaves it in draft for a person to sign. That is an architecture decision, not a gap. - In the demo, of the natural events only earthquake opens. Rain and overtopping exist and appear in the selector, but are disabled: a live demonstration shows one, not three. - If the model breaks the output format, the screen shows the prose. It never fills half a table: an invented row on a compliance screen is worse than no row. ### Frequently asked questions **Who is accountable if a Twin Mining AI agent gets it wrong?** The same person who was accountable before. The agent did not change who signs; it changed how long it takes to have the protocol in front of you. Agents propose, cite the document and page, and sign with their model and prompt version. They never decide: in management of change, a suggestion enters a state that blocks until a person confirms it, and that confirmation is a second event with its own author and date. A chatbot does not end up in a hash-chained log with its prompt version, nor does it enter a workflow that blocks until someone confirms. Here, a proposal from three months ago can be attributed to a specific agent, model and version, and therefore challenged. **What does the natural-events agent do after an earthquake?** It walks the protocol that already existed, at the moment it is needed, without anyone hunting for the PDF. After a seismic event, the agent walks the post-seismic TARP level by level and proposes the actions of the applicable protocol, with the event record and the affected sensors. Threshold and response end up on the same screen; the decision, and the signature, remain with the person. It does not predict or detect a failure: it reads documents, time series and the public seismic catalogue, and follows a protocol a person wrote. In the demo only the earthquake event opens; rain and overtopping exist and appear in the selector, but are disabled. **Does Twin Mining's artificial intelligence make decisions on its own?** No. Agents propose and cite; people decide. This is not a stated policy: it is in the data model. An agent suggestion enters a state that blocks until a person confirms it, and that confirmation is a second event with its own author and timestamp. An agent never takes part in evaluating state transitions, and every verdict is signed with the model and prompt version that produced it, so an external reviewer can reconstruct where it came from. Nothing is inferred from nothing either: every edge of the impact graph corresponds to a real relationship in the data model and declares whether it is stated or derived. Deterministic computation first, model narration second — inverting that order would let the model invent the pattern with no way to check it. **Does Twin Mining TMS predict tailings dam failures or collapses?** No, and it is worth saying plainly: the platform contains no model that predicts the failure of a tailings storage facility. Any vendor claiming otherwise is making a promise an Engineer of Record will take apart in the first technical meeting. What Twin Mining TMS does do is shorten the time between a reading changing and someone looking at it: thresholds a specialist defined, time series with their bands, anomaly detection over the historical record, and agents that read the facility's documentation and propose with the source cited. Deciding what a deviation means and what to do about it remains with the accountable people: the RTFE, the EoR, and the site organization. ## Frequently asked questions **What is a TMS (Tailings Management System)?** A TMS (Tailings Management System) is the system where a tailings storage facility's knowledge and decisions live: it consolidates operational and instrumentation data, structures the workflows an operator is required to execute — management of change, compliance self-assessment, inspections, corrective actions — and preserves auditable evidence of all of it. It differs from a monitoring platform in scope: monitoring shows the reading; a TMS connects that reading to its threshold, the response defined for that threshold, and the document backing it, while recording who decided what and when. Twin Mining TMS is a platform in this category, built for tailings storage facilities in copper and metal mining. **Which roles is Twin Mining TMS designed for?** For the roles accountable for a tailings storage facility, each with a different entry point into the platform: the RTFE (Responsible Tailings Facility Engineer), the EoR or Engineer of Record, the corporate compliance lead, the Dam Owner or Accountable Executive answering to the board, the geotechnical engineer, the site or shift supervisor, and the independent reviewer or auditor. The platform speaks the language of the trade — TARP, freeboard, ITRB, ALARP, FMEA, EMAC, Chilean DS 248 — because that is the difference between an Engineer of Record believing we understand their work in the first thirty seconds and not. **Can Twin Mining Tailings replace my current monitoring or management systems?** Twin Mining Tailings can integrate with existing systems or partially/fully replace current monitoring and management tools, depending on each operation's architecture and technical decisions. In many organizations, overlapping tools create friction, rework, and fragmented information. The TMS can consolidate those functions into a single governance point for the facility. If current systems are kept, the platform works as an orchestration layer integrating instrumentation, specialized platforms, and corporate systems. If there is functional redundancy, it can replace systems and simplify the technology stack. In both scenarios the goal is the same: that the reading, its threshold, the response and the document behind it live in one place, with a record of who decided what. **How is what the AI agents say validated?** Twin Mining TMS's agents are not black boxes. Every answer cites the document and page it comes from, and every verdict is signed with the model and prompt version that produced it. If there is no source, the agent does not answer in its place. The deterministic part comes first: the impact graph's relationships and the rule that contrasts what is declared with the evidence are computed without a language model. The model only writes the narrative on top, and a person confirms before anything changes state. Thresholds, protocols and failure modes are defined and supervised by the operator's engineering team with support from specialised tailings engineers; the software keeps them together with their supporting document. **Is the platform scalable for multiple facilities and global operations?** Yes. Twin Mining Tailings scales from a single facility to multi-site, multi-country portfolios while maintaining technical consistency and local flexibility. It supports corporate-level standardization of criteria, models, and workflows, while still adapting to each facility's specific conditions. **What role does Twin Mining's engineering team play?** Twin Mining Tailings is not only software. It is complemented by specialized tailings engineers who support implementation, configuration, and system evolution. This team ensures models reflect real facility behavior, TARP thresholds and critical controls are technically sound, and the platform evolves with operational and design changes. **How is Twin Mining Tailings different from a traditional monitoring platform?** Traditional platforms mostly focus on data visualization. Twin Mining Tailings is a Tailings Management System (TMS) that unifies monitoring, operations, risk, and governance. It does not just display information: it structures day-to-day management, links events/decisions/actions, and turns scattered data into active, traceable technical management. One question orders the whole product design: could an external auditor reconstruct who decided what, when, with which information in view, and under what authority? A monitoring system answers the first half; a TMS answers the whole question. **Does Twin Mining Tailings support Chilean regulation and SERNAGEOMIN programs?** Twin Mining Tailings is designed to support compliance with Chilean tailings programs and SERNAGEOMIN requirements, including the M1/M2 modules and Chilean DS 248, aligned with national and international technical guidance. M1 - Inspection and operation: enables structured, traceable daily inspections with evidence, ownership, and immediate availability for audits or regulatory review. M2 - Monitoring and control: integrates required monitoring data with continuity, validation and series with their bands, so a deviation is seen when it happens and it is recorded who looked at it. EMAC - Chemical stability and environmental management: supports water quality/balance, geochemical processes, environmental monitoring, and trend analysis with full traceability. Regulatory compliance is declared and answered for by the operator; what the platform contributes is that the evidence is organized and available when the regulator asks, without adding operational overhead. **Is Twin Mining Tailings modular or a closed solution?** Twin Mining TMS is a modular platform designed to adapt to each operation's technical and organizational reality. Modules can be deployed independently or progressively, enabling incremental adoption and value-based prioritization. All modules share one core: the facility's data model, with its instruments, documents, thresholds and records linked together. It is what lets a decision taken in one module be reconstructed from another. This design reduces implementation friction, avoids heavy upfront projects, and supports scaling from specific use cases to full facility governance. **In which languages and regions is Twin Mining TMS available?** The platform is bilingual Spanish/English across its entire surface, including reports and the field application. The domain layer returns translation keys and never prose, so adding a language does not require rewriting logic. Twin Mining is based in Chile — the world's largest copper producer and one of the most demanding tailings-regulation jurisdictions — and the platform is designed to operate across multi-site, multi-country metal mining portfolios. ## What it does not do - **It does not predict failures or collapses.** There is no predictive failure model. What exists is thresholds a specialist defined, time series with their bands, and agents that read documents. What the platform shortens is the time between a reading changing and a person looking at it. - **It does not certify or guarantee GISTM compliance.** Conformance is declared by the operator and verified by an independent reviewer; the platform organizes the evidence behind that declaration. - **The AI does not decide.** Agents propose and cite document and page; a person decides, and that confirmation is recorded as a separate event with its author and timestamp. - **Twin Model's fleet runs on a simulation today.** The 3D view, the dam section and the survey-by-survey basin are built; there is no GPS, telemetry or dispatch integration yet, and the view is ready to connect to the operator's position source. - **There is no native mobile app.** The platform is used from the browser, including on a tablet in the field. ## Glossary - **TMS** (Tailings Management System): The system where a tailings facility's knowledge and decisions live: it brings together monitoring, operations, documentation and compliance, and keeps the traceability of every decision. - **TSF** (Tailings Storage Facility): The facility where the waste of the mining process — ground rock plus water — is deposited. - **GISTM** (Global Industry Standard on Tailings Management): The global tailings management standard published in 2020: 6 topics, 15 principles, and 77 requirements. - **TARP** (Trigger Action Response Plan): An instrument's threshold bands — green, amber, red — together with the response defined for each. - **EoR** (Engineer of Record): The engineer accountable for the facility design. Provides technical conformance, not administrative sign-off. - **RTFE** (Responsible Tailings Facility Engineer): The engineer accountable for day-to-day operation of the tailings facility. - **ITRB** (Independent Tailings Review Board): The external expert panel that reviews the facility and can contradict the operator in writing. - **ALARP** (As Low As Reasonably Practicable): The criterion defining how far it is reasonable to reduce a risk. - **MoC** (Management of Change): The formal record of any change that alters the facility's risk: who requested it, who assessed it, who authorized it. - **Freeboard**: The vertical distance between the water surface and the dam crest; the margin before overtopping. - **Chilean DS 248**: The Chilean supreme decree regulating the design, construction, and operation of tailings storage facilities. --- # Twin Mining TMS — contenido completo en español > Twin Mining TMS es una plataforma de gestión y monitoreo de depósitos de relaves: reúne instrumentación, operación y documentación técnica, apoya las decisiones con información e inteligencia artificial, hace seguimiento del cumplimiento y deja reportes y trazabilidad de cada decisión. Sitio: https://twin-mining.com/ ## Twin Model URL: https://twin-mining.com/modulos/twin-model/ Poner en el mismo mapa lo que se mueve en la faena —los camiones y su ciclo de acarreo— y lo que se construye —el crecimiento del muro—; hoy, sobre una simulación, con la visualización lista para conectarse a la fuente de posiciones del operador. ### El problema El depósito de relaves no vive aislado de la mina: el muro se levanta con material que acarrean los mismos camiones que trabajan el rajo, y la obra del muro compite por esa flota. Sin embargo, la flota se mira en un sistema, la obra en los planos del contratista y el depósito en el suyo. Nadie tiene una vista donde se vea, a la vez, cuántos camiones están descargando en el muro y cuánto le falta al tramo que se está rellenando. Y el crecimiento del muro, que es la obra más sensible de la instalación, se sigue en informes periódicos: corte y relleno, compactación por lote, avance por tramo. Informes que llegan tarde y que no se comparan con facilidad unos con otros. Twin Model, dentro de Twin Mining TMS, es la visualización de esas dos cosas sobre el mismo mapa. Está construida y lista para conectarse a la fuente de posiciones del operador; hoy corre sobre una simulación, y lo decimos antes de que lo pregunten. ### Qué hace - **La faena entera en un mapa (visualización simulada).** Mapa de toda la faena con la flota de camiones, su estado en el ciclo de acarreo —cargando, en ruta cargado, descargando, en ruta vacío, detenido— y los indicadores del turno por faena y por zona. Hoy la flota es una simulación determinista: se enseña como capacidad de visualización, nunca como flota real en operación. - **La geometría del depósito es real.** El contorno del muro y de las lagunas está dibujado sobre la imagen satelital, generado desde el levantamiento de la instalación, no desde un dibujo. - **Recuento por zona con geocercas.** Cada camión se asigna a la zona en la que está —rajo, chancado, botaderos, muro— o queda como en ruta, y los indicadores se suman por zona. El muro del depósito es una zona más de la faena. Sobre la simulación de hoy, el recuento es de camiones simulados. - **La obra del muro, recorrible en el tiempo (simulación).** Vista de obra: avance por tramo, corte y relleno, curvas de nivel, perfil transversal, control de compactación por lote, acarreo al muro y vista 3D, recorribles levantamiento a levantamiento. No hay ningún levantamiento real detrás: es una simulación anclada a las cifras de diseño de un informe de crecimiento. Enseñamos la herramienta, no sus números. - **Medición con perfil de cotas.** Herramienta de medición sobre el mapa con distancia, cota mínima y máxima, subida, bajada y pendiente media. Es el único dato medido de la pantalla y conviene decir de dónde sale: un modelo digital de elevación público de 30 m, con error vertical del orden de ±16 m. Sirve para tener una idea del terreno, no para topografía de obra. - **La fuente de datos es intercambiable.** La pantalla consume un contrato y la fuente —simulada hoy— se cambia por configuración sin tocar la interfaz. La visualización está hecha; conectar la fuente real de posiciones no obliga a rehacerla, y es un proyecto de integración. ### Lo que calcula por su cuenta Es una superficie de lectura. Lo único que calcula por su cuenta es en qué zona está cada camión —geocercas: rajo, chancado, botaderos, muro, o en ruta— y los indicadores que salen de sumar por zona; hoy, sobre posiciones simuladas. Y lo único medido de la pantalla es el perfil de cotas de la herramienta de medición, que consulta un modelo digital de elevación público de 30 m. ### Lo que nunca decide No despacha, no asigna camiones y no dispara alertas. No hay integración con la fuente de posiciones del operador: la flota que se mueve en pantalla es una simulación determinista, y la obra es una simulación anclada a las cifras de diseño de un informe de crecimiento. ### Lo que todavía no hace - La flota es simulada. Todo lo que se mueve en pantalla —camiones, estados, indicadores del turno— sale de una función determinista del tiempo, y la pantalla no lo avisa. Por eso cada imagen de este módulo lleva pie de visualización simulada. - No hay integración con la fuente de posiciones del operador, ni historial ni reproducción de rutas, ni alertas por entrada o salida de zona. La visualización está construida y lista para conectarse; la integración es un proyecto. - La obra es una simulación anclada a cifras de diseño. Los levantamientos, el avance y los lotes son construidos, y no se publica ninguna cifra de esta pantalla: ni toneladas, ni ciclos, ni porcentaje de avance. - Los vídeos de las cámaras de la vista de zona son material de archivo de un banco de imágenes, y sus etiquetas de detección son de demostración. La vista reserva el sitio para las cámaras existentes junto a los indicadores de la zona; nada más. - Los mapas de calor no tienen medición detrás. No los contamos hasta que tengan fuente. ### Preguntas frecuentes **¿Twin Model se conecta con nuestro sistema de despacho de flota?** Hoy no. La visualización de flota está construida y lista para conectarse a la fuente de posiciones del operador; hoy corre sobre una simulación determinista, y la pantalla no lo avisa, así que lo avisamos nosotros. La capa de datos consume un contrato y la fuente se cambia por configuración sin tocar la interfaz, pero la integración es un proyecto, no una casilla. Twin Model no reemplaza un sistema de flota: pone lo que ese sistema ya sabe junto al depósito, con el muro como una zona más de la faena. Lo único medido de la pantalla es el perfil de cotas de la herramienta de medición, que sale de un modelo digital de elevación público de 30 m. **Las cámaras y las etiquetas de detección que se ven en Twin Model, ¿son reales?** No. Los vídeos de las cámaras en la vista de zona son material de archivo de un banco de imágenes, no de la instalación, y las etiquetas de detección son de demostración. La vista reserva el sitio para las cámaras existentes junto a los indicadores de la zona; nada más. Lo mismo vale para todo lo que se mueve en la pantalla: la flota, sus estados y los indicadores del turno son una simulación, y la obra del muro es una simulación anclada a cifras de diseño. Por eso ninguna imagen de Twin Model se publica sin pie de visualización simulada, y ninguna cifra de esa pantalla se publica. **¿Cómo se integran los datos desde instrumentación, sensores y otros sistemas?** La capa de datos de Twin Mining TMS usa adaptadores intercambiables por fuente: la pantalla consume un contrato y la fuente —instrumentación geotécnica y geoquímica, sensores, sistemas corporativos— se cambia por configuración sin tocar la interfaz. Hay además una API para integración; no hay camino de escritura hacia sistemas de control. Cada integración es un trabajo, no una casilla: hay que acordar con el operador qué fuente, qué frecuencia y qué unidad. Lo decimos antes para que nadie llegue a la primera reunión esperando una conexión automática. Las integraciones se implementan de forma incremental, fuente por fuente, sin detener lo que ya funciona. ## Base de Conocimiento URL: https://twin-mining.com/modulos/base-de-conocimiento/ Convertir la carpeta de informes técnicos de un depósito —estudios de estabilidad, auscultación, planes de cierre, manuales, protocolos, TARPs— en algo que se pregunta y que responde citando la página. ### El problema El conocimiento de una instalación está en documentos que nadie vuelve a abrir. No porque no importen: porque encontrar la respuesta exige saber en qué informe está, y eso lo sabe la persona que lo escribió. Cuando esa persona cambia de proyecto, el documento sigue en la carpeta y el conocimiento no. Y hay un problema debajo, más silencioso: nadie sabe qué versión manda. La misma carpeta tiene el informe en revisión B, el mismo en C, y el aprobado. Un TARP que apunta a la revisión equivocada es un procedimiento correcto ejecutado sobre un umbral que ya no existe. Twin Mining TMS ingesta el corpus una vez —conversión a PDF, archivo del original, metadatos transcritos de la portada— y a partir de ahí es indexable, buscable y citable. El asistente propone una respuesta, cita el documento y la página, y firma; la persona decide qué hacer con ella. ### Qué hace - **Control de revisiones del oficio.** Un documento recorre las letras A, B, C mientras está en revisión y llega a 0 cuando el cliente lo firma y valida. El 0 es terminal: un cambio posterior es un documento nuevo que empieza en A y apunta al que reemplaza. Es como trabaja de verdad la ingeniería de relaves. - **La cita lleva página.** Se pregunta en lenguaje natural y la respuesta cita el documento y la página de la que sale, no solo el nombre del archivo. Es la diferencia entre una respuesta y una pista, y se verifica en un clic. - **Nada se deriva.** Ningún metadato se inventa. Título, fecha y tipo se transcriben de la portada del documento, no del nombre del archivo, y un campo que nadie escribió aparece vacío en vez de rellenarse con un valor plausible. En un módulo cuya salida se usa como evidencia, inventar un metadato es peor que no tenerlo. - **Las figuras salen del PDF y siguen siendo objetos.** Las figuras y los gráficos se extraen de los documentos y quedan direccionables: se pueden abrir, combinar entre sí y usar como base de un gráfico nuevo. - **Un grafo que se recorre.** Un grafo de conocimiento une documentos, estudios y personas por sus relaciones declaradas, y deja recorrer desde un informe hasta lo que lo reemplazó o lo que lo cita. - **Tres asesores, un motor.** Asesor de protocolos, asesor técnico y cumplimiento GISTM son tres configuraciones del mismo motor de consulta sobre el corpus, no tres productos. Cada uno propone, cita el documento y la página, y firma; la persona decide. ### Lo que calcula por su cuenta Responde y cita. Cada afirmación del asistente arrastra el documento y la página de la que salió, y la interfaz muestra las fuentes al lado de la respuesta, no debajo en letra pequeña. El panel de fuentes tiene sitio propio y permanente, incluso vacío. ### Lo que nunca decide No decide qué es verdad, no aprueba nada y no cambia el estado de nada. Y no deriva: un campo que nadie escribió se muestra vacío. Una versión anterior fabricaba metadatos plausibles a partir de un identificador; la pantalla se veía completa y era ficción. ### Lo que todavía no hace - En la demo el corpus es un catálogo simulado, reproducible byte a byte y sin ninguna llamada de red. Es una decisión de presentación, no una limitación del producto — pero ninguna captura muestra documentos de un cliente. Un informe técnico identifica la instalación en la portada. - «Tres asesores» son tres configuraciones del mismo motor. No son tres inteligencias artificiales especializadas. - El asistente responde y cita. No decide, no aprueba y no cambia el estado de nada. Los modelos se equivocan; por eso la cita con página se verifica en un clic y el módulo prefiere el campo vacío al campo plausible. - Las capturas de la búsqueda y del asistente enseñan la disposición, no una respuesta en curso: se fotografían recién abiertas. ### Preguntas frecuentes **¿Qué documentos acepta la Base de Conocimiento y cómo maneja las revisiones?** Los documentos que vive un depósito de relaves: estudios de estabilidad, informes de auscultación, planes de cierre, manuales de operación y de instrumento, protocolos de emergencia y TARPs. La ingesta convierte cada documento a PDF, archiva el original y transcribe título, fecha y tipo desde la portada, no desde el nombre del archivo; derivarlos producía títulos inventados que después contaminaban las citas. El control de revisiones es el del oficio: un documento recorre las letras A, B, C mientras está en revisión y llega a 0 cuando el cliente lo firma y valida. El 0 es terminal. Un cambio posterior es un documento nuevo que empieza en A y apunta al que reemplaza, así que siempre se sabe qué versión manda. **Los modelos de lenguaje inventan. ¿Cómo sé que una respuesta de la Base de Conocimiento es cierta?** Es exactamente la objeción correcta, y la respuesta está construida en el módulo. El asistente propone una respuesta y cita el documento y la página de la que sale, no solo el nombre del archivo; la cita se verifica en un clic, y el panel de fuentes tiene sitio propio y permanente al lado de la respuesta, incluso vacío. Una persona decide qué hacer con ella. Y hay una regla que gobierna el módulo entero: nada se deriva. Un campo que nadie escribió aparece vacío en vez de rellenarse con un valor plausible. El asistente no decide qué es verdad, no aprueba nada y no cambia el estado de nada. **¿La inteligencia artificial de Twin Mining toma decisiones por sí sola?** No. Los agentes proponen y citan; las personas deciden. No es una política declarada: está en el modelo de datos. Una sugerencia de agente entra en un estado que bloquea hasta que una persona la confirme, y esa confirmación es un segundo evento con su autor y su fecha. Un agente nunca participa en la evaluación de transiciones de estado, y todo veredicto queda firmado con el modelo y la versión de prompt que lo produjo, de modo que un revisor externo puede reconstruir de dónde salió. Tampoco se infiere nada de la nada: cada relación del grafo de impacto corresponde a una relación real del modelo de datos y declara si es declarada o derivada. Primero el cálculo determinista, después la narración del modelo — invertir ese orden sería que el modelo invente el patrón y nadie pueda comprobarlo. ## Operacional URL: https://twin-mining.com/modulos/operacional/ Responder la pregunta que ordena la operación de un depósito —cuánta agua entra, cuánta sale y cuánta queda— y ver las tuberías que llevan el relave y el agua: por dónde van, qué equipos tienen y qué dicen sus instrumentos. ### El problema El balance de agua de un depósito vive, en la mayoría de las operaciones, en una planilla que una persona actualiza. Es una planilla buena —normalmente lleva años de trabajo dentro— y tiene tres problemas que no se arreglan mejorándola: solo la entiende quien la mantiene, el dato de origen se copia a mano, y no está donde está el resto de la conversación. Cuando la revancha se acorta, la discusión se hace sobre una captura de pantalla de esa planilla pegada en un correo. Con las tuberías pasa algo parecido. Son kilómetros de línea con bombas, cajones y cámaras de caída, y su estado se consulta en el sistema de control punto por punto: el caudal de una bomba en una pantalla, la presión de un tramo en otra. Nadie ve la línea entera, con sus equipos en orden y el instrumento que falla señalado en su sitio. Twin Mining TMS pone el balance y las tuberías en el mismo sitio donde están las alertas, las tareas y el documento que justifica cada banda. Un caudal sin su banda es una cifra, no una alarma. ### Qué hace - **Balance de agua en cascada.** Entradas, salidas y el resultado, en una sola lectura, en vez de repartidos por una planilla. En la misma pantalla que las alertas y las tareas. - **El circuito se dibuja.** El circuito de relaves se representa como un diagrama esquemático navegable, con nodos de depósito y de unión y aristas de flujo animadas. La mayoría de las herramientas del sector muestran tablas de puntos de medición; aquí el flujo tiene forma. - **Rendimiento y alertas sobre el mapa.** Los elementos operacionales, coloreados por su banda de umbral, y los trazados de las tuberías sobre el mapa de la instalación; cada punto abre su serie. En la demo conviven sensores de prueba con serie simulada. - **Tuberías con su trazado real.** Las tuberías de relave, retorno de agua y drenaje están dibujadas con su trazado real sobre la instalación, agrupadas por sistema, y cada una tiene su ficha con longitud, rectitud, azimut e instrumentos asociados. El trazado sale del levantamiento, no de un dibujo. - **Esquema de proceso por tubería.** Cada tubería tiene un esquema con sus equipos —cajones, cámaras de caída, bombas, empalmes— y sus instrumentos coloreados por banda. Los equipos van en orden, no a escala, y la pantalla lo dice; lo que sí es real es el largo de cada tramo, rotulado. No es un plano de ingeniería. - **Los instrumentos se asocian solos.** Los instrumentos se asocian solos a la tubería que tienen cerca y se sitúan en su kilometraje real, con su separación del eje. Nadie mantiene a mano la lista de qué sensor pertenece a qué línea. - **Fuente de datos intercambiable por configuración.** La interfaz consume un contrato —lecturas, resumen, balance, topología— y no sabe de dónde vienen los datos. Detrás hay adaptadores intercambiables; hay tres implementaciones. Conectar el historiador de un cliente no obliga a reescribir una pantalla, pero cada conexión concreta es un trabajo de integración, no una casilla. ### Lo que calcula por su cuenta Presenta. Cuando un sensor no tiene umbral configurado, deriva bandas de su propia serie con la misma forma que un umbral real —y sabe que para revancha, factor de seguridad y resistencia el lado peligroso es el bajo, así que las espeja—. Eso no es una recomendación operacional: es un valor de referencia para que un número no aparezca desnudo en pantalla, y la interfaz no lo presenta como un umbral aprobado. ### Lo que nunca decide No decide nada sobre la operación. Los umbrales los define una persona, y cambiarlos está sujeto al candado de gestión del cambio —hoy en modo observación—. No modela el flujo, no detecta fugas y no actúa sobre bombas ni válvulas: no hay ningún camino de escritura hacia sistemas de control. ### Lo que todavía no hace - Cinco de las nueve entradas del menú no están construidas: plan de transporte y deposición, capacidad de almacenamiento, deposición de arena, ambiental y reportes operacionales. No se ven en la demo y no forman parte de lo que se enseña. - No hay perfil hidráulico, cálculo de pérdidas de carga, detección de fugas ni control de bombas y válvulas. La pantalla dibuja el trazado, ordena los equipos y enseña lecturas; no modela el flujo ni actúa sobre nada. Que no exista camino de escritura hacia el sistema de control es, además, la propiedad de seguridad más valiosa del módulo. - En la demo, todo sensor sin lecturas recibe una serie simulada determinista que nunca pisa un dato real. En el esquema de proceso se marca con borde discontinuo y la etiqueta «Simulado»; en el mapa principal de rendimiento hay sensores de prueba antiguos sin esa marca. Ninguna captura es telemetría en vivo. - La arquitectura está preparada para conectar el historiador del cliente. Cada integración concreta sigue siendo un trabajo; no la prometemos como inmediata. - El pronóstico del balance de agua se ve en el menú y está deshabilitado en la demo. ### Preguntas frecuentes **¿Twin Mining TMS se conecta a mi historiador o a mi sistema de control?** La capa de datos está diseñada para eso: la interfaz consume un contrato —lecturas de sensor, resumen, balance de agua, topología— y no sabe de dónde vienen los datos. Detrás hay adaptadores intercambiables que se eligen por configuración, y existen tres implementaciones. Enchufar el historiador de un cliente no obliga a reescribir una sola pantalla. Pero cada conexión concreta es un trabajo de integración, no una casilla que se marca. No la prometemos como inmediata. Y no hay ningún camino de escritura hacia el sistema de control: la plataforma lee y presenta, no actúa sobre bombas ni válvulas. Esa es, además, su propiedad de seguridad más valiosa. El historiador tiene la serie. Lo que no tiene es la banda, la tarea ni el documento que justifica la banda; eso es lo que la plataforma añade. **¿El esquema de tuberías es un modelo hidráulico? ¿Detecta fugas?** No. La pantalla dibuja el trazado real de cada tubería —sale del levantamiento—, ordena sus equipos y enseña las lecturas de sus instrumentos coloreadas por banda de umbral. No modela el flujo, no calcula pérdidas de carga, no detecta fugas ni obstrucciones y no controla bombas ni válvulas. El esquema de proceso va en orden, no a escala, y la pantalla lo dice; lo que sí es real es el largo de cada tramo, que va rotulado. No es un plano de ingeniería. Lo que aporta es otra cosa: una línea de veinte kilómetros que se lee de un vistazo, con el instrumento fuera de banda señalado en su kilómetro y no en una lista. **¿Cómo se integran los datos desde instrumentación, sensores y otros sistemas?** La capa de datos de Twin Mining TMS usa adaptadores intercambiables por fuente: la pantalla consume un contrato y la fuente —instrumentación geotécnica y geoquímica, sensores, sistemas corporativos— se cambia por configuración sin tocar la interfaz. Hay además una API para integración; no hay camino de escritura hacia sistemas de control. Cada integración es un trabajo, no una casilla: hay que acordar con el operador qué fuente, qué frecuencia y qué unidad. Lo decimos antes para que nadie llegue a la primera reunión esperando una conexión automática. Las integraciones se implementan de forma incremental, fuente por fuente, sin detener lo que ya funciona. **¿Qué es un TARP en la gestión de depósitos de relaves?** TARP significa Trigger Action Response Plan. Son las bandas de umbral de un instrumento —verde, amarillo, rojo— y la respuesta definida para cada una: qué acciones son obligatorias, quién debe aprobarlas y a quién hay que comunicar. Explicado a alguien de fuera del sector: es el semáforo de un sensor, y qué tiene que pasar cuando cambia de color. En Twin Mining TMS el umbral, la respuesta y el documento que la respalda viven en la misma pantalla, y cambiar un umbral queda bajo expediente formal de gestión del cambio. Esa última conexión es la que separa un TMS de un sistema de monitoreo. ## Estabilidad Física URL: https://twin-mining.com/modulos/estabilidad-fisica/ Que el dato de un instrumento, la banda que lo califica y la respuesta que corresponde a esa banda estén en la misma pantalla, y que el muro se pueda mirar en corte, por secciones transversales, como lo piensa el ingeniero. ### El problema Un depósito bien instrumentado produce muchísimos datos y los interpreta muy poca gente. Los piezómetros, los inclinómetros y los puntos topográficos generan series que alguien revisa periódicamente contra un criterio que está escrito en un informe, en un TARP, en otra parte. El resultado conocido: la lectura anómala existía en el sistema días antes de que alguien la mirara, porque mirarla exigía abrir la serie, recordar el umbral y saber a quién avisar. Y hay un desajuste de forma: el ingeniero piensa el muro en sección —qué hay debajo, a qué profundidad está el piezómetro, en qué estrato—, pero el software de monitoreo lo enseña en planta, como puntos sobre un mapa. La sección vive en un plano del informe de estabilidad, separada de las lecturas. Twin Mining TMS no evalúa la estabilidad. Deja ver antes lo que ya estaba pasando: acorta el tiempo entre que un dato cambia y alguien lo mira, y hace que quien lo mira tenga delante el umbral y el protocolo sin buscarlos. ### Qué hace - **La banda viaja con el dato.** Los puntos de instrumentación se ven sobre el mapa de la instalación coloreados por su banda de umbral, y al pulsar uno se abre su serie de tiempo con las bandas dibujadas sobre el gráfico. El estado del conjunto se lee sin abrir nada. - **El cruce de banda ocupa la pantalla.** Cuando un sensor cruza una banda distinta de la verde, la aplicación entera levanta una superficie de situación con los sensores agrupados por color, un medidor de severidad, la serie corta y el mapa del punto. No es una notificación en una campana. - **La criticidad se deriva.** Un instrumento es crítico cuando tiene un umbral TARP colgando de él. No es una casilla que alguien marca: una casilla de criticidad que hay que mantener a mano deja de ser cierta en seis meses. - **El riesgo con las herramientas del oficio.** Matrices FMEA, diagramas de corbatín y el gráfico ALARP de tolerabilidad con sus tres bandas. No una matriz de colores genérica de tres por tres. - **El muro se mira en corte.** El muro se recorre por secciones transversales: cada una tiene su traza real en planta, su perfil por estratos y la instrumentación situada en su avance sobre la traza, con la geometría resumida —altura del muro, cota de coronamiento, cota de pie, longitud y azimut—. Se llega desde el mapa. - **Perfil por estratos, como herramienta.** El perfil muestra los estratos del depósito —arenas, lamas, roca basal, geomembrana, muro— con los instrumentos encima. Hoy está cargado a mano y en escala de dibujo, no en cotas reales, y solo dos secciones lo tienen. Lo que sí es real es la traza en planta: longitud, azimut y extremos. - **Filtro por familia de instrumento.** La instrumentación se filtra por familia —piezómetros, inclinómetros, prismas— sobre el mapa, incluidos los instrumentos instalados dentro de un sondaje. La familia «prismas» se infiere de la variable de desplazamiento. ### Lo que calcula por su cuenta Acorta el tiempo entre que un dato cambia y alguien lo mira. Colorea cada instrumento por su banda, levanta una superficie de situación cuando una lectura cruza una banda distinta de la verde, y deriva la criticidad de un instrumento del hecho de que un umbral TARP cuelgue de él. El juicio sigue siendo humano; lo que cambia es cuánto tarda en poder ejercerse. ### Lo que nunca decide No evalúa la estabilidad ni calcula factores de seguridad. Esa es una pieza de ingeniería que produce el EOR con sus modelos, y que en la plataforma vive como documento en la Base de Conocimiento. El panel de factor de seguridad dice «sin fuente de datos» en vez de inventar una cifra. ### Lo que todavía no hace - El módulo no evalúa estabilidad, no calcula factores de seguridad y no anticipa fallas. Eso lo hace el EOR con sus modelos. El panel de factor de seguridad dice «sin fuente de datos»: es el sitio donde entra el modelo de estabilidad del EOR, no un resultado. - La línea freática de la sección es una visualización esquemática, no un cálculo. No sale de las lecturas de los piezómetros ni de un modelo de filtración; las cifras que la acompañan —gradiente, resguardo— son aritmética sobre esa curva. El interruptor está apagado por defecto. - Los piezómetros de cada sección transversal son sintéticos, y la pantalla no lo marca, por decisión de producto. Ninguna lectura, evolución ni banda de esa pantalla se presenta como medida. Enseñamos la herramienta, nunca lo que dice. - Cambiar un umbral TARP queda bajo expediente de gestión del cambio, y ese candado está hoy en modo observación: registra la violación, no la impide. Es a propósito, porque todos los umbrales existentes son anteriores al módulo. - La pantalla geotécnica, los sensores y el CCTV existen y están ocultos en la demo. Se pueden mencionar como alcance, no mostrar. ### Preguntas frecuentes **¿Twin Mining TMS calcula el factor de seguridad del muro?** No. La estabilidad la evalúa el Engineer of Record con sus modelos, y ese análisis vive en la plataforma como documento en la Base de Conocimiento. El panel de factor de seguridad de cada sección transversal dice, con todas las letras, «sin fuente de datos»: es el sitio donde entra el modelo de estabilidad del EOR, no un resultado que la plataforma produzca. Lo que el módulo hace es más modesto y más útil de lo que suena: pone la instrumentación, su umbral y la respuesta del protocolo en la misma pantalla, y acorta el tiempo entre que un dato cambia y alguien lo mira. El EOR sigue diciendo lo que dice; lo que cambia es cuánto tarda su criterio en llegar a la pantalla de quien opera. **Las lecturas que se ven en la sección transversal, ¿son de un depósito real?** No. Todas las capturas salen de un ambiente de demostración, y en la sección transversal conviene ser especialmente preciso: la traza en planta es real —longitud, azimut y extremos—, pero el perfil por estratos está cargado a mano en escala de dibujo, los piezómetros de la sección son sintéticos, y la línea freática es una visualización esquemática, no un cálculo a partir de lecturas ni de un modelo de filtración. La pantalla no marca esos piezómetros como simulados, por decisión de producto, así que lo decimos nosotros: ninguna lectura, evolución ni banda de esa pantalla se presenta como medida. Lo que enseñamos es la herramienta —el corte navegable con su estratigrafía y su instrumentación—, nunca lo que dice. **¿Qué es un TARP en la gestión de depósitos de relaves?** TARP significa Trigger Action Response Plan. Son las bandas de umbral de un instrumento —verde, amarillo, rojo— y la respuesta definida para cada una: qué acciones son obligatorias, quién debe aprobarlas y a quién hay que comunicar. Explicado a alguien de fuera del sector: es el semáforo de un sensor, y qué tiene que pasar cuando cambia de color. En Twin Mining TMS el umbral, la respuesta y el documento que la respalda viven en la misma pantalla, y cambiar un umbral queda bajo expediente formal de gestión del cambio. Esa última conexión es la que separa un TMS de un sistema de monitoreo. **¿Twin Mining TMS predice fallas o colapsos del depósito?** No, y conviene decirlo con claridad: la plataforma no contiene ningún modelo que prediga la falla de un depósito de relaves. Cualquier proveedor que lo afirme está haciendo una promesa que un Engineer of Record desmonta en la primera reunión técnica. Lo que sí hace Twin Mining TMS es acortar el tiempo entre que un dato cambia y alguien lo mira: umbrales que un especialista definió, series de tiempo con sus bandas, detección de anomalías sobre el histórico, y agentes que leen la documentación de la instalación y proponen con la fuente citada. La decisión sobre qué significa una desviación y qué hacer con ella sigue siendo de las personas responsables: el RTFE, el EoR y la organización de la faena. ## GISTM URL: https://twin-mining.com/modulos/gistm/ Convertir un estándar de 77 requisitos en un estado consultable: qué se declaró, qué evidencia lo sostiene, quién responde por él y qué revisor externo lo va a mirar y cuándo. ### El problema La autoevaluación GISTM vive hoy en una planilla que una persona actualiza antes de cada revisión. El estado y la evidencia están en sitios distintos —el verde en una celda, el documento en una carpeta compartida—, así que un requisito puede llevar meses en verde apoyado en un informe que caducó, o en uno que nadie firmó. Nadie lo nota hasta que el revisor independiente lo pregunta. Y no es un problema de orden: es un problema de quién puede responder. El estándar exige roles acreditados y vigentes. Cuando el responsable de cumplimiento tiene que explicar de dónde sale un verde, la respuesta honesta suele ser «lo puso alguien que ya no está en el cargo, en una revisión de la que no queda registro». Twin Mining TMS no dice si cumples. Organiza la evidencia con la que se sostiene la conformidad ante un revisor externo, requisito por requisito, y deja ver dónde el estado declarado y la documentación no cuadran. ### Qué hace - **El estándar viene precargado.** 15 principios y 77 requisitos, con sus sub-requisitos, sin que el cliente tenga que transcribirlos. Es la ventaja real de arranque: nadie copia 77 requisitos a una planilla antes de ver nada. - **Tema → principio → requisito, con su evidencia.** Recorre la estructura del estándar y guarda el estado de autoevaluación de cada requisito con la evidencia documental que lo sostiene. La matriz de tema por principio se lee sin texto. - **Declarado contra evidencia, fila a fila.** Una regla determinista —no un juicio del modelo— contrasta el estado declarado con la evidencia adjunta y marca las divergencias en la propia tabla: «Sobredeclarado», «los documentos no lo sostienen». La casilla «Solo divergencias» convierte la tabla en la lista de trabajo. - **Un veredicto de IA con firma.** Un agente lee la evidencia de un requisito, propone un veredicto sobre si de verdad lo prueba, cita el documento y la página, y lo firma con su modelo y su versión de prompt. Se muestra al lado del estado declarado, nunca en su lugar; una persona decide. Si el modelo rompe el formato de salida, la pantalla enseña la prosa en vez de rellenar media tabla. - **El organigrama es un artefacto de cumplimiento.** Cargos, designaciones y su vigencia, con el panel revisor independiente en su propia rama. Un cargo vacío o una designación vencida se ve, y eso es información: el estándar trata el cambio de EOR como un evento de gestión del cambio. - **Comparar instalaciones.** Una vista de cartera compara las instalaciones del ambiente de demostración, con ranking y detección de la brecha que se repite y de la práctica que se puede transferir. El emparejamiento es determinista; el modelo solo redacta cómo transferir la práctica. - **Lecciones aprendidas ligadas al requisito.** Biblioteca de lecciones de incidentes públicos de la industria, ligadas a los requisitos que afectan, con acciones preventivas que se convierten en tarea. Abrir un requisito responde también «¿qué ha aprendido ya la industria sobre esto?». ### Lo que calcula por su cuenta Una regla determinista compara el estado declarado contra la evidencia adjunta —solo mira archivos, fechas y firmas— y marca la divergencia. Sin evidencia, el techo es «Ninguno»; con evidencia sin fecha o sin aprobar, el techo es «Parcial»: tenerlo no es lo mismo que que alguien haya respondido por ello. Además, un agente lee la evidencia, propone un veredicto sobre si de verdad prueba el requisito, y lo firma con su modelo y su versión de prompt. ### Lo que nunca decide No decide si un requisito está conforme. Eso lo declara una persona. El veredicto del agente se muestra al lado del estado declarado, nunca en su lugar, y la conformidad la verifica un revisor independiente, no el software. ### Lo que todavía no hace - El software no dice si cumples. La conformidad la declara el operador y la verifica un revisor independiente; lo que hace el módulo es organizar la evidencia con la que se sostiene. - La detección de divergencia es una regla, no la IA. Mira archivos, fechas y firmas. El modelo entra después, a interpretar la evidencia, y firma lo que propone. Fundir las dos cosas vendería algo que el producto no hace de esa forma. - Hoy el estándar viene precargado y no es configurable: requisitos, escalas y periodicidades no se adaptan a un marco interno. Es una ventaja de arranque y una limitación real. - Hay pestaña de auditoría; los reportes por perfil (directorio, EOR, regulador) todavía no. Lo que existe es la matriz de conformidad y el paquete de evidencia. - «Cartera» en la demo son cuatro instalaciones. Se puede hablar de la mecánica —comparar, rankear, ver la brecha que se repite— sin sugerir una escala que no está. ### Preguntas frecuentes **¿Twin Mining TMS certifica el cumplimiento del GISTM?** No, y ningún software puede hacerlo. La conformidad la declara el operador y la verifica un revisor independiente. Lo que el módulo hace es organizar la evidencia con la que esa conformidad se sostiene ante el revisor externo, requisito por requisito, y dejar ver dónde el estado declarado y la documentación no cuadran. Una consultora produce el informe una vez al año; esto es el estado entre informes, que es lo que el revisor pregunta. Una planilla no sabe que el documento caducó; el módulo sí, porque una regla determinista contrasta el estado declarado con los archivos, las fechas y las firmas adjuntas. **¿Qué hace exactamente el agente de IA en el módulo GISTM? ¿Decide por mí?** No decide. Conviene separar dos cosas que el módulo hace de forma distinta. Primero, una regla determinista —no la IA— compara el estado declarado contra la evidencia adjunta, mirando solo archivos, fechas y firmas, y marca la divergencia. Segundo, un agente lee la evidencia de un requisito, propone un veredicto sobre si de verdad lo prueba, cita el documento y la página, y lo firma con su modelo y su versión de prompt. El veredicto se muestra al lado del estado declarado, nunca en su lugar; una persona decide. Y si el modelo rompe el formato de salida, la pantalla enseña la prosa en vez de rellenar media tabla: una fila inventada en una pantalla de cumplimiento es peor que ninguna fila. **¿Qué es el GISTM y qué exige a los operadores de relaves?** El GISTM (Global Industry Standard on Tailings Management) es el estándar global de gestión de relaves publicado en 2020 tras el colapso de Brumadinho. Se estructura en 6 tópicos, 15 principios y 77 requisitos, y los grandes operadores mineros se comprometieron públicamente a adherir a él. Exige, entre otras cosas, una base de conocimiento interdisciplinaria de la instalación, un Engineer of Record (EoR) designado y empoderado, un Responsible Tailings Facility Engineer (RTFE), un panel revisor independiente (ITRB), y evidencia trazable de que cada requisito se evaluó y por quién. La conformidad la declara el operador y la verifica un revisor independiente: ningún software puede certificarla. Lo que Twin Mining TMS hace es organizar la evidencia con la que esa conformidad se sostiene ante el revisor externo, requisito por requisito. **¿Twin Mining Tailings está alineado con estándares internacionales como GISTM?** Sí. La plataforma está alineada con los principios del Global Industry Standard on Tailings Management (GISTM) y ayuda a operacionalizar la autoevaluación de sus 77 requisitos. Twin Mining Tailings estructura procesos, controles, evidencias y flujos de trabajo para evaluar la adherencia a los 15 principios con trazabilidad, disciplina operacional y evidencia auditable, y hace visible la distancia entre lo que ya se puede sostener y lo que todavía no. Ningún software certifica ni garantiza la conformidad GISTM: la declara el operador y la verifica un revisor independiente. Lo que la plataforma organiza es la evidencia con la que esa declaración se defiende. ## Gestión del Cambio URL: https://twin-mining.com/modulos/gestion-del-cambio/ Que ningún cambio que altere el riesgo de la instalación ocurra sin que alguien lo evalúe y alguien distinto lo autorice, y que dentro de dos años se pueda reconstruir quién decidió qué, cuándo, con qué información a la vista y bajo qué autoridad. ### El problema Un cambio en la tasa de deposición, en el nivel de la laguna, en un umbral TARP o en el ingeniero responsable altera el riesgo del depósito aunque no se mueva un metro cúbico de tierra. Sin expediente, esos cambios ocurren como ediciones de catálogo: alguien cambia un valor en una pantalla, nadie evalúa el efecto, y la revisión siguiente encuentra un TARP apuntando a un instrumento que ya no existe. Y hay un segundo problema, el que se paga en la auditoría: la decisión existió, pero el contexto de la decisión no se guardó. Se sabe quién firmó. No se sabe qué tenía delante cuando firmó. Lo normal hoy es un procedimiento en papel y una carpeta compartida. El procedimiento existe; la pregunta es si el expediente sobrevive a la rotación de las personas que lo ejecutaron. Twin Mining TMS trata cada cambio como un expediente que se puede defender. ### Qué hace - **Expediente formal de trece estados.** Cada cambio que altera el riesgo de la instalación recorre un flujo de trece estados, desde borrador hasta cierre: tamizaje regulatorio, evaluación de impacto, conformidad del EOR, aprobación, autorización, ejecución, verificación. El orden de la lista es el orden del trabajo. - **Segregación de funciones sin excepciones.** Quien pide no aprueba; quien ejecuta no verifica. No existe ningún camino de administrador que se lo salte, y hay una prueba automática que vigila que no aparezca. - **El nivel de aprobación se calcula y se justifica.** Un motor de reglas calcula quién tiene que firmar y devuelve qué regla lo produjo. Una escalada automática se puede justificar ante un auditor señalando la fila que la causó. - **«No aplica» es una evaluación firmada.** La matriz de impacto tiene ocho dimensiones fijas. El sistema distingue entre decidir que algo no aplica y que nadie lo haya mirado; en una planilla las dos cosas se ven iguales. - **Registro a prueba de manipulación silenciosa.** Los eventos van encadenados por huella, por instalación y no por expediente, con un verificador que devuelve un informe y no un booleano. No decimos que el registro sea inalterable: decimos que si alguien lo toca, se nota y se ve dónde. - **Paquete de auditoría por pregunta.** Se exporta estructurado por pregunta y no por tabla: qué, quién, cuándo, con qué información a la vista, bajo qué autoridad y con qué integridad. Sale en PDF para firmar, JSON para reverificar las huellas y texto para comparar. - **Grafo de impacto: nada se infiere de la nada.** Al proponer un cambio, el sistema muestra qué instrumentos, umbrales, documentos y procedimientos quedan afectados. Cada arista corresponde a una relación real del modelo de datos y declara si es declarada o derivada; ninguna la inventa un modelo de lenguaje. El resultado inicia el expediente, no lo salta. ### Lo que calcula por su cuenta Decide qué se puede hacer ahora y qué falta. Calcula quién tiene que firmar —el nivel de aprobación es una conclusión de un motor de reglas, no una elección— y se ocupa de que la persona que aprueba no sea la misma que pidió. ### Lo que nunca decide No decide si un cambio es buena idea: eso lo firma una persona. Y un agente nunca aparece en la evaluación de transiciones: escribe eventos de sugerencia, y solo la confirmación humana, que es un segundo evento con su autor y su fecha, mueve el estado. ### Lo que todavía no hace - El candado de umbrales TARP está hoy en modo observación: registra la violación, no la impide. Es a propósito: todos los umbrales existentes son anteriores al módulo, y activarlo dejaría la pantalla bloqueada para el equipo entero. El período de observación compra la evidencia. - Hoy nadie puede firmar un cambio, porque las designaciones de cargo no tienen persona asignada. Se puede crear, avanzar, ejecutar y cancelar; firmar, no. Y es deliberado: un rol de plataforma nunca se convierte en autoridad técnica. - No decimos que el registro sea inalterable. Eso sería más débil y además falso. Decimos que es a prueba de manipulación silenciosa: si alguien lo reescribe, se nota y se ve dónde. - Inspecciones y Mantenimiento se ven en el menú y no abren. No forman parte de lo que se enseña. ### Preguntas frecuentes **¿Quién firma un cambio en Twin Mining TMS, y puede firmarlo un administrador?** Firma la persona que ocupa el cargo que corresponde al nivel de aprobación, y ese nivel no lo elige nadie: lo calcula un motor de reglas que devuelve qué regla lo produjo. Quien pide no aprueba y quien ejecuta no verifica. No existe ningún camino de administrador que se salte esa segregación, y hay una prueba automática que falla si aparece uno. Hoy, además, nadie puede firmar todavía: las designaciones de cargo no tienen persona asignada. Se puede crear, avanzar, ejecutar y cancelar un cambio; firmarlo, no. Es deliberado: un rol de plataforma nunca se convierte en autoridad técnica. Un agente de IA tampoco firma: propone, cita y firma su propuesta con modelo y versión de prompt, y una persona decide. **¿El grafo de impacto lo genera la inteligencia artificial?** No, y es justo lo contrario de lo que lo hace fiable. Al proponer un cambio, el sistema muestra qué instrumentos, umbrales, documentos y procedimientos quedan afectados, y cada arista del grafo corresponde a una relación real del modelo de datos: una clave foránea, una tabla puente, un índice. Ninguna la inventa un modelo de lenguaje, y cada una declara si es declarada o derivada. El resultado inicia el expediente de gestión del cambio; no lo salta. El botón dice «generar flujo de cambio», no «aplicar». **¿Qué es un TARP en la gestión de depósitos de relaves?** TARP significa Trigger Action Response Plan. Son las bandas de umbral de un instrumento —verde, amarillo, rojo— y la respuesta definida para cada una: qué acciones son obligatorias, quién debe aprobarlas y a quién hay que comunicar. Explicado a alguien de fuera del sector: es el semáforo de un sensor, y qué tiene que pasar cuando cambia de color. En Twin Mining TMS el umbral, la respuesta y el documento que la respalda viven en la misma pantalla, y cambiar un umbral queda bajo expediente formal de gestión del cambio. Esa última conexión es la que separa un TMS de un sistema de monitoreo. **¿La inteligencia artificial de Twin Mining toma decisiones por sí sola?** No. Los agentes proponen y citan; las personas deciden. No es una política declarada: está en el modelo de datos. Una sugerencia de agente entra en un estado que bloquea hasta que una persona la confirme, y esa confirmación es un segundo evento con su autor y su fecha. Un agente nunca participa en la evaluación de transiciones de estado, y todo veredicto queda firmado con el modelo y la versión de prompt que lo produjo, de modo que un revisor externo puede reconstruir de dónde salió. Tampoco se infiere nada de la nada: cada relación del grafo de impacto corresponde a una relación real del modelo de datos y declara si es declarada o derivada. Primero el cálculo determinista, después la narración del modelo — invertir ese orden sería que el modelo invente el patrón y nadie pueda comprobarlo. ## Agentes URL: https://twin-mining.com/modulos/agentes/ Poner el conocimiento que ya está escrito —protocolos, TARPs, manuales, informes— a trabajar en el momento en que hace falta: cuando tiembla, cuando un sensor cruza una banda, cuando alguien necesita un gráfico que hoy pediría por correo. ### El problema Un depósito de relaves tiene el procedimiento para casi todo. El problema no es que falte: es el tiempo entre el evento y el procedimiento. A las tres de la madrugada, después de un sismo, alguien tiene que acordarse de qué TARP aplica, encontrarlo, leer qué nivel corresponde a esa magnitud y a esa distancia, y avisar a quien toca. Ese intervalo se llena de llamadas. Y la parte que se pierde no es la acción —al final se hace— sino el registro: qué se miró, con qué información a la vista, y quién decidió. Los agentes de Twin Mining TMS no predicen nada. Hacen algo más útil: encuentran el procedimiento que ya escribiste, lo recorren en el momento en que hace falta, proponen, citan el documento y la página, y firman. Una persona decide. ### Qué hace - **Proponen, citan y firman; no deciden.** Los agentes proponen, citan la fuente con documento y página, y firman con su modelo y su versión de prompt. Nunca deciden: la confirmación humana es un evento aparte y solo ese mueve el estado. - **El razonamiento y la cita son protocolo, no adorno.** El razonamiento del agente y sus citas son eventos de primera clase del canal —arranque, pensamiento, texto, cita, fin—, no texto pegado al final. La pantalla los muestra según llegan. - **Respuesta post-sísmica sobre el TARP que ya existía.** Ante un evento sísmico, el agente recorre el TARP post-sísmico por sus niveles y propone las acciones del protocolo que corresponde, con el registro del evento y los sensores afectados. El umbral y la respuesta, en la misma pantalla; la decisión, de la persona. - **Analista de datos conversacional.** Trabaja sobre los datos del depósito y produce gráficos y hojas dentro de la misma pantalla, sin salir a otra herramienta. La consulta pasa por el despachador de agentes especializados, no por consultas libres contra la base. - **Registro de auditoría de los agentes.** Hay un registro de lo que hicieron los agentes, con el nombre del agente, el modelo y la versión de prompt de cada corrida. Un veredicto sin versión de prompt sería una opinión anónima. ### Lo que calcula por su cuenta Prepara. Lee el corpus por tipo de documento, los sensores y sus bandas, el catálogo sísmico público, el estándar y sus requisitos; recorre el protocolo que corresponde y propone las acciones. Todo lo que hace queda con su nombre, su modelo y su versión de prompt en el registro, así que una propuesta de hace tres meses se puede atribuir y por lo tanto discutir. ### Lo que nunca decide Nada. Y no por prudencia comercial: por arquitectura. En gestión del cambio, la sugerencia de un agente entra en un estado que bloquea hasta que una persona la confirme, y esa confirmación es un segundo evento con su autor y su fecha. Un agente nunca aparece en la evaluación de transiciones de estado. ### Lo que todavía no hace - No predicen, no detectan ni anticipan una falla. Leen documentos, series y catálogos sísmicos públicos, y recorren un protocolo que una persona escribió. Es la prohibición que más cuesta respetar, y lo que hay es mejor de defender. - El agente no ejecuta: no crea el cambio, no mueve el estado, no notifica al equipo. Prepara el expediente y lo deja en borrador para que una persona lo firme. Es una decisión de arquitectura, no una carencia. - En la demo, de los eventos naturales solo abre sismo. Lluvia y rebalse existen construidos, se ven en el selector y están deshabilitados: una demostración en vivo enseña uno, no tres. - Si el modelo rompe el formato de salida, la pantalla enseña la prosa. Nunca rellena media tabla: una fila inventada en una pantalla de cumplimiento es peor que ninguna fila. ### Preguntas frecuentes **¿Quién responde si un agente de IA de Twin Mining se equivoca?** La misma persona que respondía antes. El agente no cambió quién firma; cambió cuánto tarda en tener el protocolo delante. Los agentes proponen, citan el documento y la página, y firman con su modelo y su versión de prompt. Nunca deciden: en gestión del cambio, una sugerencia entra en un estado que bloquea hasta que una persona la confirme, y esa confirmación es un segundo evento con su autor y su fecha. Un chatbot no queda en un registro encadenado con su versión de prompt, ni entra en un flujo que lo bloquea hasta que alguien confirme. Aquí, una propuesta de hace tres meses se puede atribuir a un agente, un modelo y una versión concreta, y por lo tanto se puede discutir. **¿Qué hace el agente de eventos naturales después de un sismo?** Recorre el protocolo que ya existía, en el momento en que hace falta, sin que nadie busque el PDF. Ante un evento sísmico, el agente recorre el TARP post-sísmico por sus niveles y propone las acciones del protocolo que corresponde, con el registro del evento y los sensores afectados. El umbral y la respuesta quedan en la misma pantalla; la decisión, y la firma, siguen siendo de la persona. No predice ni detecta una falla: lee documentos, series y el catálogo sísmico público, y sigue un protocolo que una persona escribió. En la demo solo abre el evento de sismo; lluvia y rebalse existen construidos y se ven en el selector, pero están deshabilitados. **¿La inteligencia artificial de Twin Mining toma decisiones por sí sola?** No. Los agentes proponen y citan; las personas deciden. No es una política declarada: está en el modelo de datos. Una sugerencia de agente entra en un estado que bloquea hasta que una persona la confirme, y esa confirmación es un segundo evento con su autor y su fecha. Un agente nunca participa en la evaluación de transiciones de estado, y todo veredicto queda firmado con el modelo y la versión de prompt que lo produjo, de modo que un revisor externo puede reconstruir de dónde salió. Tampoco se infiere nada de la nada: cada relación del grafo de impacto corresponde a una relación real del modelo de datos y declara si es declarada o derivada. Primero el cálculo determinista, después la narración del modelo — invertir ese orden sería que el modelo invente el patrón y nadie pueda comprobarlo. **¿Twin Mining TMS predice fallas o colapsos del depósito?** No, y conviene decirlo con claridad: la plataforma no contiene ningún modelo que prediga la falla de un depósito de relaves. Cualquier proveedor que lo afirme está haciendo una promesa que un Engineer of Record desmonta en la primera reunión técnica. Lo que sí hace Twin Mining TMS es acortar el tiempo entre que un dato cambia y alguien lo mira: umbrales que un especialista definió, series de tiempo con sus bandas, detección de anomalías sobre el histórico, y agentes que leen la documentación de la instalación y proponen con la fuente citada. La decisión sobre qué significa una desviación y qué hacer con ella sigue siendo de las personas responsables: el RTFE, el EoR y la organización de la faena. ## Preguntas frecuentes **¿Qué es un TMS (Tailings Management System)?** Un TMS (Tailings Management System, o Sistema de Gestión de Relaves) es el sistema donde vive el conocimiento y las decisiones de un depósito de relaves: consolida el dato operacional y de instrumentación, estructura los flujos de trabajo que un operador está obligado a ejecutar —gestión del cambio, autoevaluación de cumplimiento, inspecciones, acciones correctivas— y conserva la evidencia auditable de todo ello. Se diferencia de una plataforma de monitoreo en el alcance: el monitoreo muestra el dato; el TMS conecta ese dato con su umbral, la respuesta definida para ese umbral y el documento que la sostiene, y deja registrado quién decidió qué y cuándo. Twin Mining TMS es una plataforma de esta categoría, orientada a depósitos de relaves de la minería del cobre y metálica. **¿Para qué roles está diseñado Twin Mining TMS?** Para los roles que responden por un depósito de relaves, cada uno con una entrada distinta a la plataforma: el RTFE (responsable operacional de la instalación), el EoR o Engineer of Record (responsable del diseño), el responsable de cumplimiento corporativo, el Dam Owner o Accountable Executive que responde ante el directorio, el ingeniero geotécnico, el jefe de faena o de turno, y el revisor independiente o auditor. La plataforma habla el idioma del oficio —TARP, revancha, ITRB, ALARP, FMEA, EMAC, DS 248— porque esa es la diferencia entre que un EoR crea que entendemos su trabajo en los primeros treinta segundos y que no. **¿Twin Mining Tailings reemplaza mis sistemas actuales de monitoreo o gestión?** Twin Mining Tailings puede integrarse con sistemas existentes o reemplazar parcial o totalmente plataformas actuales, según la arquitectura del cliente, la redundancia disponible y las decisiones técnicas de cada operación. En muchas organizaciones hoy conviven herramientas superpuestas para monitoreo, visualización y registro. Eso genera fricción, reprocesos y dispersión de la información. El TMS puede consolidar esas funciones en un punto central de gestión del depósito. Cuando se mantienen sistemas existentes, la plataforma actúa como capa de articulación y gestión, integrando datos desde instrumentación, plataformas especializadas y sistemas corporativos. Cuando existe redundancia funcional, también puede reemplazar sistemas para simplificar la arquitectura tecnológica. El objetivo en ambos escenarios es el mismo: que el dato, su umbral, la respuesta y el documento que la sostiene vivan en el mismo sitio, y que quede registrado quién decidió qué. **¿Cómo se valida lo que dicen los agentes de inteligencia artificial?** Los agentes de Twin Mining TMS no son cajas negras. Cada respuesta cita el documento y la página de donde sale, y cada veredicto queda firmado con el modelo y la versión de prompt que lo produjo. Si no hay fuente, el agente no responde en su lugar. Lo determinista va primero: las relaciones del grafo de impacto y la regla que contrasta lo declarado con la evidencia se calculan sin modelo de lenguaje. El modelo solo redacta por encima, y una persona confirma antes de que nada cambie de estado. Los umbrales, los protocolos y los modos de falla los define y supervisa el equipo de ingeniería del operador con apoyo de ingenieros especialistas en relaves; el software los conserva con su documento de respaldo. **¿La plataforma es escalable para múltiples depósitos y operaciones globales?** Sí. Twin Mining Tailings está diseñado para operar desde un solo depósito hasta portafolios multi-faena y multi-país, manteniendo consistencia técnica y flexibilidad local. La plataforma permite estandarizar criterios, modelos y flujos a nivel corporativo, y adaptarlos a las condiciones específicas de cada depósito. **¿Qué rol cumple el equipo de ingeniería de Twin Mining?** Twin Mining Tailings no es solo una plataforma de software. La solución se complementa con un equipo de ingenieros especialistas en gestión de relaves que acompaña implementación, configuración y evolución del sistema. Este equipo asegura que los modelos representen fielmente la realidad física del depósito, que los umbrales TARPs y controles críticos sean técnicamente correctos, y que la plataforma evolucione junto con los cambios operacionales y de diseño. **¿En qué se diferencia Twin Mining Tailings de una plataforma de monitoreo tradicional?** Las plataformas tradicionales se enfocan principalmente en visualizar datos. Twin Mining Tailings es un Tailings Management System (TMS) que integra monitoreo, operación, riesgo y gobernanza en un sistema único. La plataforma no solo muestra información: estructura la gestión diaria del depósito, conecta eventos, decisiones y acciones, y transforma datos dispersos en gestión técnica activa y trazable. La pregunta que ordena el diseño del producto es una sola: ¿podría un auditor externo reconstruir quién decidió qué, cuándo, con qué información a la vista y bajo qué autoridad? Un sistema de monitoreo responde la primera mitad; un TMS responde la pregunta completa. **¿Twin Mining Tailings cumple con la normativa chilena y sus programas (SERNAGEOMIN)?** Twin Mining Tailings está diseñado para facilitar el cumplimiento del Programa Tranque y del Observatorio Nacional de Relaves en Chile, integrando requerimientos de los módulos M1 y M2, y alineándose con guías técnicas nacionales e internacionales, incluido el DS 248. Módulo M1 - Inspección y operación: permite ejecutar y registrar inspecciones operacionales diarias en forma digital, estructurada y trazable, con evidencia, responsables y disponibilidad inmediata para revisión o fiscalización. Módulo M2 - Monitoreo y control: integra la información de monitoreo requerida, con continuidad, validación de datos y series con sus bandas, para que una desviación se vea cuando ocurre y quede registrado quién la miró. EMAC - Estabilidad química y gestión ambiental: soporta calidad y balance de aguas, procesos geoquímicos, monitoreo ambiental y análisis de tendencias con trazabilidad completa. El cumplimiento normativo lo declara y responde el operador; lo que la plataforma aporta es que la evidencia esté ordenada y disponible cuando el fiscalizador la pida, sin aumentar la carga operativa. **¿Twin Mining Tailings es una plataforma modular o una solución cerrada?** Twin Mining TMS es una plataforma modular, diseñada para adaptarse a la realidad técnica, operativa y organizacional de cada operación. Cada módulo puede implementarse en forma independiente o progresiva, permitiendo adopción incremental y priorización por valor sin desplegar todo el sistema desde el primer día. Los módulos comparten un núcleo común: el modelo de datos del depósito, con sus instrumentos, documentos, umbrales y expedientes enlazados. Es lo que hace que una decisión tomada en un módulo se pueda reconstruir desde otro. Este diseño reduce fricción de implementación, evita proyectos de alto impacto inicial y permite escalar desde casos específicos a una gestión integral del depósito. **¿En qué idiomas y regiones está disponible Twin Mining TMS?** La plataforma es bilingüe español/inglés en toda su superficie, incluidos los reportes y la aplicación de terreno. La capa de dominio devuelve claves de traducción y nunca prosa, de modo que añadir un idioma no obliga a reescribir la lógica. Twin Mining tiene su base en Chile —el mayor productor de cobre del mundo y una de las jurisdicciones con regulación de relaves más exigente— y la plataforma está diseñada para operar en portafolios multi-faena y multi-país de la minería metálica. ## Qué NO hace - **No predice fallas ni colapsos.** No hay modelo predictivo de falla. Hay umbrales definidos por un especialista, series con sus bandas y agentes que leen documentos. Lo que acorta es el tiempo entre que un dato cambia y alguien lo mira. - **No certifica ni garantiza el cumplimiento del GISTM.** La conformidad la declara el operador y la verifica un revisor independiente; la plataforma organiza la evidencia con que se defiende. - **La IA no decide.** Los agentes proponen y citan documento y página; decide una persona, y esa confirmación queda como un evento aparte con su autor y su fecha. - **La flota de Twin Model corre hoy sobre una simulación.** La vista 3D, la sección del muro y la cubeta por levantamiento están construidas; aún no hay integración con GPS, telemetría ni despacho, y la vista está lista para conectarse a la fuente de posiciones del operador. - **No hay app móvil nativa.** Se usa desde el navegador, también en terreno desde una tableta. ## Glosario - **TMS** (Sistema de Gestión de Relaves): El sistema donde vive el conocimiento y las decisiones de un depósito de relaves: reúne monitoreo, operación, documentación y cumplimiento, y deja la trazabilidad de cada decisión. - **TSF** (Depósito de relaves): La instalación donde se depositan los residuos del proceso minero: roca molida más agua. - **GISTM** (Global Industry Standard on Tailings Management): El estándar global de gestión de relaves publicado en 2020: 6 tópicos, 15 principios y 77 requisitos. - **TARP** (Trigger Action Response Plan): Las bandas de umbral de un instrumento —verde, amarillo, rojo— y la respuesta definida para cada una. - **EoR** (Engineer of Record): El ingeniero responsable del diseño de la instalación. Da conformidad técnica, no firma administrativa. - **RTFE** (Responsible Tailings Facility Engineer): El responsable operacional de la instalación de relaves. - **ITRB** (Independent Tailings Review Board): El panel de expertos externos que revisa la instalación y puede desmentir al operador por escrito. - **ALARP** (As Low As Reasonably Practicable): El criterio que define hasta dónde es razonable reducir un riesgo. - **MoC** (Gestión del Cambio): El expediente formal de cualquier cambio que altere el riesgo de la instalación: quién lo pidió, quién lo evaluó, quién lo autorizó. - **Revancha**: La distancia vertical entre la superficie del agua y la coronación del muro; el margen antes del rebose. - **DS 248**: El decreto supremo chileno que regula el diseño, construcción y operación de los depósitos de relaves.