Version: 1.0.0
Status: Adopted
Normative for: All SensOS RFC publications and access-controlled companions

1. Purpose

Every SensOS RFC SHALL declare how it may be read, who may change it, and what force it carries. Classification prevents accidental publication of implementation IP and makes ecosystem obligations unambiguous.

2. Required metadata

Every RFC SHALL contain at least:

FieldRequired values
ClassificationPublic Standard · Partner Specification · Enterprise Specification · Internal Engineering · Trade Secret
StatusProposal · Draft · Review · Active · Deprecated · Superseded · Withdrawn · Historic
AudiencePublic · Partners · Enterprise · Internal
Normative LevelInformational · Experimental · Standards Track · Best Current Practice · Historic

Public Standard RFCs published on sensos.org SHALL also continue to provide existing portal frontmatter (title, status, category, version, updated, repository, relation fields) until the portal schema is extended.

3. Classification definitions

ClassificationIntentTypical content
Public StandardInteroperability contractABI, behavior, guarantees, conformance, compatibility
Partner SpecificationIntegration under NDAWire encodings, token grammars, protocol annexes
Enterprise SpecificationCustomer diligence / ops under agreementDeployment guides, shared-responsibility models, audit packs
Internal EngineeringGemmina engineering designADRs, module design, maturity notes, experiment reports
Trade SecretNeed-to-know proprietary advantageEvaluation methods, calibration, solvers, optimized execution

4. Audience definitions

AudienceWho may read
PublicAnyone; published on sensos.org and the public standards repository
PartnersParties under active partner / NDA agreement
EnterpriseCustomers or prospects under commercial or diligence agreement
InternalGemmina Intelligence personnel and explicitly authorized contractors

Audience MUST be consistent with Classification. A Trade Secret document MUST NOT have Audience = Public.

5. Normative Level definitions

LevelMeaning
InformationalExplains context; not a compatibility obligation
ExperimentalProvisional; may change without full deprecation cycle
Standards TrackNormative interoperability requirements for claims of compatibility
Best Current PracticeProcess or operational requirements for the ecosystem
HistoricRetained for record; not for new implementations

6. Access matrix

ClassificationReadPropose changesApprove changesPublish to sensos.org
Public StandardAnyoneCommunity + stewardStandards editors + stewardRequired when Active
Partner SpecificationPartnersPartners + stewardPartner program + stewardForbidden
Enterprise SpecificationEnterprise audienceCustomer success + stewardEnterprise program + stewardForbidden (summaries may be public)
Internal EngineeringInternalEngineeringEngineering leadsForbidden
Trade SecretNeed-to-knowAuthorized inventors/ownersIP / executive designeeForbidden

7. Publication requirements

Public Standard

  1. MUST obey the Documentation Philosophy (WHAT, not HOW).
  2. MUST NOT include wire layouts, token grammars, calibration constants, internal module inventories, or execution strategies.
  3. MUST define observable conformance criteria or explicitly defer them to a named conformance suite.
  4. MUST pass classification review before leaving Draft.

Partner Specification

  1. MUST be distributed only under NDA or equivalent.
  2. MUST reference the Public Standard it implements or extends.
  3. MUST NOT be copied into public RFC bodies.

Enterprise Specification

  1. MAY deepen operational guidance beyond Public Standards.
  2. MUST NOT disclose Trade Secret methods unless a separate exhibit explicitly authorizes that disclosure.

Internal Engineering / Trade Secret

  1. MUST remain outside public Git history for new material going forward (historical research-era commits remain immutable).
  2. MUST NOT be linked from primary public navigation.

8. Approval authorities

Change typeAuthority
Editorial (non-normative)Standards editor
Normative Public StandardStandards editor + steward review
Partner / Enterprise specsProgram owner + steward
Reclassification to/from PublicSteward + IP review
Trade Secret designation or releaseExecutive designee / IP counsel

9. Compatibility with portal status labels

Until metadata is fully unified, map portal status values as follows:

Portal statusGovernance StatusTypical Normative Level
ProposedProposal / DraftExperimental or Standards Track
Active / ImplementedActiveStandards Track
DeprecatedDeprecatedHistoric or Standards Track (sunset)
SupersededSupersededHistoric

10. RFC namespaces

RFCs are further organized by namespace. Namespace assignment does not replace Classification; both MUST be declared.

NamespacePurposeNotes
RFC-COREKernel / observation coreUnchanged
RFC-HEXTObject / transportUnchanged
RFC-HEKBKnowledge baseUnchanged
RFC-MCPMCP extensionsUnchanged
RFC-CALCache / projectionUnchanged
RFC-SensOSPlatform managersUnchanged
RFC-ARCHArchitectural taxonomyUnchanged
RFC-PROCESSLifecycle protocolUnchanged
RFC-MMMeaning Mapper product specsNew
RFC-ITMImplementation traceability & evidenceNew; cross-cutting
RFC-SALegacy semantic annotationSuperseded by RFC-MM; Historic

See RFC Namespaces.

RFC-ITM applies to every product namespace. It does not define product ABIs.

11. Enforcement

Material that violates this policy SHALL be blocked from public release, redacted, or reclassified before publication. Conformance and certification programs SHALL cite only Public Standard and explicitly approved Partner annexes.