Status and authority
This is an Alpha/Experimental public projection of the AI Portal schema and identifier model. It gives outside AI partners a stable, readable snapshot. It does not replace the implementation, runtime evidence, HELP and metadata stores, accepted manuals, or owner rulings that support it.
Registered DBF schemas
| Domain | Tables | Upstream definition | Portal posture |
|---|---|---|---|
| Identity and RBAC | SYSUSER, SYSMEMBER, SYSROLE, SYSPERM, SYSROLEPERM, SYSMEMROLE, SYSOVERRIDE, SYSASSIGN, SYSGRANT | identity schema | Governed per-table CRUD and close policies |
| AI-BBS and Pseudo-Chat | SYSBOARD, SYSTHREAD, SYSPOST | BBS schema | Generic Portal CRUD is read-only; the BBS daemon owns writes |
| Global rulings | SYSRULING | ruling schema | Append-only doctrine and owner decisions |
| Portal tracking | SYSLANE, SYSRUN, SYSRUNLANE, SYSPROOF, SYSTASK | tracking schema | Governed tracking; run history is append-only |
| SelfDoc command catalog | SYSCMD | reviewed SelfDoc catalog schema | Read-only metadata projection |
The registered surface contains 19 table schemas across five custody domains. Registration does not assert that every table is seeded or current. Mutation policy follows each table's owner; the word "database" is not a permission model.
Physical format: these are x64base DBF, not classic DBF
Read this before opening any of the tables above with a standard DBF library.
The registered tables are written in the house flavor, version byte 0x64, which
the engine names "x64base DBF" (dbf_version_token -> v64). It resembles
dBASE/FoxPro closely enough to open, and it does not have the same layout.
| Property | Classic DBF | x64base DBF (0x64) |
|---|---|---|
| Version byte | 0x03, 0x30, 0xF5, ... | 0x64 |
| Field-name limit | 10 characters | wider |
| Field-length limit | 255 | wider |
| Record count | 32-bit, header offset 4 | 32-bit mirror plus a 64-bit count in an extended header block |
| Descriptor array | begins at offset 32, all entries real | prefixed by phantom descriptors whose 11-byte name is not a printable identifier |
The phantoms are the trap. A naive reader treats them as fields, shifts every subsequent column, and still produces plausible-looking output -- the record count and record length are correct, because those live at the classic offsets. The result is not an error. It is wrong data that looks like data.
How to read one correctly. A descriptor is real only if its name begins with an
ASCII letter, and a layout is trusted only when sum(real field widths) + 1 equals
the record length -- the +1 being the leading deleted-flag byte. If it does not
reconcile, refuse the read rather than guessing. Concretely: on SYSBOARD a
correct reader reports 9 fields and 2 phantoms; a classic reader reports 11
fields, two of them named with control characters.
This section is a reading contract, not a file-format specification. The
authority is the engine source (include/xbase_64.hpp, src/xbase/dbf_file.cpp,
src/xbase/fields_mgr.cpp); publishing table and field names without this note is
what made an otherwise accurate schema page unusable to an outside reader.
Identity crosswalk
| Identity | Role | Primary relationship |
|---|---|---|
project.<domain>.<name> | Durable program | Parent of governed lanes |
AIF-NNN | Intake or work lane | Links project, lifecycle, work, proof, and closeout |
PDLC / SDLC | Process classification | PDLC may nest inside SDLC; neither allocates identities |
M<n> or named gate | Evidence checkpoint | Belongs to one lane |
R<n> | Doctrine or owner ruling | One global sequence shared by every lane |
| provider/date run id | Bounded execution | Links acting member, project, and one or more lanes |
task.* | Work item | Links to a lane without becoming the lane identity |
proof.* | Evidence record | Links lane, source, state, platform, and observation time |
AIPR-* | Durable AI report | Links to the execution run and authority envelope |
Historical ticket values remain readable. A value shaped like AIF-NNN is a
legacy lane reference; another value is an external ticket reference. Older
records that placed an AIPR-* report identity in run_id remain visible as a
compatibility seam. New records keep execution and report identities separate.
Typed registry schemas
| Schema | Purpose |
|---|---|
ai-report-audit-v1 | Report identity, agent, baseline, and authorization envelope |
ai-report-index-v1 | Generated report discovery |
ai-runs-v1 | Attributed execution and lane links |
labtalk.ai_portal.tasks.v1 | Operational work-item projection |
portal-recall-graph-v1 | Triggered retrieval graph |
dottalk.portal.feed.v1 | DotTalk++ authority-to-consumer feed seam |
dottalk.portal.assertions.v1 | Evidence-anchored routing assertions |
dottalk.fullstack.current.v1 | Maintained current documentation-run pointer |
dottalk.portal.status.v1 | Generated feed, assertion, and current-run status |
dottalk.portal.identifiers.v1 | Canonical identifier classes and legacy mappings |
dottalk.portal.identifier.status.v1 | Generated cross-registry normalization findings |
labtalk-database-ecology-v1 | Database artifact classification and custody |
Data-flow rule
DotTalk++ source contracts feed HELP and metadata stores. Those stores feed manual generation, comparison, proofs, and Portal reports. AIF claims, global R rulings, runs, work items, and proofs pass through the identifier crosswalk before status is projected to the website.
The arrows never make the website authoritative. A correction is made in the owning engineering source or registry, validated there, and then republished.
Return to the AI Portal overview.