Protocol5 IOTA-1 From Theory to Concrete Implementation

Full report

On this page

Executive summary

The highest-confidence reading of the current source set is that Protocol5 IOTA-1 is not a blockchain protocol first. It is a C#/.NET approximate semantic-conversion system that maps English words and phrases to public Unicode / ISO/IEC 10646 symbols through embeddings, ranking, provenance, and explanation. The current Protocol5/AIWikis materials are consistent on the core architecture: a Facade-led .NET service, ADO.NET repositories, SQL Server 2025 vector storage/search, a local LM Studio embedding adapter, and a strict rule that embedding population is local-only tooling, not a public mutation API. The public web surface is intentionally read-only and evidence-heavy, and the system must continue to work in a DatabaseOnly “gist” mode after corpus population.

The most actionable implementation path is therefore a hybrid architecture: keep the core semantic engine private in a Windows/.NET + SQL Server 2025 + LM Studio runtime, expose only read-only ASP.NET endpoints on Protocol5, and, if you need a separate public authority/demo site, export a public-safe package into WordPress rather than giving WordPress live access to the SQL Server corpus. That public-safe export pattern is explicitly recommended in AIWikis, which proposes a manifest plus compressed NDJSON records, import validation, and safe projections while keeping raw vectors private by default.

As of 2026-05-15, the currently discoverable public Protocol5 status endpoint reports that the hosted category corpus is configured but not reachable, with readiness = offline, vectorDimensions = 1998, and publicSeedConcepts = 56. In practical terms, you should not plan your MVP around the hosted public corpus being production-ready today. You should build locally first, using the public seed registry path as your bootstrap mode, then move to local SQL corpus population, then publish only read-only endpoints and exported safe artifacts.

A second important conclusion is that there are two different “IOTA” universes in your source set. Protocol5’s “IOTA-1” is the semantic-converter project. The IOTA Foundation stack is a Move-based blockchain / trust framework with JSON-RPC, GraphQL, Identity, Hierarchies, localnet tooling, and optional DID/VC infrastructure. Those official IOTA Foundation assets are useful as optional trust/provenance layers, but they are not a prerequisite for the Protocol5 semantic engine itself. If you use the official IOTA stack here, the best fit is to anchor provenance, concept-registry hashes, DIDs, VCs, or hierarchical authority, not to move the semantic-conversion core on-chain.

My recommendation for an initial MVP is:

1. Build the seed-registry + database-only converter first.
2. Stand up the SQL Server 2025 vector corpus second.
3. Add LM Studio local embedding generation third.
4. Expose the read-only Protocol5 API fourth.
5. Add WordPress export/import only if you need a public authority/demo surface.
6. Treat IOTA Foundation integration as optional phase-two provenance/governance plumbing.

What the strategy actually is

The current Protocol5 rules define IOTA-1 as “approximate public-symbol conversion, not exact translation”, and explicitly prohibit private-use Unicode profiles, proprietary dictionaries, hidden bilingual tables, or secret codebooks becoming the authority. The visible glyph is an expression/signifier, while the meaning anchor is the selected concept ID, canonical vector hash, provenance, and safety checks. That means the implementation must optimize for ranking, evidence, and inspectability, not for opaque translation accuracy or compression tricks.

The current operating split is also clear. JustAnIota.com is the WordPress implementation / public demonstration / authority surface, while Protocol5.com is the .NET / C# experiment surface using SQL Server vectors and LM Studio. AIWikis in turn is the memory/archive layer that preserves planning and evidence. That separation matters operationally because it implies two different trust boundaries: the private semantic engine boundary and the public evidence/publishing boundary.

The implementation doctrine has evolved in a useful direction. Current AIWikis and Protocol5 materials emphasize phrase-first segmentation, maximal segment lookup, candidate ranking lanes, public Unicode safety, seed-vs-SQL comparison, trace evidence, and database-only fallback. Those are not theoretical niceties; they should directly shape your backlog, your DTOs, your test fixtures, and your observability.

It is also important to separate current directives from older exploratory proposals. Some historical AIWikis intake files discuss broader Unicode coverage, private-use approaches, SQL Server 2026, or very large corpus designs. The current Protocol5 rules and decisions, however, explicitly say no private-use authority, public Unicode only, SQL Server 2025 vector features as baseline, local LM Studio, and a local WPF embedding runner. For implementation, those current directives should take precedence.

The optional IOTA Foundation layer belongs in a different category. The official IOTA Foundation docs describe a Move-based blockchain, JSON-RPC and GraphQL APIs, Identity, Hierarchies, DIDs/VCs, and localnet tooling. That stack is best understood here as an optional trust fabric for provenance and governance, not as the core runtime for semantic conversion.

Authority and responsibility boundaries

This table synthesizes the current source boundaries across Protocol5, AIWikis, and IOTA Foundation materials.

Reference architecture

The architecture that best matches the current sources is a private semantic core plus public read-only evidence perimeter. Internally, you run a Facade over normalization, segmentation, vector composition, ranking, explanation, SQL access, and optional LM Studio enrichment. Externally, you expose only read-only conversion/search/evidence endpoints and optionally export a safe package to a WordPress public site. This directly tracks the current Protocol5 rules, the current .NET architecture planning file, and the WordPress export proposal.

flowchart LR
    subgraph Private Runtime
        UI[Protocol5 Web UI]
        API[ASP.NET Core Read-Only API]
        FACADE[IJustAnIotaConverterFacade]
        LOGIC[Normalization, segmentation, ranking, explanation]
        SQLREPO[ADO.NET repositories]
        SQL[(SQL Server 2025 vector corpus)]
        LM[LM Studio local server]
        RUNS[(ExperimentRun / audit store)]
        POP[EmbeddingDesktop WPF runner]
    end

    subgraph Public Projection
        EXPORT[C# exporter]
        PKG[manifest.json + *.ndjson.gz]
        WP[WordPress plugin import]
        WPDB[(WordPress DB / safe projection)]
        JI[JustAnIota public workbench]
    end

    subgraph Optional Trust Layer
        IOTA[IOTA JSON-RPC / Identity / Hierarchies]
    end

    UI --> API --> FACADE --> LOGIC
    LOGIC --> SQLREPO --> SQL
    LOGIC --> LM
    LOGIC --> RUNS
    POP --> LM
    POP --> SQL
    SQL --> EXPORT --> PKG --> WP --> WPDB --> JI
    EXPORT -. optional hash anchoring .-> IOTA
    RUNS -. optional provenance anchoring .-> IOTA

Required software and libraries

The table below separates source-grounded requirements from recommended implementation choices where the sources are silent.

Recommended topology choices

The current source set strongly favors the middle option.

Concrete implementation blueprint

The fastest realistic delivery path is to implement the system in three passes: bootstrap, populate, and publish.

Build pass one

Start by creating the project skeleton that the current architecture file already sketches: Abstractions, Facade, Application, Domain, Infrastructure.Sql, Infrastructure.LmStudio, Worker.Indexer, Web, Tests, and a test harness. Do not begin with a single monolith. The current source set is clear that the Facade is the stable public contract and the repositories must remain persistence-agnostic, with ADO.NET staying behind abstractions.

Implement the v1 facade first, even before SQL:

Protocol5.JustAnIotaConverter.Abstractions
Protocol5.JustAnIotaConverter.Facade
Protocol5.JustAnIotaConverter.Application
Protocol5.JustAnIotaConverter.Domain
Protocol5.JustAnIotaConverter.Infrastructure.Sql
Protocol5.JustAnIotaConverter.Infrastructure.LmStudio
Protocol5.JustAnIotaConverter.Worker.Indexer
Protocol5.JustAnIotaConverter.Web
Protocol5.JustAnIotaConverter.Tests
Protocol5.JustAnIotaConverter.TestHarness

That layout comes directly from the current AIWikis architecture file and is the right starting point for a real repository.

Then implement the seed-registry path before the SQL corpus. Protocol5’s current rules explicitly describe a developer path where JustAnIotaConverterFactory.CreateDefaultDatabaseOnly() runs from a public seed registry for disconnected apps, smoke tests, UI prototypes, and early WordPress paths before the vector store is ready. That is the correct MVP bootstrap because it lets you lock the DTOs, ranking outputs, and evidence packet shape early.

Build pass two

Next, implement the normalization and segmentation pipeline exactly in the order the rules describe:

1. Normalize input, preferably to NFC.
2. Split paragraphs into sentences.
3. Inside each sentence, try the longest stored English segment first from Category.Categories.
4. Fall back to single words in Category.Words.
5. Rank candidate public glyph rows from Category.ISO10646.
6. Return ranking lanes, candidate source atlas families, scores, and provenance.

That phrase-first, maximal-segment approach is one of the clearest current implementation requirements in the source set; it is also where many naive implementations will fail by tokenizing too early or too aggressively. Build it as a dedicated service, not as incidental string parsing in controllers.

At the same time, build the core minimal SQL schema for the first internal corpus. The simpler early AIWikis schema is still useful for an MVP because it is easy to validate and test:

• IotaSymbol
• EnglishTerm
• EmbeddingModel
• SymbolEmbedding
• EnglishEmbedding
• SimilarityEdge
• ExperimentRun

But do not stop there architecturally. The more current Protocol5 category-corpus strategy centralizes row metadata in Category.IotaEmbeddingRecords, keeps source-local IotaEmbedding / IotaEmbeddingRecordId pairs on source rows, and introduces a more expressive concept/assertion graph with Category.IotaConcepts, Category.IotaConceptRelations, Category.IotaSemanticFrames, Category.IotaSemanticAssertions, and related slot tables. For an MVP, I recommend starting with the simple schema and reserving the graph layer behind interfaces so you can add it later without breaking the facade.

Build pass three

Once the schema is in place, build the local embedding population runner. The current rules are explicit that population belongs in the local WPF desktop runner and not in a web mutation route. The runner should:

• read source rows from Category.Categories, Category.Words, and Category.ISO10646,
• construct descriptor text from public metadata and human-readable anchors,
• call LM Studio locally,
• store model name, dimensions, prompt/profile/version, source hash, source column, provenance, and timestamps,
• clear and regenerate vectors when normalized source text, version, model, source ID, or dimensions change.

The current AIWikis decisions file gives a particularly important operational constraint: the local SQL Server preview environment rejected vectors larger than 1998 dimensions, so the active current category-corpus population uses vector(1998) and stores a normalized first-1998 slice from text-embedding-qwen3-embedding-8b’s native 4096-dim output. Unless you have confirmed different behavior in your environment, treat 1998 as the current SQL ceiling and standardize on it for production-like testing.

LM Studio integration should use the local OpenAI-compatible server. At minimum you need:

• GET /v1/models
• POST /v1/embeddings

with the base URL pointed to LM Studio rather than a cloud provider. LM Studio documents http://localhost:1234/v1 as the standard pattern.

Publish pass

Only after the seed and SQL paths are producing stable evidence packets should you expose the Protocol5 read-only web API. The currently discoverable public endpoints are:

• /api/justaniota/status
• /api/justaniota/convert
• /api/justaniota/concepts/{concept_id}
• /api/justaniota/semantic/resolve
• /api/justaniota/semantic/embed
• /api/justaniota/meaning
• /api/justaniota/similarity
• /api/justaniota/compare
• /api/justaniota/round-trip
• /api/justaniota/ranking-demo
• /api/justaniota/search
• /api/justaniota/category-search

However, only some of those have browser-discoverable public descriptors today. The safest engineering move is to freeze your own internal contracts first, then map public endpoints onto them. Use the public status endpoint as a health/readiness probe and the public ranking-demo and search contracts as your initial externally visible API forms.

If you also want the WordPress authority/demo path, do not point WordPress directly at the Protocol5 SQL database. Instead, implement the portable package export/import workflow:

1. C# exporter creates manifest.json plus records-*.ndjson.gz shards.
2. WordPress plugin accepts manual admin upload.
3. Plugin validates package shape, checksums, row counts, vector dimensions, and public-safety constraints.
4. WordPress imports only safe searchable metadata into its own tables.
5. Public WordPress endpoints serve only allowlisted safe projections.
6. Vectors and raw package files remain private by default.

That pattern gives you strong interoperability with existing public CMS infrastructure without compromising the core semantic engine’s trust boundary.

APIs, data contracts, and interoperability

Public Protocol5 endpoints to implement first

The currently documented read-only contracts are enough to define an MVP public surface.

GET /api/justaniota/status should return environment and readiness information. The currently exposed status includes modes, directions, endpoint inventory, live-AI state, seed concept count, and category-corpus readiness. This is the endpoint you should wire into your health checks, canaries, and deployment gates.

GET|POST /api/justaniota/ranking-demo is the best first “real” public API because it already separates seed-only and SQL-backed behavior and documents its POST fields:

• input
• direction
• mode
• tokenizationMode
• resultLimit

GET|POST /api/justaniota/search is the best second public API because it documents both text-query and embedding-query modes. Its POST fields are:

• input for text query when LM Studio embedding is configured,
• embedding for direct vector input,
• target = both | categories | words | iso-10646,
• resultLimit.

Recommended internal request and response contracts

The public docs do not fully specify the discovered-but-undocumented endpoints such as /convert, /meaning, /round-trip, and /semantic/resolve. For implementation, I recommend a stable internal contract like the following, based directly on the public UI/evidence requirements and the current facade responsibilities. The schema below is recommended, not an official public spec. It aligns with the current public workbench semantics around concept anchors, vector hashes, ranked candidates, warnings, and drift.

{
  "requestId": "01JX....",
  "input": "how are you today",
  "direction": "english-to-iota",
  "mode": "database-only",
  "tokenizationMode": "single-glyph",
  "resultLimit": 5,
  "sourceLanguage": "en-US",
  "publicUnicodeOnly": true,
  "includeEvidence": true
}

A response should carry both user-facing and machine-facing evidence:

{
  "requestId": "01JX....",
  "isApproximate": true,
  "output": "警火",
  "selectedConceptId": "concept.warning.event",
  "canonicalVectorHash": "sha256:...",
  "confidence": 0.82,
  "unicodeSafety": "pass",
  "unknownRate": 0.10,
  "rankedCandidates": [
    {
      "candidateId": "U+8B66 U+706B",
      "score": 0.82,
      "distance": 0.18,
      "rankingLane": "sql-category",
      "sourceAtlasFamily": "iso10646",
      "provenance": ["Category.Categories:warning fire"]
    }
  ],
  "trace": {
    "normalization": "NFC",
    "segments": ["warning fire"],
    "resolvedTerms": ["warning fire"],
    "warnings": []
  },
  "drift": {
    "roundTripOutput": "warning fire",
    "lossNotes": []
  }
}

The reason to include selectedConceptId and canonicalVectorHash is that the current Language Converter page explicitly says those—not the visible glyph alone—are the meaning anchor.

Core data model

A practical implementation needs two data-model layers.

The MVP layer should focus on fast delivery and deterministic query paths:

erDiagram
    IOTA_SYMBOL ||--o{ SYMBOL_EMBEDDING : has
    ENGLISH_TERM ||--o{ ENGLISH_EMBEDDING : has
    EMBEDDING_MODEL ||--o{ SYMBOL_EMBEDDING : uses
    EMBEDDING_MODEL ||--o{ ENGLISH_EMBEDDING : uses
    IOTA_SYMBOL ||--o{ SIMILARITY_EDGE : from_or_to
    ENGLISH_TERM ||--o{ SIMILARITY_EDGE : from_or_to
    EXPERIMENT_RUN }o--|| EMBEDDING_MODEL : selected

    IOTA_SYMBOL {
      int SymbolId
      string CodePoint
      string Glyph
      string UnicodeName
      string BlockName
      string GeneralCategory
      string DescriptionText
    }
    ENGLISH_TERM {
      int TermId
      string TermText
      string NormalizedText
      string LanguageTag
      string SourceKind
    }
    EMBEDDING_MODEL {
      int ModelId
      string Provider
      string ModelName
      int Dimensions
      string DistanceMetric
      string VersionHash
    }

That layout is drawn directly from the Protocol5 .NET architecture page.

The production layer should then add the newer category-corpus graph that current AIWikis decisions emphasize:

• Category.IotaEmbeddingRecords
• Category.IotaConcepts
• Category.IotaConceptSourceLinks
• Category.IotaConceptRelations
• Category.IotaSemanticFrames
• Category.IotaSemanticFrameSlots
• Category.IotaSemanticFrameSlotEdges
• Category.IotaConceptFrameLinks
• Category.IotaSemanticAssertions
• Category.IotaSemanticAssertionSlots

Those extra tables are not optional fluff. They are the path from “vector similarity demo” to a system that can explain who / did / to-whom-or-what / when / polarity / modality as first-class evidence. If you skip them entirely, you will likely hit an explainability ceiling later. The right compromise is to architect for them immediately, but phase them after the first working corpus.

Export package and message format for interoperability

For migration and interoperability, the current AIWikis export proposal is among the most concrete implementation documents in the source set. The recommended transport is:

• manifest.json
• records-*.ndjson.gz
• optional neighbors-*.ndjson.gz
• optional checksums file.

The recommended row contract is flattened and implementation-neutral so that WordPress or another downstream system does not need to understand the live SQL schema:

{
  "id": "Categories:42:sha256-5e86c1...",
  "source_table": "Categories",
  "source_key": "42",
  "descriptor_text": "Artificial intelligence memory category",
  "embedding_version": "protocol5-local-v1",
  "embedding_model": "nomic-embed-text-v1.5",
  "embedding_dimensions": 768,
  "text_hash": "sha256:...",
  "updated_utc": "2026-05-04T14:25:19.381Z",
  "visibility": "public",
  "public_meta": {
    "kind": "category",
    "title": "AI Memory",
    "slug": "ai-memory",
    "locale": "en-US",
    "tags": ["memory", "search", "protocol5"]
  },
  "vector": {
    "encoding": "f32-base64le",
    "data": "AAAAQJqZmT8AAABAKC4..."
  }
}

That shape is well-designed for forward compatibility because it is deterministic, language-neutral, and decoupled from the source joins. It also honors the current recommendation to keep vectors as f32-base64le in the canonical package while optionally supporting json-f32 for debug fixtures.

Interoperability with existing systems

If you already have internal systems, do not integrate them against raw Protocol5 tables first. Integrate them against the Facade DTOs or the portable package contract.

Use these patterns:

• Existing ASP.NET / .NET apps: reference the facade abstractions and consume the read-only conversion/search APIs.
• Existing SQL Server workloads: integrate through ADO.NET repositories or views, not direct table assumptions, because the schema is still evolving from simple embedding tables toward a richer concept/assertion graph.
• CMS / WordPress / static sites: use the export/import package, not live SQL Server access.
• Optional trust / governance requirements: anchor package hashes, registry snapshots, concept release versions, or policy approvals onto IOTA Identity / Hierarchies / VCs rather than putting the whole corpus on-chain. That is the cleanest interoperability point with the official IOTA stack.

Security, deployment, testing, monitoring, and scale

Security considerations and threat mitigations

Most of the meaningful security work here is Unicode security, semantic integrity, and trust-boundary discipline, not classic network crypto alone.

Two more mitigations are worth making mandatory in version one.

First, enforce public Unicode safety at the logic layer, not just at the UI. The rules explicitly say the logic layer owns scalar handling, grapheme grouping, approximation labels, and private-use rejection. If you relegate those checks to the browser, you will create inconsistent semantic behavior across clients.

Second, keep embedding generation local. Current Protocol5 decisions explicitly make embedding population a local desktop/tooling workflow rather than a public mutation endpoint. That is both a design doctrine and a sound security boundary.

Legal and compliance considerations

The clearest licensing consideration is that your public Unicode metadata sources are usable, but not without preserving the right notices. Unicode states that its data files and software are generally licensed under the OSI-approved Unicode License v3, and the Unicode License text permits copying, modifying, publishing, distributing, and even selling copies provided the copyright/permission notice appears in copies or associated documentation. The Unicode Character Database is explicitly the authoritative property-data source for character metadata.

That means you can safely ingest public Unicode metadata, CLDR data, and related public descriptor bundles into the corpus, but you should maintain:

• source version,
• license notice,
• provenance,
• and update history.

If you add the official IOTA Foundation trust stack, the compliance question becomes mostly privacy and permanence. IOTA’s object model and on-chain identity model are persistent, addressable, and designed for verifiable interaction; that is good for hashes, DIDs, VCs, and delegated authority, but it is a poor place for raw user text, raw embeddings, or sensitive semantic traces. The safe pattern is to put hashes and attestations on-chain, keep the semantic corpus off-chain, and use VCs/presentations for verifiable authority or release approvals. That is an implementation inference grounded in the IOTA object model and identity docs.

Deployment options

These options are grounded in the current split between private semantic engine, public read-only APIs, and optional public safe projection. For optional IOTA deployment, the official docs give you localnet, public JSON-RPC endpoints, and a Universal Resolver Docker flow.

If you choose optional IOTA integration, use JSON-RPC first. The official JSON-RPC reference is stable and currently documented as v1.22.1 with endpoint conventions like https://api.NETWORK.iota.cafe:443 and indexer variants, while the TypeScript GraphQL client is still explicitly marked as in development.

CI/CD and testing strategy

A rigorous testing strategy should mirror the architecture, not just the controllers.

Your CI pipeline should include:

1. Contract tests for facade DTO stability.
2. Normalization tests for NFC, Rune handling, grapheme grouping, and private-use rejection.
3. Segmentation tests that prove phrase-first lookup outranks single-word fallback.
4. Seed-registry golden tests for known phrases.
5. Seed-vs-SQL regression tests using the same logic used by the public ranking demo.
6. Integration tests against an actual SQL Server 2025 vector-capable environment.
7. Load tests for /search, /ranking-demo, and /round-trip.
8. Adversarial Unicode tests for confusables, zero-width marks, and hidden controls.

The current C# slice already mentions MSTest contract coverage, which is a good clue about the expected style of the testing layer. For CI/CD itself, the specific platform is unspecified in the sources, so either GitHub Actions or Azure DevOps is reasonable. If you need Windows desktop test automation for the WPF runner or SQL Server preview features, use self-hosted Windows runners rather than trying to force all tests into Linux-hosted pipelines. That recommendation is informed by the Windows-heavy runtime stack and SQL Server 2025 tooling requirements.

Monitoring and performance guidance

Monitor the system by semantic mode, not just by HTTP status code. The public workbench already exposes the categories of telemetry you should care about: approximation status, ranked candidates, ranking lanes, vector evidence, seed-vs-SQL differences, drift, and corpus readiness. Mirror those internally as first-class metrics.

At minimum, instrument:

• request latency by mode (database-only, hybrid, llm-assisted, semantic-hybrid, semantic-interlingua),
• unknown-rate,
• drift rate,
• candidate-lane distribution,
• SQL corpus reachable/unreachable,
• embedded-row coverage,
• stale-row count,
• LM Studio request latency,
• vector-distance distribution,
• public Unicode safety failures.

For vector performance, the core official technical facts are:

• SQL Server vector columns currently support 1 to 1998 dimensions.
• VECTOR_DISTANCE supports exact kNN-style search.
• VECTOR_SEARCH provides approximate nearest-neighbor search.
• SQL vector indexes use DiskANN, which is intended to give high QPS and low latency with approximate search.
• float16 vectors exist but are still preview-gated in SQL Server 2025.

That leads to a straightforward operational rule:

• Use exact search during development, correctness testing, and small-corpus operation.
• Use ANN (VECTOR_SEARCH + vector index) once latency matters and the corpus is large enough that exact scans are too expensive.
• Keep embedding caching on the LM Studio side and pre-aggregated vectors on the SQL side where possible.

A simple storage formula is also worth planning around. At the current Protocol5 local ceiling of 1998 dims, a float32 vector is about 7,992 bytes before table/index overhead. For large multi-table corpora, that makes index and storage planning non-trivial even before you add similarity edges and experiment records. By contrast, smaller model widths or truncation strategies can materially reduce storage and improve latency. That estimate is a direct calculation from the documented SQL vector width and float32 storage model.

Delivery timeline, staffing, costs, and open questions

Recommended MVP timeline

The Gantt below assumes a start on 2026-05-18 UTC and a twelve-week MVP. It prioritizes source-aligned deliverables rather than speculative features.

gantt
    title Protocol5 IOTA-1 MVP
    dateFormat  YYYY-MM-DD
    axisFormat  %Y-%m-%d

    section Foundation
    Repo skeleton and facade contracts     :a1, 2026-05-18, 10d
    Seed registry and DTO golden tests     :a2, after a1, 10d

    section Corpus
    SQL schema and ADO.NET repositories    :b1, after a1, 15d
    Unicode/descriptor ingestion           :b2, after b1, 10d
    LM Studio integration and cache        :b3, after b1, 12d
    EmbeddingDesktop population runner     :b4, after b3, 10d

    section Query engine
    Phrase-first segmentation and ranking  :c1, after a2, 15d
    Evidence packet and drift reporting    :c2, after c1, 10d
    Read-only API endpoints                :c3, after c2, 10d

    section Hardening
    SQL integration/load/security tests    :d1, after c3, 10d
    WordPress export/import path           :d2, after c3, 10d
    Pilot deployment and readiness gates   :d3, after d1, 5d

This sequence follows the current strategy: bootstrap with seed concepts, then local SQL population, then read-only evidence-rich publication, then public-safe export if needed.

Staffing and effort estimates

The figures below are implementation estimates, not official published budgets. They are based on the current stack complexity: C#/.NET service, ADO.NET, SQL Server 2025 vector features, local LM Studio integration, WPF tooling, and optional WordPress/IOTA integrations.

The minimum realistic MVP roles are:

• Senior .NET engineer / architect: facade, logic, DTOs, APIs, integration direction.
• SQL/vector engineer: schema, indexing, ingestion, search tuning.
• Frontend engineer: Protocol5 TypeScript UI, evidence views, no-jQuery/no-Bootstrap compliance.
• QA/DevOps: automated tests, release gates, observability, deployment.
• Optional WordPress engineer: only if you preserve the dual-surface strategy.
• Optional IOTA engineer: only if you add DID/VC or hierarchy-based provenance.

Recommended migration sequence

If you are moving from theory to a durable implementation, use this migration order:

1. Theory to seed registry: encode a small reviewed concept set with deterministic expected outputs.
2. Seed registry to SQL corpus: ingest Category.Categories, Category.Words, and Category.ISO10646.
3. SQL corpus to evidence-first API: expose read-only endpoints with ranking lanes, provenance, and drift.
4. Evidence-first API to public authority: add WordPress export/import only after public-safe package validation is stable.
5. Public authority to verifiable governance: add optional IOTA DIDs, VCs, or Hierarchies only for release/provenance workflows.

Open questions and limitations

Several details remain genuinely unspecified or only partially public.

The first gap is the exact public contract for endpoints like /api/justaniota/convert, /meaning, /round-trip, and /semantic/resolve. The public status endpoint lists them, but the publicly discoverable browser descriptors currently document only /status, /ranking-demo, and /search. Your implementation should therefore freeze internal contracts first and treat the undisclosed public contracts as subject to change.

The second gap is the final production schema choice between the simpler IotaSymbol / EnglishTerm model and the richer Category.IotaConcepts / IotaSemanticAssertions graph. The sources show both, and the newer graph-oriented model is clearly the longer-term direction, but it is not fully public as a runtime contract yet.

The third gap is the final deployment environment. The source set strongly suggests Windows-local SQL Server + LM Studio + WPF tooling, but it does not specify your cloud, VM size, GPU plan, operating model, or whether the public site and private engine will share infrastructure. Those should be treated as deployment decisions, not architectural unknowns.

The fourth gap is the role of the official IOTA Foundation stack. The current Protocol5 materials do not require it. I have treated it as an optional provenance/governance layer because that is the cleanest fit with IOTA Identity, VCs, and Hierarchies, but that integration is not a current Protocol5 requirement and should not block the semantic MVP.

The practical bottom line is simple: if you want to move from theory to implementation quickly and with the least rework, build a private, evidence-first, read-only .NET semantic engine first, a SQL Server 2025 vector corpus second, and any public WordPress or optional IOTA Foundation integration only after the core evidence packet, ranking logic, and database-only fallback are stable.