SemantIQ is a Public Alpha (Experimental) project. Community participation is welcome, but participation, discussion, or an accepted proposal does not by itself establish implementation, release status, external validation, scientific authority, production readiness, or adoption.
This page is the shortest route into the project.
| Goal | Use |
|---|---|
| Ask a setup or usage question | GitHub Discussions |
| See current work and contribution opportunities | GitHub Projects |
| Browse orientation and learning material | GitHub Wiki |
| Report a reproducible defect or compatibility problem | Reproduction or Compatibility Report |
| Propose a feature | Feature Request |
| Propose architecture or contract changes | Architecture / RFC Proposal |
| Propose a benchmark pack | Benchmark Pack Proposal |
| Submit an independent reproduction attempt | Independent Replication Report |
| Contribute code or documentation | CONTRIBUTING.md |
| Report a vulnerability | SECURITY.md |
Good first contributions include:
- correcting a documentation mismatch;
- validating a quickstart on a clean environment;
- adding or improving a bounded example;
- reporting an integration compatibility result;
- adding a focused regression test;
- improving links, terminology, or contributor guidance.
These normally use the Fast contribution path in CONTRIBUTING.md.
SemantIQ benefits most from evidence generated outside owner-controlled infrastructure.
Useful contributions include:
- independent reproduction attempts;
- operating-system and runtime compatibility reports;
- model/provider integration observations;
- benchmark-pack execution reports;
- divergent or blocked reproduction results.
A failed, partial, or divergent result can be as useful as a successful reproduction when the environment and evidence are recorded precisely.
Architecture, benchmark semantics, evidence logic, scoring, governance, security-sensitive behavior, release-critical contracts, and breaking interfaces use the Core change path and may require an issue, specification, RFC, threat-model review, or compatibility plan before implementation.
Discussions are for questions, ideas, experience reports, early proposals, and results that benefit from conversation before becoming repository work.
A discussion is not an accepted specification or implementation commitment. Material decisions should be promoted into an issue, RFC, specification, or pull request with a durable review trail.
See Discussion Playbook.
The Project board should show current work, contribution opportunities, blocked items, and review state.
Board placement is operational coordination, not a release promise or evidence of implementation.
See Project Board Model.
The Wiki should provide orientation, learning paths, glossary material, and navigational summaries.
Canonical technical truth remains in version-controlled repository documentation, schemas, code, and governance files. Wiki pages should link back to those sources rather than silently replacing them.
See Wiki Seed.
At the current Public Alpha stage, especially valuable contributions are:
- Independent reproduction of documented workflows.
- Compatibility evidence across operating systems, runtimes, providers, and integrations.
- Small benchmark packs and examples with clear licensing and reproducible inputs.
- Documentation friction reports from first-time users.
- Focused tests that expose missing edge cases without changing benchmark meaning.
- Evidence-bound proposals that distinguish implemented capability from external validation.
Do not post credentials, private data, proprietary prompts, confidential datasets, or vulnerability details in public issues or discussions.
Security reports follow SECURITY.md. Conduct expectations follow the Code of Conduct. General support routing is documented in SUPPORT.md.