title: "Briefing — "What should we investigate?"" source: "workspace/2026/TFW_20260830-114238_ASSISTED15/research/iter1/1_briefing.md"

Briefing — "What should we investigate?"¶

Mindset: Strategist. You're planning an investigation, not doing it. Frame what matters. Resist solving. Test: "Can I explain WHY we're investigating this and what would change our approach?" Parent: HL-TFW_20260830-114238_ASSISTED15 Goal: Deliver a standalone, organizationally neutral Assisted 1.5 whose lifecycle, identity, update discipline, and practical templates are derived from the read-only Innoforce field lineage and maintained through an explicit public-core/private-overlay boundary.

Research Plan¶

Gather¶

Build hash-backed path and version ledgers for public Assisted 1.0 and the read-only Innoforce 1.2–1.5 lineage, distinguishing shared, added, removed, and renamed paths without reproducing private content.
Decompose the problem into independent dimensions: file authority, update direction, baseline proof, state locality, template ownership, language surface, and runtime capability.
Trace the lifecycle, identity, updater, template, and changelog claims to their actual files and executable invariants; record every organization-, environment-, or provider-specific coupling as a classification, not as copied material.
Consult current primary documentation for version-control comparison/merge behavior, synchronized-folder limits, local configuration/state boundaries, and Codex task capabilities; actively collect counter-evidence against the proposed core-plus-overlay model.

Extract¶

Cross-reference the Gather dimensions into a configuration space covering whole-tree replacement, classified core-plus-overlay, generated distribution, stock-hash preservation, and manual reviewed promotion.
Derive the smallest invariant set that keeps lifecycle and identity fail-closed after neutralization, including the distinction between participant, project role, task owner, AI role, local binding, and shared project state.
Classify each public candidate path as core-owned, customizable, or downstream-only and pair it with a baseline/update rule that can operate in both directions without implying symmetry.
Test H1–H4 against repository evidence, field lineage, and primary external sources; separate reusable template semantics from branding, examples, and organization state.

Challenge¶

Run pairwise consistency checks over the configuration space and eliminate combinations that cannot simultaneously preserve neutrality, downstream customization, trace stability, version truth, and fail-closed behavior.
Attack surviving configurations with private-data false negatives, neutralization false positives, customized-template drift, unclassified paths, changed baselines, concurrent writers, partial synchronization, surname collisions, legacy identifiers, missing Codex capabilities, and Full/Assisted namespace interference.
Seek counter-evidence from official source-control, synchronization, local-state, and Codex documentation; distinguish what is technically guaranteed from what is only an operational convention.
Produce implementation-facing decisions and verification obligations, classifying every HL recommendation as either a refinement to a free section or an evidence-complete amendment proposal to a frozen claim.

Hypotheses (from HL §10)¶

#	Hypothesis	HL Status
H1	Universal lifecycle and identity behavior can be extracted from the Innoforce 1.5 package without weakening its fail-closed safety conditions.	open
H2	A classified manifest plus non-mutating comparison is sufficient for safe forward update and reviewed reverse promotion; an automatic two-way mirror is unnecessary.	open
H3	Practical templates can be neutralized while preserving the result-producing logic the owner considers essential, with company knowledge and branding fully excluded.	confirmed by owner direction; implementation evidence pending
H4	Keeping the field-proven Russian user layer for the 1.5 core minimizes semantic sync drift; public English localization can remain a separate later task.	open

Scope Intent¶

In scope: read-only analysis of public Assisted and Innoforce 1.2–1.5; universal lifecycle, identity, update, migration, changelog, template, and language behavior; path authority and baseline rules; external primary-source verification; neutralization and adversarial verification requirements for the single approved implementation phase.
Out of scope: editing either product tree; copying or publishing Innoforce facts, people, branding, project defaults, or paths; changing Full TFW, Light, root guides, frozen HL claims, status, or iterations.yaml; implementing synchronization; accepting a budget overrun; push or tag operations.

Guiding Questions¶

What is the smallest path-authority and baseline model that supports safe public-core → Innoforce update and audited Innoforce-generic → public promotion without blind mirroring?
Which lifecycle and identity invariants are genuinely universal, and which current behaviors depend on Innoforce wording, Google Drive assumptions, local machine state, or unverified Codex capabilities?
Which template and language elements must be core-owned, stock-hash protected, user-customizable, or downstream-only for Assisted 1.5 to remain both useful and neutral?

User Direction¶

Run deep mode with three OODA loops per stage, required counter-evidence, and at least two complete research iterations.
Treat H:\Shared drives\IT\Innoforce AI-First Knowledge\innoforce_starter_v1.5 and adjacent 1.2–1.4 lineage as read-only evidence.
Exclude Innoforce knowledge and other private organizational state; retain and neutralize the practical template capabilities that let other users reach the field-proven working discipline.
Keep product work inside editions/; do not push or tag. The owner delegated ordinary research decisions to the Phase Coordinator, but any evidence-complete amendment proposal must stop and return to the owner before application.

Stage complete: YES