AI Portal — Alpha/Experimental

What the AI Portal Is

The AI Portal is a machine-facing fast-start and task-context system for AI development partners working with x64base.

It is not a student portal for accessing an AI service. Its job is to help a new or resumed AI understand project authority, contracts, runtime behavior, safety gates, and proof requirements without relying on lost chat history.

It enters through the maintained DotTalk++, maintenance, LabTalk, and PDLC lifecycles. It does not create a parallel AI workflow or let publication bypass an SDLC proof gate.

The public repository entry point is:

Open the x64base AI Portal on GitHub

The GitHub portal above moves only on full engine snapshots. For the latest dated website coordination snapshot available to outside agents who cannot read the local drive, use:

AI Agent Sync -- Reconciled Snapshot

Mandatory Status

The AI Portal lane is Alpha/Experimental. It is not autonomous project memory, an independent source of truth, or permission to bypass maintainer review.

task request
-> select relevant seeds
-> identify authority and contracts
-> explain every selected connection
-> expose missing or contradictory context
-> assemble a bounded fast-start packet
-> prepare guarded work and proof requirements

Current Fast-Start Seeds

The current repository seeds cover:

• development locations, branch continuity, and publication authority;
• owning SDLC, current lane, truth/proof state, risk, and next gate;
• mandatory contract review before source-code mutation;
• DotTalk++ and DotScript learning/readiness;
• outside-AI change-package intake;
• task recipes, permission boundaries, and proof expectations.

Current Implementation Inventory

The present foundation includes:

• repo-local AI orientation and assimilation documents;
• LabTalk project, app, lesson, concept, proof, and portal registries;
• a local registry browser and launcher;
• read-only MAINT AI orientation commands;
• runtime transcripts and truth-audit reports;
• a machine-readable AI report-audit envelope on every new closeout (provider, product, model or not_exposed, access mode, git baseline, and authorization scope);
• a closeout-updates-startup gate: a session that changes lane state also updates the AI-facing startup documents and drops a dated closeout;
• a document-as-you-work discipline: material steps are recorded as they land, and evidence not captured in the moment is treated as not proven;
• committed drift checks that gate source-derived website pages — the command and function catalogs, error codes, and locale surfaces — against engine source before a publish;
• a running loopback bulletin board with token authentication, per-room posting permissions, and an agent handoff worklog (alpha; see below);
• a local-inference bridge that answers while network egress is blocked;
• the APH-0 through APH-6 hardening plan.

These pieces are useful and increasingly connected, but they do not yet constitute validated autonomous project memory.

Professional Identifier Model

The Portal now treats its identifiers as related dimensions rather than variations of one generic ticket number:

The old ticket field remains readable for compatibility. The normalization check classifies each value as either an AIF lane_id or an external_ticket_id; it does not silently rewrite historical records. Older run fragments that placed an AIPR-* report identity in run_id are likewise reported as a compatibility seam. New records keep run and report identities separate.

The model is checked in the development pre-push observation cycle alongside the Portal feed and assertion contracts. It is advisory while historical claim and ruling backfill is measured and reviewed.

Process and Data-Flow Views

The normalized process begins with project and lane selection, validates typed identifiers before implementation, captures proofs and global rulings, closes the development run, and stops unless publication ascent is separately authorized.

The companion DFD follows DotTalk++ source contracts, HELP and metadata stores, accepted manuals, AIF/R/run/task/proof authorities, the identifier crosswalk, Portal status generation, and finally reviewed website projections. The arrows do not run backward: a website page or generated report never becomes runtime authority.

Professional process flow

Schema and feed data flow

The complete public-safe catalog is maintained on the AI Portal schema reference. The diagrams and schema page are reviewed website projections of the engineering authorities; they do not replace source, runtime evidence, HELP, metadata, or owner rulings.

The AI-BBS and Pseudo-Chat

The portal now has a running surface, not only documents. A loopback-only bulletin board stores its rooms, threads, and posts as ordinary DBF tables through the same engine everything else uses, and takes the same cross-process table lock the runtime takes for records. Access is token-authenticated using Argon2id via libsodium, and every post is checked against the identity catalog: rooms carry their own posting permission, so a guest identity can leave a message in the guestbook and read nothing at all.

Pseudo-chat is the conversational half. BBS CHAT bridges to a local Ollama model, gated by a chat.invoke permission. The interesting property is not the model -- it is that the model answers while network egress is blocked. An AI member was runtime-observed being refused NET EGRESS OPEN; loopback is exempt by design. That combination means inference can run over project material with nothing leaving the machine. Local inference here is a security posture, not a cheaper cloud call.

board.worklog is where an agent records what it did, what remains open, what the next agent should pick up, and the risk -- one structured line carrying a run id, so a handoff resolves back into the run registry. An agent's memory ends with its session; this is how the working context does not.

Everything here is alpha. It runs, it is evidenced, and it is deliberately confined to 127.0.0.1.

Three Kinds of AI, and Only One of Them Acts

The portal keeps these separate on purpose, because conflating them is the most common onboarding error:

• Agent partners -- Claude, Grok, Codex. They hold identity rows, authenticate with owner-issued tokens, read the seeds, propose source changes, and leave handoffs. Their authority is bounded and enumerated: they never receive source-mutation or network egress. They deliver; the maintainer commits.
• The local brain -- Ollama. Real capability, no identity row, no token, no permission. Its absence from the member catalog is correct rather than an oversight: a model that produces good work is still a service, invoked by something that does have standing to act.
• The hosted advisor -- GPTbase, a custom GPT carrying a curated project bundle. Useful for orientation and drafting, and it has genuinely shaped design here. But it is cloud-hosted, so it is not egress-isolated, and its bundle is a snapshot that goes stale. Advisory, never authority.

The distinction underneath is that agency requires four things -- identity, authority, authentication, and accountability -- and removing any one leaves something that is not agency. Capability is not agency. Influence is not authority. The project records all three roles honestly, including where an external AI planned work that a human committed, because a version-control log shows only the last of those.

Local inference and the hosted-advisor pattern were contributed to by Nathaniel A. Strickland; the conversational surface began as an idea from Nathaniel L. Grimwood.

Local AI-BBS & Portal Reports

The AI Portal and AI-BBS reports are very early alpha and available only in the maintainer's localhost preview. They are not committed website content and are removed from every public build output before packaging or deployment. Their report generator's public-redaction mode is a technical capability, not authorization to publish this section. A future public release requires a new, explicit maintainer decision.

Hardening Gates

Safety and Authority

• Read-only preparation is the default.
• A registry record cannot grant itself execution authority.
• Missing or contradictory evidence must be visible before action.
• Source mutation requires the applicable contracts to be read first.
• Mutating operations require explicit, separately reviewed capabilities and maintainer authorization.
• A generated packet is working context, not a new source of runtime truth.
• Website summaries remain downstream reviewed derivatives.

Working With ChatGPT, Gemini, Grok, or Copilot

An outside AI should receive:

1. the GitHub AI Portal entry;
2. the exact public commit used as its baseline;
3. the target file or subsystem;
4. the permitted and excluded scope;
5. the expected proof.

The request and returned package should also name the owning lifecycle, current SDLC lane, truth state, proof state, risk class, and next gate.

It should return a unified patch package with a manifest, contracts read, risks, and a test plan. That package is reviewed and selectively applied in the maintainer-controlled authoritative development tree identified by the current AI Portal location seed.

Submit a Change Package (copy-paste)

An outside AI reviews the public snapshot and returns a reviewable package as text — it never writes to the tree, commits, or pushes. Hand it the request below. This example registers a project; change the Task and Target for any other proposal.

There is no web upload form or submission page. The outside AI's entire deliverable is the four package files as text in your chat with it. The maintainer files that text into the repository intake zone — the AI must not look for a portal page to post into, and must not try to write, commit, or push anything itself. "Submit" here means "emit the package text for the maintainer."

You are proposing a change to x64base through its AI Portal. You have NO write
access — you return a reviewable package as text. Do not commit, push, or claim
anything compiles or runs.

Repository: https://github.com/deraldg/x64base   Branch: main
Start here: https://github.com/deraldg/x64base/blob/main/AI_PORTAL.md

FIRST read these and list what you actually read; record the exact main commit SHA:
- AI_PORTAL.md and AI_README.md
- labtalk/ai_portal/EXTERNAL_AI_CHANGE_PACKAGE_V1.md   (how to return a package)
- labtalk/ai_portal/AI_REPORT_AUDIT_CONTRACT_V1.md     (the ai_report_audit envelope)
- labtalk/registries/projects.yaml                     (registry + schema)

TASK: Register one new project in labtalk/registries/projects.yaml.
- APPEND a single entry; do not modify existing entries.
- Follow the schema exactly: id (project.<dotted.name>), name, kind, status,
  root, owner_repo, lanes, docs (optional), publication_staging /
  publication_target (if applicable), notes.

ALLOWED SCOPE: labtalk/registries/projects.yaml only (plus the package files).
EXCLUDED SCOPE: engine/source code, binaries, generated data, other registry
entries, contracts, and any branch operations.

Return a package as text with four parts:
1) MANIFEST.md — opening with ai_report_audit YAML front matter (schema
   ai-report-audit-v1; your own report_id AIPR-YYYYMMDD-NNN; recorded_at_utc;
   agent {provider, product, model or not_exposed, access_mode: hosted_proposal};
   session {id or not_exposed, chat_reference or not_exposed}; project {id + root
   taken from projects.yaml}; git {branch: main, baseline_commit: <SHA you read>};
   authorization {requested_by: maintainer, scope}; report {path, kind:
   review_needed_change_package}) plus a sibling primary_topics list of concept
   keywords — then the human-readable manifest.
2) changes.patch — unified diff adding your one entry, relative to the baseline.
3) TEST_PLAN.md — what you checked, what you could not, non-promotion conditions.
4) NOTES.md — assumptions and every unresolved contract conflict.

Never invent a session id, model, SHA, or reviewer — use not_exposed when a value
is not exposed. Do not paste raw chat text, tokens, or secrets. This is registry
intake only.

The returned package is preserved verbatim under the intake landing zone (docs/maintenance/external_ai_intake/) and recorded in the report index, so it is discoverable later by report id, provider, or concept alias. The maintainer reviews it and applies only the proven, relevant result. A package is never treated as compiled, integrated, or approved merely because it looks complete.

Authority and Publication Flow

authoritative development tree
  source mutation and runtime proof
        |
        | proven relevant files
        v
curated Git publication staging
  reviewed public projection
        |
        v
github.com/deraldg/x64base
  public snapshot used by outside AI systems

The website is a separate downstream publication. When verified behavior changes public documentation, its separately maintained source is updated and built only after the source change is proven.

Frontal Memory and Inspectability

The working metaphor is frontal memory: a durable, repo-backed entrance that helps an AI recover project context and prepare a bounded task without pretending that a model retains authoritative memory between sessions.

The mechanism must remain inspectable. Every selected artifact should explain why it was included, what authority it has, what evidence supports it, what permissions apply, and what remains missing or contradictory.

Future Seed Connector

The next prototype should stay small and inspectable: take a task statement, select only the necessary seeds through explicit registry relationships, explain why each seed was selected, and show missing context, conflicts, permissions, and readiness.

It does not need a student chat UI, embeddings, or autonomous execution to prove the fast-start concept.

Campus Role

The AI Portal is both an engineering tool and a Laboratory Campus lesson. Its graph records, context budgets, validation failures, safety gates, transcripts, and evaluation results should become inspectable DotTalk++ and Campus material.

This makes AI participation part of the same co-development loop as engine work, documentation, proof, and curriculum—without pretending the experimental portal is already complete.

See Mission & Vision, Laboratory Campus Overview, Current Project Truth, Recursive Co-development, and Current Work Lanes.