Recommendation Adjustments

This page tracks how AIWikis.org changes its own LLM Wiki, source-package, governance, source-mapping, and agent-handoff recommendations based on build evidence.

Current Recommendations

• Start with source scope and trust labels.
• Use a source manifest before public summary writing.
• Keep raw snapshots out of installable WordPress packages.
• Require human approval for policy, security, privacy, legal, production, and architecture changes.

Proposed Changes

• Add a lessons/source-observations folder to dogfood sites that consume starter packages.
• Include Dogfood Notes and Recommendation Changes in release evidence.
• Add a public Source Map page alongside machine-readable source data.
• Require source-package ownership checks so dogfood sites do not relabel upstream starter bundles as local products.
• Record local package-observation hashes for dogfooded source-site WordPress plugins without bundling those ZIPs into the consuming site's public package.
• Add a bounded autonomous wiki custodian prompt for repositories that want an agent to compile raw sources into durable, cited Markdown nodes.
• Use AIWikis as the long-term memory archive for already-dispositioned UAIX.org, LlmWikis.org, Protocol5.com, ɩ.com / JustAnIota.com, and AIWikis archive or source-memory inputs, while keeping each source site's authority intact.
• Add a Deep Cognitive Archive pattern for projects that need a slower reasoning layer behind public pages and compact handoff packets.
• Require a checked Project Handoff export loop when a project claims reviewed wiki memory can feed .uai or AI Memory packets. The loop should select reviewed nodes, verify governance/source metadata, and produce a compact export manifest.
• Add an Intake Outcome Ledger for dropped-file workflows so the user can see what was read, what changed, what was deferred or blocked, where the raw file lives, and where reviewed change documentation can be viewed.
• Treat generated AI Memory package files as operating protocols, not empty templates: package builders should ask for source authority, memory update timing, evidence ledger, conflict handling, testing, deployment, review, risk, and rollback choices before handing work to the next human or AI.
• Keep a public roadmap for dogfood sites that separates current support, next work, later research, and blocked claims.
• Add reviewed source-system memory guides beside generated file indexes so a dogfood site explains what each source owns, how local memory preserves it, when to update it, and which claims remain out of scope.
• Add a cross-site memory atlas and operations playbook when a dogfood memory site sits between multiple source authorities. The atlas should route claims and artifacts; the playbook should route maintenance work and checks.
• Add a memory coverage matrix and claim boundary register so agents can tell which domains are covered, partially covered, source-only, or blocked before making claims.
• Treat implementation-package sites as first-class source systems when they carry package and route evidence, while routing standards and conformance claims back to the normative source.
• Give every newly preserved source system a named source guide, home-page listing, coverage entry, claim-boundary entry, and generated route family so its evidence does not disappear under generic memory.

Accepted Changes

• AIWikis.org version 0.1.0 includes lessons pages, source-package references, and release-evidence dogfood sections.
• AIWikis.org now records that LlmWikis publishes llm-wiki-starter-bundle-v2.7.0.zip, UAIX publishes uai1-project-handoff-v2.7.0.zip, Protocol5 publishes Protocol5 UAI .NET artifacts, and AIWikis consumes or observes source packages.
• UAIX Project Handoff plugin dogfood was fed back to UAIX so its experimental exporter and validator match the current package-shape guidance.
• AIWikis distilled the active Autonomous Wiki Custodian blueprint into a bounded public page while keeping full metadata migration and graph automation as future review work.
• AIWikis now preserves processed UAIX.org and LlmWikis.org archive files under raw/system-archives/ and exposes the policy through a System Memory Archive public page, compiled wiki nodes, and graph triples.
• AIWikis incorporated the Deep Cognitive Archive model as local source-side architecture, preserving the raw Improvement report while publishing only a reviewed synthesis.
• AIWikis now generates a local Project Handoff export from AGENTS.md, readme.human, .uai state, recommendation docs, intake scaffolding, and selected reviewed wiki nodes. This is local dogfood evidence, not hosted UAIX generator or certification support.
• AIWikis now tracks recent UAIX dropped-file digestion through an Intake Outcome Ledger page, transfer manifest, compiled wiki nodes, graph records, and updated progress/decision state.
• AIWikis now tracks the UAIX AI Memory Wizard protocol expansion as source evidence: generated system profiles, receiver briefs, startup packets, overlay JSON, and optional LLM Wiki memory plans carry operating rules while UAIX.org remains the authority for the wizard.
• AIWikis now publishes a Roadmap page so documentation, source-sync, package-evidence, and deployment-readiness work have a single public planning surface.
• AIWikis now publishes UAIX.org, LLMWikis.org, Protocol5.com, and JustAnIota Source Memory Guide pages as reviewed public memory maps that sit beside generated source-file pages without replacing any source site.
• AIWikis now indexes Protocol5.com as a first-class implementation-package source system with /protocol5/ generated routes, a reviewed source memory guide, source-package observations, and explicit non-claims that Protocol5 does not replace UAIX.org for UAI-1 standards authority.
• AIWikis now indexes ɩ.com / JustAnIota.com as a first-class compact-message tooling and implementation-memory source system with /justaniota/ generated routes, a reviewed source memory guide, and explicit non-claims that JustAnIota does not replace UAIX.org for UAI-1 standards authority.
• AIWikis now publishes a Cross-Site Memory Atlas and Source Memory Operations Playbook so cross-site documentation and long-term memory maintenance have explicit routing rules and a repeatable workflow.
• AIWikis now publishes a Memory Coverage Matrix and Claim Boundary Register so coverage state and claim safety are visible before public copy, package notes, roadmap language, or handoff summaries are written.

Rejected Changes

• Do not rewrite source recommendations silently.
• Do not claim certification or endorsement from package generation.
• Do not include raw fetched source snapshots in theme or plugin packages.
• Do not publish an AIWikis-branded starter ZIP that obscures source-package ownership.
• Do not treat the Intake Outcome Ledger as automatic ingestion, hosted import validation, repository writes, certification, endorsement, or source-site authority.
• Do not turn UAIX wizard dogfood into a claim that AIWikis owns the AI Memory standard, hosts a package importer, automatically writes repositories, or synchronizes LLM Wikis.
• Do not let source memory guides imply AIWikis is the canonical UAIX, LLMWikis, or Protocol5 source.
• Do not let Protocol5 package or mirror evidence imply UAI-1 standards authority, validator authority, conformance approval, certification, or endorsement.
• Do not let JustAnIota compact-message tooling, keyless JSON, HTML extraction, Unicode/PUA experiments, or logo/theme work imply UAI-1 standards authority, validator authority, registry authority, conformance approval, certification, endorsement, semantic authority, anonymization proof, or production deployment.
• Do not let a cross-site atlas or playbook imply AIWikis can certify, validate, deploy, or operate source-site tooling beyond current evidence.
• Do not treat "covered by AIWikis memory" as equivalent to source authority, production deployment, certification, or endorsement.

Open Questions

• Should recommendation changes require a separate human approval step before becoming public guidance?
• Should future source-package manifests record source inspiration per file?
• Which .uai files should be required across LlmWikis starter bundles versus UAIX Project Handoff exports?
• Should future archive pulls be manual, scheduled, or triggered only by explicit human request?
• Should future large intake outcomes use dated ledger pages or stay on the rolling ledger?
• Should deep-memory node metadata become a source-site recommendation, or remain an AIWikis implementation detail until more evidence exists?
• Should AIWikis keep the Project Handoff export as internal release evidence until UAIX publishes broader generator support, or publish a public-safe bundle with a narrower support boundary?