docs: checkpoint return to Confidence Engine origin
This commit is contained in:
@@ -0,0 +1,227 @@
|
||||
# Confidence Engine — Return to Origin Context
|
||||
**Date:** 18 August 2026
|
||||
**Purpose:** durable project context / methodology checkpoint
|
||||
|
||||
> **Build → Break → Learn → STOP.** The recent selector-led work was a valuable implementation hypothesis. The experiments exposed its boundaries. Development is deliberately pausing before optimising the wrong assumption further.
|
||||
|
||||
## Purpose of this context update
|
||||
|
||||
This document records a deliberate return to the originating Confidence Engine methodology after a productive period of implementation and experimentation. It is not a rejection of the recent work. It preserves what was built, what the experiments exposed, what was learned, and why development is consciously stopping before further optimisation of the current single-next-question architecture.
|
||||
|
||||
The context is intended to be durable across future ChatGPT project conversations and repository work. Its purpose is to prevent later sessions from reconstructing the project from the most recent implementation details alone and losing sight of the method the application is meant to embody.
|
||||
|
||||
## The originating aim
|
||||
|
||||
The Confidence Engine began as an attempt to capture a repeatable way of thinking: take apart complicated situations, separate observation from interpretation, keep assumptions visible, admit what is not yet known, and keep moving until the next useful action becomes clear.
|
||||
|
||||
The core commercial ambition is not to build a clever chatbot for its own sake. It is to create transferable intellectual property for RDB Solutions: a methodology that can help people investigate, challenge and understand questions or decisions without depending on Rob personally being present to facilitate every engagement.
|
||||
|
||||
The software application is one delivery mechanism. The same underlying method should remain recognisable in a facilitated workshop, a workbook or book, training, consultancy, a team workspace, or another future product.
|
||||
|
||||
- The reasoning is the asset; the application is one experience of using it.
|
||||
- The engine guides; it does not judge.
|
||||
- Confidence is earned through understood evidence and manageable next actions, not through confident-sounding answers.
|
||||
- Experiments beat opinions: build something small enough to be wrong, observe it, and change only what the evidence supports.
|
||||
|
||||
## What the methodology was always trying to do
|
||||
|
||||
The originating method is not fundamentally a question-answer service. It is a disciplined investigation process. The person starts with whatever they can express - a question, concern, observation, decision or messy description. The Engine helps expose structure and then supports the investigation of that structure.
|
||||
|
||||
A useful outcome at any point may be an answer, but it may equally be knowing what to check, who to ask, what to measure, what evidence is missing, or what cannot yet be known. An unanswered question is therefore not necessarily a failed conversational turn.
|
||||
|
||||
- Start with what is actually happening.
|
||||
- Question the question and trace how the present situation arose.
|
||||
- Break complexity into pieces small enough to understand.
|
||||
- Separate knowns, assumptions, uncertainties and conclusions.
|
||||
- Investigate one manageable thing at a time.
|
||||
- Add evidence, update understanding and challenge what no longer fits.
|
||||
- Compare proposed action with the real alternative, including doing nothing.
|
||||
- Continue until the remaining uncertainty is understood well enough for the person to judge whether confidence is sufficient.
|
||||
|
||||
## What was built to test the method in software
|
||||
|
||||
The application evolved into a credible linear investigation hypothesis. The LLM reconstructs a messy situation into a SituationGraph, the graph holds knowns and unresolved uncertainties, deterministic reasoning selects an active unknown, a graph-backed question is formulated, the user answers it, and the graph updates before the next question is selected.
|
||||
|
||||
This was a reasonable implementation hypothesis. It made the method concrete enough to test. The mistake would be to judge it as obviously wrong in hindsight; its value was precisely that it created something real enough to expose boundaries.
|
||||
|
||||
## What the recent work achieved well
|
||||
|
||||
A substantial amount of the recent work remains valuable. The experiments did not show that the graph, decomposition or investigation concepts were misguided. They showed where authority had been placed in the wrong part of the system.
|
||||
|
||||
- LLM reconstruction of messy statements into useful structure.
|
||||
- Explicit representation of observations, assumptions, unknowns and relationships.
|
||||
- Graph persistence and state mutation as understanding changes.
|
||||
- Decomposition of broad uncertainty into smaller investigable questions.
|
||||
- Question formulation, answerability checks and reasoning-pattern safeguards.
|
||||
- Ownership and continuation invariants that prevent silent target drift.
|
||||
- Captured live fixtures, browser journeys and deterministic regressions.
|
||||
- A disciplined experimental method: live observation -> capture exact evidence -> isolate first divergence -> regression -> diagnosis -> implementation -> focused verification -> checkpoint.
|
||||
|
||||
## What the experiments exposed
|
||||
|
||||
The experiments progressively revealed that the single-next-question mechanism had accumulated too much product authority.
|
||||
|
||||
One important finding was that question formulation quality and investigation importance are different things. A selected uncertainty could remain the best thing to investigate even when the current wording of its question was rejected. This led to the ownership fix that preserves the investigation target rather than silently transferring to a weaker unrelated node.
|
||||
|
||||
A later metamorphic selector experiment exposed a deeper boundary. Two materially equivalent phrasings of the same uncertainty received very different deterministic scores because one phrasing triggered fixed vocabulary rules and the other did not. Wording alone changed the selected investigation target.
|
||||
|
||||
- Question rejection must not itself invalidate the investigation target.
|
||||
- Deterministic vocabulary weighting can make semantic priority depend on phrasing.
|
||||
- Real users use typos, slang, abbreviations, jargon, shorthand and personal language; LLM-generated graph labels also vary between equivalent phrasings.
|
||||
- Expanding a keyword dictionary would improve coverage but preserve a finite and brittle semantic boundary.
|
||||
- Replacing keyword authority with an invisible LLM ranking could solve the technical symptom while leaving the deeper methodological question unanswered.
|
||||
|
||||
## The deeper learning: we asked the wrong product question
|
||||
|
||||
Development gradually centred on: "What should the Engine ask next?" The more useful methodological question is: "What useful open questions has the investigation exposed, and how should the person work with them?"
|
||||
|
||||
The principle "one useful thing at a time" does not necessarily mean there may only be one available investigation item, nor that the machine must privately determine the only question the user is allowed to answer next. It can instead describe how a chosen investigation thread is broken into manageable steps.
|
||||
|
||||
## Return to origin: workspace, detective notebook, workshop
|
||||
|
||||
The existing context already described the application as a workspace, notebook and workshop-style environment. The current learning strengthens that interpretation.
|
||||
|
||||
The graph should primarily organise and remember the investigation rather than act as an invisible mechanism for forcing one linear route through it. Multiple open questions can coexist. The user can decide where they can make progress while the Engine continues to guide, challenge, connect and remember.
|
||||
|
||||
- Surface the open questions the LLM has already derived.
|
||||
- Let the user answer what they know now.
|
||||
- Let the user choose a question that matters most to them.
|
||||
- Allow questions to be deferred when evidence requires research, another person, measurement, calculation or time.
|
||||
- Allow the investigation to persist across minutes, days or weeks.
|
||||
- Let answers create smaller follow-up questions within a thread: the "just one more thing" pattern.
|
||||
- Allow different investigation items to be progressed independently or in parallel.
|
||||
- Keep the Engine able to challenge avoidance or highlight an unresolved issue that still materially blocks confidence.
|
||||
|
||||
## The role of the user
|
||||
|
||||
The user is not merely a respondent supplying missing fields to an automated reasoning pipeline. The user is the investigator. Choosing what to work on is itself part of the reasoning process.
|
||||
|
||||
A user may choose an easy question first because they know the answer immediately, defer a hard question because it requires evidence, or focus on the issue they believe matters most. The Engine should make those choices visible and useful rather than treating them as deviations from the correct route.
|
||||
|
||||
## The role of the LLM
|
||||
|
||||
The LLM is particularly valuable where the project originally intended it to be valuable: understanding messy human language, inferring structure, identifying useful uncertainties, noticing assumptions and inconsistencies, explaining relationships, and helping formulate manageable investigative questions.
|
||||
|
||||
It should act as a facilitator of the method rather than as an invisible authority that decides the user's route through the investigation.
|
||||
|
||||
## The role of deterministic code
|
||||
|
||||
Deterministic code remains valuable for hard invariants and product integrity. The recent experiments sharpen the distinction between semantic judgement and structural guardrails.
|
||||
|
||||
- Validate graph membership and node identity.
|
||||
- Exclude resolved or structurally invalid items.
|
||||
- Maintain relationships, dependencies and persistence.
|
||||
- Prevent duplicate or contradictory graph state.
|
||||
- Preserve ownership/current focus when a user is working on a thread.
|
||||
- Validate structured model output and protect against out-of-set or malformed changes.
|
||||
- Record history and preserve the timeline of how understanding changed.
|
||||
|
||||
## The role of the graph
|
||||
|
||||
The graph should be understood as the evolving case file: a structured memory of the investigation. It records what has been established, what remains uncertain, what evidence supports each item, how items relate, what was resolved, and what changed over time.
|
||||
|
||||
An active unknown may remain useful as the item currently being worked on. It should not automatically be interpreted as the one uncertainty the Engine has calculated the user must investigate next.
|
||||
|
||||
## Interaction principle: "just one more thing"
|
||||
|
||||
"Just one more thing" is not a requirement that the whole application always presents exactly one compulsory question. It is a decomposition principle inside an investigation thread.
|
||||
|
||||
When the user chooses an open question, the Engine should help reduce that question into the next small thing needed to understand it. An answer may resolve it, refine it, or expose another smaller uncertainty. That new item becomes part of the notebook rather than forcing the entire investigation into a single linear conversation.
|
||||
|
||||
## Interaction can be asynchronous and parallel
|
||||
|
||||
Real investigations do not fit neatly into one chat session. Some answers are immediate; others require documents, colleagues, calculations, measurements, research or waiting for events.
|
||||
|
||||
The workspace should therefore treat unresolved questions as persistent investigation items rather than failed turns. Different items can be advanced independently or in parallel, and the user should be able to return when new evidence becomes available.
|
||||
|
||||
- Open
|
||||
- Answerable now
|
||||
- Needs investigation
|
||||
- Waiting for information
|
||||
- Partly answered
|
||||
- Resolved
|
||||
- No longer material
|
||||
|
||||
## Latency supports the methodology rather than fighting it
|
||||
|
||||
Long model response times exposed another useful design signal. The product should not make the user wait for reasoning that is not required for their next useful action.
|
||||
|
||||
Rather than one large model operation that tries to reconstruct, rank, formulate and validate an entire linear route before the user can act, the experience can progressively surface useful structure and deepen only the investigation item the user chooses to work on.
|
||||
|
||||
## Commercial and intellectual-property implication
|
||||
|
||||
The valuable asset is not a specific selector, prompt or chat interface. Those can be replaced. The defensible value is the repeatable Confidence Engine method for turning uncertainty into an understandable investigation and helping a person build justified confidence.
|
||||
|
||||
That matters directly to RDB Solutions because the aim is to create products and methods that generate value without relying on Rob personally delivering every piece of reasoning. A software workspace, facilitator-led workshop, workbook, training programme or other delivery format can all express the same underlying method.
|
||||
|
||||
## Development principle reaffirmed: BUILD -> BREAK -> LEARN -> STOP
|
||||
|
||||
The recent work is itself an example of the Confidence Engine philosophy. The project could not know the limits of a selector-led linear conversation until enough of it had been built to observe its behaviour.
|
||||
|
||||
The experiments generated evidence. The evidence challenged the underlying assumption. Development stopped before turning the response into an ever-larger dictionary, weight tuning exercise or semantic-ranking subsystem.
|
||||
|
||||
Stopping is not failure. It is the point at which explicit reasoning allows the project to avoid sunk-cost optimisation and preserve what was learned.
|
||||
|
||||
## What remains valuable from v0.47
|
||||
|
||||
The return to origin is not a reset. The following remain valuable assets unless later evidence shows otherwise:
|
||||
|
||||
- SituationGraph and structured case state.
|
||||
- LLM reconstruction/decomposition.
|
||||
- Known / assumed / unknown / evidence distinctions.
|
||||
- Relationships and dependencies.
|
||||
- Resolution and supersession state.
|
||||
- Question decomposition and answerability concepts.
|
||||
- Ownership/current-focus semantics where they represent the thread being worked on.
|
||||
- Validation and graph-integrity safeguards.
|
||||
- Persistent history and captured provenance.
|
||||
- Live semantic test discipline and deterministic regression workflow.
|
||||
- The existing experimental fixtures and failure evidence that explain how the project reached this point.
|
||||
|
||||
## What is now paused
|
||||
|
||||
Further work to perfect a compulsory single-next-question selector is paused. This includes both continued keyword/dictionary optimisation and immediate replacement with an invisible semantic ranking mechanism.
|
||||
|
||||
No conclusion has yet been made that selection or recommendation has no role. The Engine may still recommend, challenge or identify an issue that materially blocks confidence. What is paused is the assumption that recommendation must equal compulsory routing.
|
||||
|
||||
## Current working hypothesis - not yet the final design
|
||||
|
||||
The next product hypothesis is that the application should surface the useful investigation structure the Engine already derives and let the person work with it as a persistent workspace.
|
||||
|
||||
Multiple open questions can coexist. The user can choose, defer, investigate and return. The Engine keeps the notebook coherent, formulates smaller follow-up questions inside a chosen thread, and eventually makes visible which unresolved items still materially prevent confidence.
|
||||
|
||||
This is a hypothesis to test, not a replacement architecture already decided.
|
||||
|
||||
## Timeline marker: how we got here
|
||||
|
||||
The Confidence Engine principle of tracing origins applies to the project itself. Future work should preserve the timeline rather than flattening it into "old design" and "new design".
|
||||
|
||||
- Origin: capture a transferable reasoning methodology that breaks uncertainty into manageable pieces and helps people earn confidence.
|
||||
- Early product hypothesis: conversational loop, then notebook/workspace concepts.
|
||||
- Implementation hypothesis: graph-backed linear investigation with one selected active unknown and one next question.
|
||||
- Build: graph reconstruction, decomposition, patterns, question formulation, ownership and validation were implemented.
|
||||
- Break: real browser journeys and deterministic regressions exposed stale ownership, question-rejection and selection-boundary defects.
|
||||
- Learn: question wording is not target validity; fixed vocabulary scoring is not paraphrase-invariant; next-question selection had accumulated too much authority.
|
||||
- STOP: further selector optimisation paused.
|
||||
- Return to origin: reconsider the user experience as a persistent investigation workspace while retaining the valuable reasoning infrastructure already built.
|
||||
|
||||
## Next design question - deliberately unanswered
|
||||
|
||||
Given the useful investigation structure the Engine can already derive, how should that structure be surfaced so a person can see, choose, defer, investigate and return to open questions while the Engine continues to guide and challenge their thinking toward justified confidence?
|
||||
|
||||
The next phase should begin from this methodology question, not from a preselected technical solution.
|
||||
|
||||
## Source basis
|
||||
|
||||
- `01_Confidence_Engine_Founding_Principles`
|
||||
- `02_Confidence_Engine_Product_Story`
|
||||
- `04_Rob_Thinking_Model`
|
||||
- `06_Confidence_Engine_Context`
|
||||
- `07_Rob_Thinking_Style_and_Working_Philosophy`
|
||||
- `08_Confidence_Engine_Development_Context`
|
||||
- `08_Confidence_Engine_Project_Context_August_2026`
|
||||
- `Confidence_Engine_Live_Semantic_Test_Method`
|
||||
- `Confidence_Engine_Project_Context_Update_2026-08-17`
|
||||
- `Confidence_Engine_Current_Handoff_2026-08-17`
|
||||
|
||||
This context update distinguishes established project principles from current implementation learning. The workspace/user-directed investigation model is recorded as the current hypothesis to test, not as a completed replacement architecture.
|
||||
@@ -125,3 +125,20 @@ The override was produced by fixed `actor_match` keyword scoring: node n65sgyd's
|
||||
**What this establishes:** On fresh Start calls, deterministic keyword signals can override model-inferred investigation priority when node labels differ in dictionary-match patterns. The final investigation target is not the model's contextual judgment but the highest-scoring candidate under fixed scoring rules.
|
||||
|
||||
**What this does NOT prove:** Whether the deterministic selection is better or worse than the model's suggestion; consistency across scenario types; or downstream investigation quality impact.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## RETURN-TO-ORIGIN CHECKPOINT
|
||||
|
||||
**selector-led compulsory next-question optimisation is PAUSED**
|
||||
|
||||
**semantic-selector replacement is also PAUSED**
|
||||
|
||||
Recent work is preserved as valuable experimental learning. The graph/reconstruction/decomposition/invariant work remains potentially reusable. No replacement architecture has been selected.
|
||||
|
||||
The next phase starts from the workspace/methodology question, not from a preselected technical solution.
|
||||
|
||||
See:
|
||||
- `docs/methodology-checkpoint-return-to-origin.md` — repository-facing checkpoint summary
|
||||
- `docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md` — full methodology context (source)
|
||||
|
||||
@@ -0,0 +1,136 @@
|
||||
# Confidence Engine — Methodology Checkpoint: Return to Origin
|
||||
|
||||
**Date:** 18 August 2026
|
||||
**Status:** CHECKPOINT — development paused at this methodology question
|
||||
**Branch:** `feature/decision-closure-ownership-v0.47`
|
||||
|
||||
> **Build → Break → Learn → STOP.** The recent selector-led work was a valuable implementation hypothesis. The experiments exposed its boundaries. Development is deliberately pausing before optimising the wrong assumption further.
|
||||
|
||||
---
|
||||
|
||||
## Original Aim
|
||||
|
||||
Capture a repeatable way of thinking: take apart complicated situations, separate observation from interpretation, keep assumptions visible, admit what is not yet known, and keep moving until the next useful action becomes clear.
|
||||
|
||||
The core commercial ambition is to create transferable intellectual property for RDB Solutions — a methodology that helps people investigate, challenge and understand questions or decisions without depending on Rob personally being present.
|
||||
|
||||
The reasoning is the asset; the application is one delivery mechanism. Confidence is earned through understood evidence and manageable next actions, not through confident-sounding answers. Experiments beat opinions.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Hypothesis
|
||||
|
||||
The LLM reconstructs a messy situation into a SituationGraph. The graph holds knowns and unresolved uncertainties. Deterministic reasoning selects an active unknown. A graph-backed question is formulated. The user answers it. The graph updates. The next question is selected.
|
||||
|
||||
This was a reasonable implementation hypothesis — it made the method concrete enough to test.
|
||||
|
||||
---
|
||||
|
||||
## What Was Built Successfully
|
||||
|
||||
- LLM reconstruction of messy statements into useful structure
|
||||
- Explicit representation of observations, assumptions, unknowns and relationships
|
||||
- Graph persistence and state mutation as understanding changes
|
||||
- Decomposition of broad uncertainty into smaller investigable questions
|
||||
- Question formulation, answerability checks and reasoning-pattern safeguards
|
||||
- Ownership and continuation invariants that prevent silent target drift
|
||||
- Captured live fixtures, browser journeys and deterministic regressions
|
||||
- A disciplined experimental method: live observation → capture exact evidence → isolate first divergence → regression → diagnosis → implementation → focused verification → checkpoint
|
||||
|
||||
---
|
||||
|
||||
## What the Experiments Exposed
|
||||
|
||||
The single-next-question mechanism had accumulated too much product authority.
|
||||
|
||||
1. **Question formulation quality and investigation importance are different things.** A selected uncertainty could remain the best thing to investigate even when its question wording was rejected — leading to the ownership fix that preserves the investigation target rather than silently transferring it.
|
||||
|
||||
2. **Deterministic vocabulary weighting makes semantic priority depend on phrasing.** Two materially equivalent phrasings received very different scores because one triggered fixed vocabulary rules and the other did not. Wording alone changed the selected investigation target.
|
||||
|
||||
3. **Real users use typos, slang, abbreviations, jargon, shorthand and personal language; LLM-generated graph labels also vary between equivalent phrasings.** Expanding a keyword dictionary would improve coverage but preserve a finite and brittle semantic boundary.
|
||||
|
||||
4. **The experiments exposed that we had asked the wrong product question.** Development centred on "What should the Engine ask next?" when the more useful question is "What useful open questions has the investigation exposed, and how should the person work with them?"
|
||||
|
||||
---
|
||||
|
||||
## BUILD → BREAK → LEARN → STOP
|
||||
|
||||
- **BUILD:** Graph reconstruction, decomposition, patterns, question formulation, ownership and validation were implemented.
|
||||
- **BREAK:** Real browser journeys and deterministic regressions exposed stale ownership, question-rejection and selection-boundary defects.
|
||||
- **LEARN:** Question wording is not target validity; fixed vocabulary scoring is not paraphrase-invariant; next-question selection had accumulated too much authority.
|
||||
- **STOP:** Further selector optimisation paused — before turning the response into an ever-larger dictionary, weight tuning exercise or semantic-ranking subsystem.
|
||||
|
||||
---
|
||||
|
||||
## Return to Workspace / Notebook / Workshop
|
||||
|
||||
The graph should primarily organise and remember the investigation rather than force one linear route. Multiple open questions can coexist. The user can decide where they can make progress while the Engine continues to guide, challenge, connect and remember.
|
||||
|
||||
- Surface the open questions the LLM has already derived
|
||||
- Let the user answer what they know now
|
||||
- Let the user choose a question that matters most to them
|
||||
- Allow questions to be deferred when evidence requires research, another person, measurement, calculation or time
|
||||
- Allow the investigation to persist across minutes, days or weeks
|
||||
- Keep the Engine able to challenge avoidance or highlight an unresolved issue that still materially blocks confidence
|
||||
|
||||
---
|
||||
|
||||
## User-Directed Open Investigations
|
||||
|
||||
The user is not merely a respondent supplying missing fields to an automated reasoning pipeline. The user is the investigator. Choosing what to work on is itself part of the reasoning process.
|
||||
|
||||
Multiple investigation items can be advanced independently or in parallel. Different items can be progressed independently, and the user should be able to return when new evidence becomes available.
|
||||
|
||||
---
|
||||
|
||||
## Asynchronous / Deferred Investigation
|
||||
|
||||
Real investigations do not fit neatly into one chat session. Some answers are immediate; others require documents, colleagues, calculations, measurements, research or waiting for events.
|
||||
|
||||
Open questions should be treated as persistent investigation items rather than failed turns. States include: Open, Answerable now, Needs investigation, Waiting for information, Partly answered, Resolved, No longer material.
|
||||
|
||||
---
|
||||
|
||||
## What Remains Technically Valuable
|
||||
|
||||
- SituationGraph and structured case state
|
||||
- LLM reconstruction/decomposition
|
||||
- Known / assumed / unknown / evidence distinctions
|
||||
- Relationships and dependencies
|
||||
- Resolution and supersession state
|
||||
- Question decomposition and answerability concepts
|
||||
- Ownership/current-focus semantics where they represent the thread being worked on
|
||||
- Validation and graph-integrity safeguards
|
||||
- Persistent history and captured provenance
|
||||
- Live semantic test discipline and deterministic regression workflow
|
||||
|
||||
---
|
||||
|
||||
## What Is Paused
|
||||
|
||||
Further work to perfect a compulsory single-next-question selector is paused. This includes both continued keyword/dictionary optimisation and immediate replacement with an invisible semantic ranking mechanism.
|
||||
|
||||
No conclusion has yet been made that selection or recommendation has no role. The Engine may still recommend, challenge or identify an issue that materially blocks confidence. What is paused is the assumption that recommendation must equal compulsory routing.
|
||||
|
||||
---
|
||||
|
||||
## Commercial Continuity
|
||||
|
||||
The valuable asset is not a specific selector, prompt or chat interface. Those can be replaced. The defensible value is the repeatable Confidence Engine method for turning uncertainty into an understandable investigation and helping a person build justified confidence.
|
||||
|
||||
That matters directly to RDB Solutions: the aim is to create products and methods that generate value without relying on Rob personally delivering every piece of reasoning. A software workspace, facilitator-led workshop, workbook, training programme or other delivery format can all express the same underlying method.
|
||||
|
||||
---
|
||||
|
||||
## Deliberately Unanswered Next Question
|
||||
|
||||
> Given the useful investigation structure the Engine can already derive, how should that structure be surfaced so a person can see, choose, defer, investigate and return to open questions while the Engine continues to guide and challenge their thinking toward justified confidence?
|
||||
|
||||
The next phase should begin from this methodology question, not from a preselected technical solution.
|
||||
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
Full methodology context: `docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md`
|
||||
This is a concise repository-facing checkpoint derived from the above source, preserving all sections.
|
||||
Reference in New Issue
Block a user