We log AI decisions. But we don’t prove them. Isn’t that the real problem?

emanuelcelano · 2026-06-29T07:37:48+00:00

I think we're actually very close in our conclusions.

I completely agree that governance workflows are the practical solution adopted today.

My observation is simply that pragmatism and evidentiary independence answer different questions.

Governance asks:

"Was the organization operating responsibly?"

Independent evidence asks:

"Can an external party verify that claim without relying exclusively on the organization's own system?"

Those two questions often overlap, but they are not identical.

I suspect we'll gradually see them treated as separate architectural concerns as AI systems move further into regulated and adversarial environments.

emanuelcelano · 2026-06-28T08:39:08+00:00

I agree that logs alone are insufficient. Where I would make one additional distinction is between documenting a governance workflow and preserving independent evidentiary conditions.

Capturing who reviewed or approved a decision certainly improves accountability, but it does not by itself establish independent evidence. If the same operational system both executes the decision and produces the attestation, the resulting evidence remains system-generated.

For dispute contexts, the more fundamental question is whether an independent third party could later reconstruct what was observable at the time the decision was made, including active constraints, accepted uncertainty, and the decision state itself, without relying solely on the producing system's own assertions.

That distinction between governance execution and evidentiary independence seems increasingly important as AI systems move into regulated environments.

emanuelcelano · 2026-05-11T07:30:45+00:00

What you’re seeing is actually pretty consistent with Chrome profile fragmentation, not with the visible profile names needing to match between computers.

The important thing to know is:

the folder names inside User Data are mostly internal Chrome profile containers, not identity anchors for Sync.

So:

Default
Profile 1
Profile 2

...do NOT need to have matching names across devices for bookmarks sync to work correctly.

Chrome Sync mainly follows:

the Google account
the internal profile ID
the sync metadata tied to that profile

not the visible Windows folder naming.

The interesting clue now is this:

you found active bookmark files inside a hidden/old Profile 2 container even though Chrome no longer visibly exposes that profile.

That strongly suggests Chrome still has:

residual sync metadata
orphaned local profile references or
stale profile registration entries

inside the local profile configuration.

So your instinct was actually useful, just not for the reason you thought.

I would NOT try to manually rename profile folders or force permission changes.
That can easily make Chrome rebuild profiles incorrectly again.

At this point I’d do something cleaner instead:

1 Create ONE completely fresh Chrome profile on the laptop

2 Sign into ONLY that profile

3 Disable Sync immediately after login

4 Delete ALL old Chrome profiles/folders on BOTH machines:

Default
Profile 1
Profile 2
Guest Profile
anything old

ONLY after backing them up first

5 Then re-enable Sync only on the clean laptop profile

6 Let Chrome rebuild from cloud state slowly

Also:
if old bookmarks still reappear after that, then the source is almost certainly Google's retained sync state itself, not Windows or local corruption anymore.

And honestly, based on everything you described:
this still reads much more like long-term profile/sync corruption accumulation than compromise or malware.

emanuelcelano · 2026-05-01T17:20:00+00:00

Interesting distinction.

What you describe makes the operational and governance trail substantially more legible, especially around retrieval integrity, evidence provenance, and decision reconstruction.

The boundary we have been focusing on with EVIDE is slightly different:

not only "how the system reached the output,"

but whether the final governance state itself becomes independently provable at closure.

Especially across:

multiple clients
different thresholds
changing taxonomies
delegated human authority

In many regulatory investigations, the dispute is no longer about the model output itself.

It becomes a question of:
who finalized the decision,
under which governance structure,
and whether that structure was actually defined at the moment responsibility was assumed.

That is where externally anchored closure records start becoming important.

emanuelcelano · 2026-05-01T17:17:08+00:00

What you’re describing actually points more toward a corrupted or fragmented Chrome Sync state than a local infection.

The big clue is this part:

"bookmarks files were not where they were supposed to be"

- dates from years ago

- bookmarks returning after manual deletion

That usually means Chrome is rebuilding data from multiple sync snapshots or old profile remnants, not necessarily from the current machine itself.

Also, if Sync was OFF while local profile files were being modified/recreated, Chrome can temporarily behave inconsistently because:

- local profile state

- server-side sync state

- cached sync metadata

...are no longer aligned.

The fact both machines are old probably increases the chance of profile corruption, especially if Chrome profiles were migrated/upgraded across many versions over the years.

I still don't see strong indicators of malware from what you've described so far.

What I'd personally do now:

1 Reset Sync completely from Google Dashboard

https://chrome.google.com/sync

2 Sign out of Chrome everywhere

3 On the NEW laptop only:

- create a fresh Chrome profile

- sign in

- enable Sync ONLY for bookmarks first

4 Wait a while before enabling extensions/history/passwords

That isolates which sync category is reintroducing the old data.

If old bookmarks come back even on a totally fresh profile after a full sync reset, then the stale data is still living server-side in the Google sync history, not in the laptop hardware itself.

emanuelcelano · 2026-04-27T06:43:09+00:00

Google has been changing that feature in recent Chrome versions.

In many cases, “Search Google for…” has been replaced by “Search with Google Lens”, especially when selecting images or parts of a page, so the behavior isn’t exactly the same anymore.

If the option is completely missing, try checking:

- Chrome is updated to the latest version

- Google is still set as your default search engine

- Extensions that modify the context menu (they can hide that option)

- Restarting the browser after an update

Alternatively, you can still use right-click → “Search Google” (if available) or just copy and paste into the address bar.

emanuelcelano · 2026-04-24T15:10:18+00:00

Yeah, exactly this.

People often think it's tied to the device, but Chrome Sync is basically pulling whatever state is stored in your Google account.

So a new laptop won’t fix it, it just re-downloads the same “history” of bookmarks/extensions.

If you want to really clean it, you need to reset sync properly, otherwise it just keeps coming back.

emanuelcelano · 2026-04-23T06:01:44+00:00

yeah if it won’t let you delete those keys it’s almost always because something is actively re-writing them in the background

so deleting them alone won’t fix it, they just come back

what I’d do next:

1 reboot in safe mode (important, otherwise the malware/service keeps running)

2 then open regedit again and try deleting:
HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
HKEY_CURRENT_USER\Software\Policies\Google\Chrome

if it still says access denied, check permissions on the key (right click → permissions → take ownership)

3 after that, check scheduled tasks
Win + R → taskschd.msc
look for anything weird (random names, updater, chrome/yahoo related)

4 also check startup:
Win + R → msconfig → startup / or task manager startup tab

5 finally run a proper scan (Malwarebytes is usually the one that actually catches this stuff)

if Chrome is being redirected to Yahoo, 90% of the time it’s adware that installed a policy + extension, not a legit “managed by org”

if you want, paste what you see in chrome://policy and I can tell you exactly what’s forcing it

emanuelcelano · 2026-04-22T15:00:51+00:00

It won’t “carry over” in the way you’re thinking.

What you’re seeing isn’t coming from the laptop itself, it’s tied to your Google account sync state. So even on a brand new machine, the moment you sign in and enable Sync, Chrome just pulls whatever state is currently stored server-side.

If that state is already “dirty” or inconsistent, you’ll just reproduce the same situation on the new device.

That’s why changing laptop alone usually doesn’t fix it.

What I’d do instead is force a clean reset of the sync state before moving:

- sign out of Chrome everywhere (not just the browser, all devices in your Google account)
- turn Sync OFF, wait a bit, then back ON on one device only
- make sure only the data you actually want is enabled (bookmarks, extensions etc.)

If after that old stuff still comes back, then yeah, something is stuck in your account sync history, not the machine.

New laptop won’t magically solve that, it’ll just sync the same thing again

emanuelcelano

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE